Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Idea for 2.0

Re: [Freeciv-Dev] Idea for 2.0

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Artur Biesiadowski <abies@xxxxxxxxx>
Cc: Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: Re: [Freeciv-Dev] Idea for 2.0
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Sun, 18 Jul 1999 12:48:26 -0400

On Sun, Jul 18, 1999 at 05:11:32PM +0200, Artur Biesiadowski was heard to say:
> Greg Wooledge wrote:
> > 
> > Yes, but that unique ID number is a secret that should be known only to
> > the server.  The client should not know it.
> Of course not.
> In that case server could get away with pointers only. ID is needed to
> communicate with client. In other case how would you pass changes in
> info about units ? To decrease hp of unit you would need to reference
> not simple id, but position on board + number of unit on that field - a
> lot of bookeeping. And how to do finding units supported by given city ?
> It would have to go through server (and now can be done in client).
> IT IS POSSIBLE to do all without ids, but if we will go that way, we may
> end with client getting prerendered images from server and sending raw
> mouse/keyboard events back (Xserver ?)
> Artur

  It's been a while since I poked around in this bit of the code.  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

  handle_unit_move_from_player(int player,int unit_id, move_type *move)

  I suppose that we'd have to either hash the unit tables or keep reverse
mapping info in the unit struct (the latter is simpler and perhaps even more
efficient) -- use -1 to indicate that a player cannot see a given unit.  So
when a unit moves, we check whether it will move into any players' visions and
add it to the unit lists for those players, then send a 'unit moved' packet
(making the animation occur), then delete it from the lists for clients that
can't see it anymore (and send a "unit vanished" packet).

  There are some intricacies (esp. how to add units without incurring an
O(n) hit while we try to find the first empty slot -- can we make an empty-slot
queue or something?), but it seems doable to me, and I think keeping as much
game logic as possible server-side is a good idea.  (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..)


The only thing worse than infinite recursion is infinite recursion.

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