The border between fiction and reality

[Hans Ronne <hronne at comhem dot se>]

In my hunt for unit pointers I ran into an interesting problem. Where
exactly is the border between plans and actions in the case of the human
player? Most of the discussion so far has focused on the AI, and I think
there is a consensus that things happen only when an action is executed.
Anything before that (plan execution, task execution) is planning code that
should deal with unit views only.

For the human player, the answer is easy when we are dealing with command
functions that directly schedule actions. Until the command is given, it is
all planning. The corresponding interface code should therefore use unit
views only, which is what the human player sees.

If a human command schedules a task for execution, things become a little
more complicated. However, one can argue, as I have done, that as long as
the task has not scheduled any actions, nothing has really happened that
affects the state of the game. Hence, the task execution code would also be
part of the (extended) planning code, just as for the AI. Unit pointers
should be banned.

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. Unit views will not do. 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.

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.
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.

The best that we can do in this case is to restrict the unit pointers to
the common interface code by letting advance_into_cell look them up itself.
And I will probably do that. Feeding it a unit pointer as an argument that
it can look up itself doesn't make much sense, anyway.

The conclusion would seem to be that advance_into_cell is really part of
the action code (that part of the kernel where things do happen). But it is
also, by definition, part of the interface. So perhaps the two are
inseparable.

One may ask, then, is there really a difference between advance_into_cell
and the task execution code? Both of them recieve commands from the
interface (human player) and both of them schedule actions. Perhaps we
should permit unit pointers in the task execution code as well?

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.

Hans