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

Re: [Freeciv-Dev] Idea for 2.0

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: Re: [Freeciv-Dev] Idea for 2.0
From: Andy Black <ablack@xxxxxxxxxxxxxx>
Date: Fri, 16 Jul 1999 20:54:29 -0600

At 5:24 PM +0200 7/15/99, Artur Biesiadowski wrote:
>Peter Schaefer wrote:
>
>>
>> Ok, maybe that was not a good enough point - here is a better one:
>> If the client sends the map to the server for safekeeping anyway,
>> why not keep it in the server from the start ?
>>
>> Last time I played on a small connection, downloading
>> the map took very long - so I think yes, it matters.
>
>I don't think that it is possible to avoid transmiting vital statistics
>during reconnect/load game. During that time entire map can be send in
>one packet - it would be not a lot of data (40k ?)
>
>For now it seems that every map is send by one tile at time. It might be
>good in some cases, but when for example two players exchange maps in
>late game it is an overkill (if I understand it correctly each tile is
>
>short length;
>char packet_type;
>int x;
>int y;
>int type;
>int special;
>int known;

How about sending the tile data in a 2d array containg the folowing items
struct tile_data {
  int turn;
  enum tile_terrain_type type;
  enum tile_special_type special;
};

The packet data could look something like the folowing
short length;
char packet_type;
int x_start;
int y_start;
int x_length;
int y_length;
struct tile_data[x_length][y_length];

Because the length varies, we would need to use maloc for storing the data
untill it is coppied to the user's map data.

The turn field is probably the most efficent way to determine who knows
what about the tile.  If the turn field is 0, the tile has not been
discovered.  When the turn filed is greater than 0, that was the turn that
tile was last seen. That data is important with minor things like that
fog-of-war idea. Actually, the packet doesn't even need to include the turn
id, just use T_UNKNOWN for terain type.  However, the server needs the turn
id.  When one civ learns about another civ's map, you look to see who has
the most recent information about each tile, use that information, then
send out a fresh map.

On the topic of maps, prehaps the spy should be able to steal the maps from
other civilizations.  I belive that function is known as gathering
inteligence :-).

>Which gives 23 bytes per tile - compared to maybe 4 that are really
>needed (only type and special are needed - and surely not 32 bits for
>each, unknown can be represented by another terrain type). A lot of
>overhead.

in enum tile_terain_type, move T_UNKNOWN to spot 0.

>BTW, maybe we can just use terrain type VOID for representing unknown
>tiles ? This way map would be a bit more consistent - no need to check
>special case of non-known tile ?
>
>Artur


Andy Black



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