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: More unit view stuff


>Regarding the basic unit view problem, I would argue in favor of
>keeping the "fog-of-war" methodology.  I didn't quite follow the
>entire description of how the unit views work, but if these views
>are "owned" by a given side, then it seems to me that it should be
>possible to fix them so that they are static -- and disassociated
>from the real, underlying unit.  Since these views never change
>position, and are removed only when the hex they occupy is directly
>viewed, it would be easy enough to remove them as new intelligence
>becomes available.  And I don't see how adding in the purging of
>"dated" unit views would be problematic.  But then again, I don't
>have the courage to look through the kernel code to see why it's
>difficult.  B-)

Dissociating the unit views from the real units is easy enough. The problem
is that we also need new interface code to draw the views. The current code
is cheating and draws a real unit instead of a unit view when the real unit
exists. And it cannot draw occupants without cheating.

As for the purge, you are right in that it should be easy to implement. The
problem is mostly a design problem. How often should the views be purged? I
would say it depends a lot on the game.  And on what the user wants. I'm
leaning towards making it a user preference, if we go this way. Which of
course would require even more interface code :-/.

BTW, the problem with interface code is that we now have no less than five
interfaces: curses, x11, tcl, mac and sdl. Adding to the complexity, the
mac interface exists in two flavours (classic and carbon) and the tcl and
sdl interfaces in three flavours (unix, mac and windows). Even if all
features are not supported in all interfaces, you have to make sure that
each interface still builds and runs without problems when you change
things around. For example, you may need to add dummy functions for stuff
that is not implemented in a specific interface.

>I'm not sure, Hans, what you mean here.  Are you saying that it does
>not make sense to also be given the terrain information?  That only
>the unit's position should be revealed?

No, rather the opposite. I meant that terrain info perhaps is more useful
than the position of a unit that quickly becomes obsolete and just adds to
the host of stale unit views. So the idea would be to reveal terrain that a
unit can see (adjacent cells) rather than just the cell it sits on.

>If this is the case, then maybe the view update should be that a
>side's view needs to be layered.  (Perhaps it already is.)  One
>layer is the terrain, which presumably doesn't change.  Portions
>of that are determined to be revealed or unrevealed.  Another
>layer is the unit-views of units that are not directly owned or
>controlled by or in view of that side -- e.g. the enemy units.
>Most of this information would be obsolete.  Finally, there are
>the unit-views that are 100% reliable.  These are of the side's
>units, but also of units within the "visible" range of the side's
>units.
>
>Is this feasible?  Does it make sense?  Is it already implemented
>this way, and I'm just babbling?  B-)

What you say makes a lot of sense, since it is pretty much how the code
works. There are already separate layers for terrain view and unit views.
I'm not sure that separarate layers for stale and current unit views would
make a difference. They only differ in that the current ones have been
updated recently. Otherwise, they are handled in the same way.

Hans



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