This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The border between fiction and reality


On Wed, 18 Aug 2004, Hans Ronne wrote:

> However, a different situation arises with move-unit commands, all of which
> eventually end up in advance_into_cell. At this point we are committed to
> moving, and we have to know what real units are present in the destination
> cell. 

Do we?

> Consider the case of a single invisible enemy
> unit in the target cell. Because of its presence, advance_into_cell will
> schedule an overrun action. In its absence, it schedules a move action.
> Whether we see the unit or not is irrelevant.

Right. Are you saying this is a problem?
If we are advancing into a cell as a result of a movement 
task, then a flag should be passed to the 'advance_into_cell' 
code to indicate that an overrun should not be attempted in the 
case of a seen enemy unit. If the enemy unit is unseen, the an 
overrun should, in fact, be attempted, because this case is no 
different than if the human player had been clicking along cell by 
cell and had accidentally run into the unseen enemy.

> Every call to advance_into_cell in the interfaces is therefore preceeded by
> a unit_at which gets a pointer to the first real unit in the stack.

Yuck.

> According to the principle that the interfaces should deal only with unit
> views, I started to convert these calls to unit_view_at instead, but soon
> realized that this was a mistake.

I am talking without having seen the code recently, so perhaps I 
am missing something, but I would not consider that to be a 
mistake.

> In fact, the task code which does the same thing as advance_into_cell
> (do_move_to_task and do_approach_subtask) also checks for real units in the
> destination cell. However, the main reason for this seems to be that these
> tasks once could schedule attack actions against enemy units, just like
> advance_into_cell does. That code was later commented out, so I'm not sure
> to what extent we really need these unit pointers in the task execution
> code.

Like I stated earlier, if the human wouldn't know the enemy was 
there and the enemy is on the path being taken, then the human 
would have likely clicked on the cell containing the enemy if 
he/she had been moving cell by cell with keys or clicks. The 
automatic movement should not use special knowledge to avoid 
combat when, in fact, the human player could not have such 
knowledge.

Eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]