Freeciv

ai: the ai, later linked into the server

tools: freeciv support executables

that C++ add-ons (particularly new clients) are possible. See the

CodingStyle file for more.

handle_remove_unit(), and finally the unit is disbanded.

Notice that the two packets (PACKET_UNIT_DISBAND and

PACKET_UNIT_BUILD_CITY and PACKET_UNIT_CHANGE_HOMECITY.

When adding a new packet type, check to see if you can reuse some of the

- the data send to a reconnecting player

- the end turn activities

functions, when something happens on the client socket.

=========================================================================

may be readable by some clients).

If you alter the graphics, then make sure that the background remains

generated properly, which will certainly not give any good results.

Each terrain tile is drawn in 16 versions, all the combinations with

forests and rivers are treated in special cases.

Isometric tilesets are drawn in a similar way to how civ2 draws (that's

"dither" in the code.

Non-isometric tilesets draw the tiles in the "original" freeciv way,

each tile, so that a different copy can be drawn depending the terrain

this to the civ2 system.

=========================================================================

Different types of map topology

=========================================================================

a 5x3 map would be conceptualized as

<- XXXXX ->

<- XXXXX ->

and it looks just like that under "overhead" (non-isometric) view (the

client, the same map will look like

X

X X

x

conceptualized as

<- X X X X X ->

Of course under an overhead-view client it will again turn out badly.

Both types of maps can easily wrap in either direction: north-south or

in the east-west direction.

=========================================================================

=========================================================================

In Freeciv, we have the general concept of a "position" or "tile". A tile

becomes important when we start to use non-standard maps (see above).

Here is a diagram of coordinate conversions for a classical map.

- Map (or "standard") coordinates.

the local geometry of square tiles, but do not represent the global map

square tiles) that the tile adjacency rules

(map_x-1, map_y-1) (map_x, map_y-1) (map_x+1, map_y-1)

- Natural coordinates.

Natural coordinates preserve the geometry of map coordinates, but also have

most operations because of their sparseness - they may not have the same

scale as map coordinates and, in the iso case, there are gaps in the

natural representation of a map.

is needed.

Native coordinates compress the map into a continuous rectangle; the

above iso-rectangular map is represented in native coordinates by

compressing the natural representation in the X axis to get the

3x3 iso-rectangle of

GHI (0,2) (1,2) (3,2)

The resulting coordinate system is much easier to use than map

operations (e.g., normalize_map_pos, whole_map_iterate) as well as

storage (in map.tiles and savegames, for instance).

- Index coordinates.

Index coordinates simply reorder the map into a continuous (filled-in)

the ordering of the tiles in native coordinates, and is slightly

easier to use for some operations (like storage) because it is

of the positions within the system.

Indexes can be easily converted to native coordinates using

An map index can tested using the CHECK_INDEX macro.

With a classical rectangular map, the first three coordinate systems are

introduced "map_x/map_y" or "nat_x/nat_y" to help distinguish whether

rigorous in keeping them apart, and will often just name their variables

Note that if you don't need to do some abstract geometry exploit, you

will mostly use tile pointers, and give to map.[ch] tools the ability

=========================================================================

An isometric map is defined by the operation that converts between map

Converting from map to native coordinates involves a pi/2 rotation (which

scales in each dimension by sqrt(2)) followed by a compression in the X

"normal set" of native coordinates is defined as

{(x, y) | x: [0..map.xsize) and y: [0..map.ysize)}

while the normal set of map coordinates must satisfy x >= 0 and y >= 0.

TILE_KNOWN_UNSEEN is a tile of which the user knows the terrain,

but not recent cities, roads, etc.

past, UNKNOWN tiles that were adjacent to UNSEEN or SEEN were sent to make

exploring new land may sometimes change the appearance of existing land (but

this is not fundamentally different from what might happen when you

goto code but allowed cheating.

Fog of war is the fact that even when you have seen a tile once you are

and

void fog_area(struct player *pplayer, int x, int y, int len)

functions. "int len" is the radius of the area that should be

track of fog of war, these functions also make sure to reveal TILE_UNKNOWN

tiles you get near, and send info about TILE_UNKNOWN tiles near that the

client needs for drawing. They then send the tiles to

Player-related entities in Freeciv - by Reinier Post <reinpost@win.tue.nl>

+ by dwp@mso.anu.edu.au

Freeciv games, you'll notice that the participants are called 'players'.

At the same time, players seem to be identified with civilizations.

On the other hand, civilizations seem to be identified by 'nation':

+ connection

Records a client connection; like a user, but disappears when the user

disconnects, whereas for real users we may want to remember them between

Where do these entities exist?

Nations aren't actually used for anything that matters; for them,

so the question isn't very interesting.

on a different server; the players will be the same. A new game will

client only has one instantiated player.

be possible to assign different levels of access to commands to different

survive the addition and removal of other players, the start or restart

of a game, reconnections by the same user even from different computers,

may have different levels of access in different games.

While they last, connections are sufficient identification for users.

Ideally, users would be identified with unique global ids, handed out

by a 'registry service' similar to the metaserver, but this would be

a server session (even whan a game is started, or restarted when that

option is added) and make them persist across games (when a saved

game is loaded in a different server session).

Users will be created when they first connect to a server, remembered by

be sent a unique session id, generated when the server started, plus a

fresh user id; it will store them in a ~/.civcookie file, and send it

reconnect; 'unprotected' ones allow anyone to connect; server commands

and probably client options will be available to control this.

----

THE PRESENT IMPLEMENTATION:

access levels to be assigned to each individual connected player, which

would not be the case if they were directly assigned to the player struct

(due to the fact that the players array changes when players are added or

But that's it.

Players are still created before the game is started, and player names

Server ids do not exist at all.

Commands to protect/unprotect users do not yet exist; they would serve

'player' means a civilization, see above), where each connection may

be either an "observer" or "controller".

only has one real connection (client.conn) -- its connection to the

server -- though it does use some other connection structs (currently

pplayer->conn) to store information about other connected clients

In the old paradigm, server code would usually send information to a

single player, or to all connected players (usually represented by

should be sent to a single connection, or to all connections for a

this, "destinations" should now be specified as a pointer to a struct

commonly applicable lists are maintained:

game.all_connections - all connections

game.est_connections - established connections

pplayer->connections - connections for specific player

pconn->self - single connection (as list)

1. (pconn->used == 0) Not a real connection (closed/unused), should

not exist in any list of have any information sent to it.

2. (pconn->established == 0) TCP connection has been made, but initial

Freeciv packets have not yet been negotiated (join_game etc).

information except directly as result of join_game etc packets,

or server shutdown, or connection close, etc.

(All following cases exist in game.est_connections.)

3. (pconn->player == NULL) Connection has been established, but is not

the plan is to allow this in future, so clients can connect and

then see list of players to choose from, or just control the server

or observe etc. Two subcases:

information about other clients, game status etc, but not map,

units, cities, etc.

(All following cases exist in game.game_connections.)

map, units, cities, etc.

4. (pconn->player != NULL) Connected to specific player, either as

Exists in game.game_connections, and in pconn->player->connections.

Macros and inline functions

===========================================================================

use of other C99 features and some new requirements by the code, this has

This causes problems because one coder may prefer to use a macro while

discretion to the author about whether to use a function or a macro; all

we've done is add even more choices.

Therefore the following guidelines should be followed:

- Functions should only be put into header files when doing so makes a

inlined unless there is a reason to do so.

- Macros that take function-like parameters should evaluate each parameter

named in all upper-case letters as a MACRO.

- Iterator macros should respect "break".

The data_encoding is used in all data files and network transactions.

This is UTF-8.

charset is the same as your GUI library, GUI writing is easier.)

under our control, and all output to the command line must be converted.

===========================================================================