Re: [Freeciv-Dev] Idea for 2.0

[Greg Wooledge <wooledge@xxxxxxxxxxx>]

Jules Bean (jmlb2@xxxxxxxxxxxxxxxx) wrote:

> Artur Biesiadowski wrote:

> > - if client crash or lost link and restart, there will be nobody to get
> > this information from.

I hadn't considered that.... :-/

> > - I'm not sure if hacked cleint could not use it to gain illegal
> > visiblity after load/save; anyway first point is enough I think.

That's what I was thinking about.

> The issue is that the client, to be useful, wants to store what it
> *last* saw, for squares which it can't now see.  IMO, it would be
> strange for the server to try to keep track of what the client last saw
> on each square - it would be cleaner that the client remembers this.

I truly do wish it could be that simple.  But as far as I can see, it
cannot.  The server must be responsible for saving the entire game state,
which includes the 'state of known-ness' of the map from each client's
point of view.  For reasons stated above, the client cannot be held
responsible for accurately reporting this information at save game time.


Peter Schaefer (schaefer@xxxxxx) wrote:

> Generating it in the client and sending for safekeeping is
> bad for traffic reasons. 

That, too. ;-)

> I think either the server should keep and save a full map view for each 
> client,
> or the visibility rules should be modified so that you see 
> only the terrain type and cities, if a tile has been explored.

The client wants to know the tile terrain type, the tile improvements,
and the visible unit and/or city.

The unit/city is the hard part.  If there's a unit/city on a tile when
the client can no longer see that tile, then the following information
(at least) must be remembered:

  * the unit type (or "city", which can be treated as a special type
    of unit for this purpose)

  * the civilization which owns the city/unit

  * the unit's HP (percentage?), or the city's size

  * if a unit, that unit's activity (if any)

  * if multiple units, the "plus sign" (for a future CTP mode, we'd want
    the number of units in the stack)

The client's knowledge of all of this constitutes part of the state of
the game, and therefore must be saved.  Therefore it must be known to
the server as well as to the client.


Daniel Sjolie (deepone@xxxxxxxxxx) wrote:

> > If the client sends the map to the server for safekeeping anyway,
> > why not keep it in the server from the start ?
> 
> Because the server has no bussines tampering with that map!
> It is very much the right thing to do to have it in the client...

The client can't send its version of the map to the server -- see above.
Yes, we want to avoid duplicating information sent to the client --
once we've sent the map during a given session, there's no reason to
send it again unless the client's knowledge changes.

But when a saved game is resumed, the client starts with 0 knowledge.
It only knows what the server tells it, so the server must load the
client's knowledge-map and send it to the client.

> > This sort of spells doom for (ai) clients that plan to sent
> > huge amounts of data to the server for safekeeping -
> 
> Agreed, so let's solve it in anuther way... :)

That's an entirely different problem. :-(

-- 
Greg Wooledge                    | Distributed.NET http://www.distributed.net/
wooledge@xxxxxxxxxxx             | because a CPU is a terrible thing to waste.
http://www.kellnet.com/wooledge/ |