Re: [Freeciv-Dev] Idea for 2.0

[Daniel Sjolie <deepone@xxxxxxxxxx>]

On 1999-07-15 18:55:52, Greg Wooledge wrote:
> 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.... :-/

Well, I did...

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

If the client generates the 'foggy' map this issue never comes into
question...

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

Uhh? I don't see any reasons for that to be infeisable above...

> Peter Schaefer (schaefer@xxxxxx) wrote:
> 
> > Generating it in the client and sending for safekeeping is
> > bad for traffic reasons. 
> 
> That, too. ;-)

That is the only concern if You ask me...
And it can be dealt with by only sending updates...
So the actual data would be on the server but not the structure...

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

Don't You see that it is an incredible lot easier to do this in the
client??? Simply only send the client information it really can see!
The 'foggy' map is *completely* the clients bussines!

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

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

Who has ever talked about sending the client maps more than once???

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

Again, if the client is to be *anything* but stupid it needs to be able
to keep data in the server just for safe keeping...
It does *not* have to mean a lot of traffic...

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

No! It's not!

So, keep the data in the server but the code in the client...
Give each client a place in the server to store its info and construct a
general packettype for updating this data... This certainly should be
able to do without getting to much traffic...

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)