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

[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: freeciv-dev@xxxxxxxxxxx (Freeciv developers)
Cc: Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: [Freeciv-Dev] updating tile visibility (was: Idea for 2.0)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Mon, 19 Jul 1999 09:54:35 +0200

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

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

>   Daniel

-- 
Reinier Post

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