Unit view problems (long)

[Hans Ronne <hronne at telia dot com>]

I haven't checked anything in for a month now, but that doesn't mean xconq
development has ceased. I have been digging into the unit view code, which
is the last major thing that needs to be fixed in the current version of
xconq. As Stan pointed out last year, there are a number of bugs in the
unit view code, e.g. the frequent drawing of mobile units without an emblem
in games where all mobile units belong to a side (and thus have emblems).

That particular bug turned out to be due to a unit moving from its old
(seen) location to a new (unseen) location inside a city. Since occupants
are drawn without an emblem, the obsolete view of the unit in its old
location would now also be drawn without an emblem, thus in effect
revealing not only that the unit had moved, but also that it had moved
inside something.

This bug was easy to fix, but it was only the tip of an iceberg. As I
digged into the unit view code, I found several similar problems. Most of
them involve transport-occupant relationships and situations when a unit
actually is in a different location than its obsolete view.

After some careful thought, I can see two possible fixes. One of them is
easy to implement but would also somewhat change how the game is played.
The other fix is harder, but would leave the gameplay more or less intact.

First, an explanation for those of you who never peeked at the kernel code.
In non-see-all games, units  are not drawn directly on the map. Instead,
they are tracked by separate objects called unit views, and it is those
that are drawn on the map. One enemy unit can have several unit views, if
it has been observed several times in different locations, and all of them
can subsequently be drawn on the map.

Whether or not an enemy unit (or rather its view) is first seen, is
determined by the view coverage of your side. The coverage is typically any
cell within one cell from a friendly unit. It is stored as an area layer
that is updated as your units move around. You can turn display of the view
coverage on in most interfaces. Non-covered cells are then drawn as grayed
out regions.

Now, here is the catch. Xconq works somewhat like a tactical operations
map. By this I mean that not only does it draw units (or views) that you
actually can see right now, but also obsolete views of units in their "last
seen location" even if this location is no longer directly observed by you.
The display is thus a mix of real time data and (usually obsolete)
intelligence.

The good thing about this is that it is just like the confusion in real
battle. A common tactical mistake is to interpret multiple sightings of the
same unit as several units, thus overestimating the strenght of the enemy.
This is something xconq certainly facilitates.

The bad thing is the above mentioned display bugs. Another problem with the
current approach is that obsolete unit views never expire. This means that
the map can become littered with stale unit views. An experienced player
will recognize them as units that cease to move. It seems that Stan
intended for unit views to be purged at some point, since each unit view is
dated, but this was never implemented. In effect, the only way to purge or
update a unit view is to move a unit nearby so that its cell enters your
covered area.

Here are the two possible fixes:

FIX 1 (THE EASY WAY)

Get rid of the "last seen location" stuff. Only draw units that are
actually observed in real time. This would mean that if you fly over enemy
territory you would only see units as long as they stay within your vision
range. After that, it would be up to you to remember what you saw and
where. You would no longer have obsolete unit views to guide your memory.

The good thing about this draconian solution is that it solves all the
problems. In fact, the entire unit view code could then be retired, since
you would only draw images of real units. There is also an attractive
simplicity to this solution. The possibility of drawing unit views instead
of real units is nice in theory, but I have found that it adds little value
to the game. As noted above, an experienced player is never fooled by
obsolete views: they are just a nuisance.

The bad thing is that you loose the fog-of-war confusion, which is
something rather unique to xconq. I know of no other game that spends a lot
of time drawing images in the wrong places of units that no longer exist
:-).

FIX 2 (THE HARD WAY)

The heart of the problem is the fact that the unit view object does not
represent transport-occupant relationships correctly, and therefore has to
rely on the underlying real units (if they still exist). This approach will
always fail if the real unit died or moved away. The only way to fix this
is to implement transport-occupant relationships also for unit views.

Furthermore, some kind of date-based purge of obsolete unit views would
have to be implemented, as originally intended. The question then arises
how frequently should views be purged. Once each turn? Should it perhaps be
a user preference? Or a game setup option?

The good thing about this solution is that it keeps the fog-of-war concept,
which perhaps could be developed into something more interesting. For
example unit views that move around instead of just sitting there. Sort of
like the Flying Dutchman ...

The bad thing is that this fix would require a lot of coding that could be
better spent elsewhere. Furthermore, much of the problems deal with
something that is rarely seen in real games, i.e. enemy units whose
occupants are visible. This can be achieved by setting see-occupants to
true for a given unit type, but it is a rarely used option.

So now you know about the two options, if you cared to read this far.
Feedback and opinions are welcome.

Hans