ClientServerDesign

Widelands implements multiplayer games with parallel simulation. This means that every system that takes part in the game is simulating the whole game. The players on different systems send commands to the host system, which checks that the commands are allowed, and then sends them to all systems, where they are taken into the simulation. This technology is good for keeping network traffic low. But one feature is simply impossible to get; exploration. Since every user is on a system that does the whole simulation, he has complete knowledge (like in chess).

But exploration is a very interesting and enjoyable feature of a game, so it seems worthwhile to implement multiplayer support in a way that allows it. This means a client/server architecture. The server runs the simulation and sends information to each player's client(s) when he sees it according to the game rules.

Here follows an estimate of how much network traffic would be needed.

Each player knows everything about himself, so there is no need to send frequent updates about the movements of the player's own units. The server just has to tell the client the path that the unit is going to walk. Then the client knows all that it needs to know. (If something exceptional happens, the server must of course inform the client.)

The units of other players need some more traffic since the player must not know the unit's path in advance. It must only know that it is moving along a certain edge at a certain speed. This is handled with so called unit sightings. A unit sighting is a small data structure that is created when a player starts seeing a unit of another player. The player is informed about the unit's type, location, speed, carried item, health and whatever. An ID is created for the unit sighting. This sighting is then updated and eventually destroyed when the unit moves out of the player's view.

When the sighted unit starts walking along the next edge, the player needs an update. Suppose that such an update can be squeezed into 24 bit (1 bit indicating that the packet is a unit sighting update, 18 bit ID (which unit sighting it is about, 3 bit new walking direction). (The client can infer the walking speed since it knows the game rules, unit type, slope, terrain, and such.) Suppose that it takes on average a second for a unit to walk an edge. Then it takes 24 bit/s to maintain a unit sighting. A very high number of unit sightings, say 2^17 (= 131 072) would need 3 Mbit/s to maintain. This speed is already possible for many people today and will be common when we have a working implementation ready for them to play.

Note that most of the units that a player sees will be his own units, which do not require such regular updates.

So according to this calculation, it would be possible to implement and use a client/server design with a reasonable network traffic. The worst-case traffic to a client would be 3Mbit (when he sees 131 072 enemy units, a very high number that will not actually be reached in the foreseeable future).

In this example calculation, the network protocol is designed so that the packet that is estimated to be bandwidth-critical will be as small as possible. It will only have 1 bit of packet type signature. If that bit is 1, it is a unit sighting packet. If the bit is 0, it is another kind of packet. Then the following bits determines which kind. So less common packet types will have longer signatures. Examples of other packet types are unit sighting health change, and unit sighting appearance (when it walks into the player's active vision). Note that no packet is needed when a unit sighting disappears. The client knows when this happens, since it know the extent of the player's vision and where the unit is going. So both client and server deallocate the unit sighting when it walks out of active vision.