Re: [Freeciv-Dev] Idea for 2.0

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

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)
  {
    unit_move(client_units[player][unit_id],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..)

  Daniel

-- 
The only thing worse than infinite recursion is infinite recursion.