Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] updating tile visibility (was: Idea for 2.0)

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Reinier Post <rp@xxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>, Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: Re: [Freeciv-Dev] updating tile visibility (was: Idea for 2.0)
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Mon, 19 Jul 1999 07:19:01 -0400

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?


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

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