doc/README.attributes

   1
   2 Client/server model
   3 ===================
   4
   5 Each client player has an attribute block and the server also holds
   6 such an attribute block for every player. All attribute blocks the
   7 server holds are included in the save game. The client and server
   8 synchronize their blocks. The server sends its block to the client at
   9 game start or reload. The client sends an updated block at each end of
  10 turn to the server. Since the maximum packet size is limited to
  11 currently 4k and the attribute block can have arbitrary size (although
  12 limited to 64k in this initial version) the attribute block can't be
  13 transferred in one packet. So the attribute block is divided into
  14 attribute chunks which are reassembled at the receiver. No part of the
  15 server knows any inner structure of the attribute block. For the
  16 server an attribute block is just a block of bytes.
  17
  18 User interface
  19 ==============
  20
  21 Since an attribute block isn't a good user interface the user can
  22 access the attributes through a mapping/dictionary/hashmap/hashtable
  23 interface. This hashtable will get serialized to the attribute block
  24 and the other direction around. The key of the hashtable consists of:
  25 the (real) key, x, y and an id. The (real) key is an integer which
  26 defines the use and format of this attribute. The values of the
  27 hashtable can have arbitrary length. The internal structure of an
  28 value is unknown to the attribute handling.
  29
  30 For easier access there are wrapper functions for the common types
  31 unit, city, player and tile. So there are easy methods for attaching
  32 arbitrary data to a unit, a city, a player (self or other) or a tile.