Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Fog, was: Idea for 2.0

Re: [Freeciv-Dev] Fog, was: Idea for 2.0

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Fog, was: Idea for 2.0
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Sun, 18 Jul 1999 14:25:59 +1000 (EST)

I'm not sure if this will clarify things, or just add more fog,
but I will try to make a few clarifications of my own. :-)

1. The server has to know what the client can currently see.
This is not only because the server must sometimes act on 
this information (eg, send updates), but so that the server
can successfully save the game and restore, and can resend
the information, eg after a restore, or if the client loses 
the connection and re-connects, or if the client is away for 
a few turns, or the client disconnects and someone else with
a different client connects as that player, or if the player
is a server-side AI and later a client connects and wants to 
start playing that player as a human.

2. If the client wants to record historical information about
what happened on previous turns, thats its business.  Well,
potentially it could be useful for the server to do this, but
its not currently supported.  Persistent storage of data by
such a client is also not currently supported, but might be 
nice to have.

3. Is the information about what the client sees in fogged
areas part of the "current view" or is it "historical"?
I think this is the crux of the disagreement. 
That it is historical information is true in some sense.
However I would argue that it can also be considered part
of the "current view", because at least _some_ of the 
information is stuff which the client _must_ display to
be considered reasonable.  And the information _must_ be 
retained through save/restore, disconnect/reconnect,
change of server-AI to human, etc.  That is, although
it is in some sense historical, it is not acceptable 
for the client to "forget" this information, because it
is information which by the "rules" of the game the user 
_should_ see.

4. Supposing by 3 that it is game "policy" that certain
information forms part of the "current view", then what
should be the details about that policy?  Eg, specifically,
what information about enemy units last seen in areas 
covered by fog should be considered part of the "current

4a. In Civ1, the view of such units was kept, so long as the
unit remained stationary (typically fortified).  Once the
unit moved (in any way), it disappeared from view.  But
this doesn't seem very sensible to me, because it means 
that when the unit moves, the client gets an update about
a unit in a now non-visible area.

4b. A possibility mentioned before would be to show the 
unit/tile exactly as it was last seen, until the tile bcomes 
visible again.  

4c. Another possibility is the "Warcraft units" method (I think) 
that all enemy units disappear from view as soon as they become

I think I prefer 4b for tiles and cities (which are naturally
stationary things which you have some expectation they may
still be there later), but 4c for units, which often move around.

5. An issue related to 4 is when a unit is the same as a 
previously seen unit.  In the current implementation a client 
may realize this due to the persistence of unit id values.  
(This doesn't even require much smarts, just the current 
implementation that there can only be one representation 
of a unit with a given id.)  

This could be considered "cheating" but actually it could 
also be rationalised away: eg, military intelligence saw the 
8th Greek Light Cavalry Regiment at one time, and recognised 
the same regiment in another place sometime later.

Hope we're getting somewhere here,
-- David

[Prev in Thread] Current Thread [Next in Thread]