Re: [Freeciv-Dev] updating tile visibility (was: Idea for 2.0)

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

On Mon, Jul 19, 1999 at 09:54:35AM +0200, Reinier Post was heard to say:
> > How difficult
> > would it be to keep different id -> unit mappings for each client?  ie:
> > (obviously pseudocode :) )
> > 
> >   struct unit * client_units[MAX_PLAYERS][MAX_UNITS];
> >   /* Of course we probably really want a growable array, this is just an
> >    * example
> >    */
> 
> The unit list is a struct player attribute.  Why not have separate id
> spaces for each player's units?  All references to unit ids would need
> to be replaced with references to a particular player's unit ids.

  Yeah, that was what I was saying (I should have done it more succinctly :) )

  You'd have to have a master id list and then mappings to it for each player
(I think all server-side data should use the global mappings; they should only
 be converted when a packet is actually sent -- this also might automatically
 solve the problem of not sending updates for invisible units; just call the
 packet-sending function -- it'll silently drop the packet if the unit isn't
 in a player's visible list)

> > (we aren't really that
> > far from an X-type protocol where the clients are dumb interfaces to the
> > server, but this actually works here because the protocol is so high-level.
> > The only thing that it doesn't work with is play-by-email..)
> 
> I never studied the details of tile visibility, but it seems to me that
> the aim is to allow clients to maintain an up to date of all server side
> information they may need, to look ahead as much as possible.  The client
> is dumb in that it must not update any of this client-side information
> directly: update requests must be sent to the server, which will respond
> by returning the updated information.  Perhaps a more general solution is
> possible by putting all information the client is allowed to see under the
> player struct, and using a single server->client packet type to 'sync' the
> client side copy, issued whenever updates occur.  The game struct would
> become server side only, as it should be.

  Interesting.  What would it do to bandwidth?

  Daniel

-- 
  Catch an error-catch an error, coming through the stack...