Real-time Multiplayer Game

6.3.1 Rolf’s Blast

Rolf ’s Blast is a real-time multiplayer game, specially developed for this the-sis. A player can walk in a labyrinth and shoot at other players. Figure 6.3 shows a picture of the game. The score of a player is increased by one for each other player it shoots, and decreased by one each time it was hit by another player, whereby the score cannot become negative. The goal of the game is to have the highest score among the players, thus shoot as many others as possible and avoid to be shot by others.

Figure 6.3: Rolf’s Blast

If a player has shot or was hit by another player, it is not allowed to shoot for a certain period of time. Therewith it is avoided that a player constantly shoots or that a player that was hit directly repays the hit.

Each game instance can host two local players. For the name of a player that gets displayed in the score board of the game, the local host name together with a node local player identifier is used.

6.3 Real-time Multiplayer Game Chapter 6

Two versions of the game have been implemented, a peer-to-peer and a client/server based version (refer to Appendix A.1 for more information about game architectures). The peer-to-peer version of the game, which needs no service management by the Rosamon framework, was developed first to ascertain in more details the needs of games in a dynamic ad hoc environment. After this, Rosamon itself and the client/server based game version, which interacts with Rosamon, were implemented.

To simplify the analysis of the implementations, both game versions pos-sess an automatic mode for each player, therewith a player can act randomly on the playground without user intervention.

6.3.2 Rolf’s Blast: Peer-to-peer Version

In the peer-to-peer version of the game, each instance of the game is alone accountable for the state of its local players. The state of a player consists of its name, its node-local identifier, its score, its position on the playground and its firing status. Each time a local player acts, the corresponding game instance executes the action and sends the complete new state of the player to a predetermined broadcast address and port in the network, to inform the other peers about the action. To broadcast the message, also flooding as used in Rosamon is applicable (refer to Section 6.2).

If a local player shoots another player situated on a remote node, its score is not increased until the corresponding game instance receives an acknowl-edgement of the player that was shot. This mechanism avoids wrongful enrichment of a player as a result of an inconsistent game state, because of unreliable network connections and communication latency it cannot be ensured that all game instances possess over the same game state simulta-neously. For example, while a player shoots another player, the other player could already have moved to somewhere else on the playground.

A game instance that receives a state of a remote player updates its local game state accordingly. A possible fire action of a player is executed on each game instance individually, thus each game instance adapts the locally stored score of all players accordingly. If a local player of a game instance was hit by a remote player, the hit is acknowledged to the remote player game instance.

The reason that the firing of a player is executed on each game instance individually is that, on the one hand, this enables a more responsive and locally consistent reaction of the local game state, and on the other hand, possible network communication bursts caused by the synchronization effort to a player action are avoided. As a disadvantage, a potential discrepancy in the game state of the individual game instances could be temporary worsen.

But as in the entire game only one instance is ultimately responsible for the state of a player, the game state is globally considered unambiguous at any time and inconsistencies among the game instances disappear by the next sent player states, which are triggered by further actions of the players.

If for a certain time period no action was received from a remote player, it will be removed from the local state of each game instance, as this player is either inactive or has lost connection. This period will be even abbreviated, if a hit acknowledgement is expected from the remote player.

As always the complete player state is sent when a player acts, the remote game instances can easily take in a new or previously removed player. No additional coordination is needed to join or leave the game.

6.3.3 Rolf’s Blast: Client/Server Version

The client/server version of Rolf ’s Blast was developed starting from the peer-to-peer version of the game. The intention was more to have a service well-suited for the management inRosamon, as to develop a well-elaborated client/server based game.

The client instances of the game handle the interaction with the human players and the server manages the game state. Thus, each client just for-wards the desired action of a local player to the server and displays the game state as received from the server. Thereby the desired action of a local player is pre-examined on its validity by the client to avoid unnecessary network traffic. The server of the game executes the received action of the players and informs the clients about the new game state. Before a new player can join the game it has to first register himself with its desired name to the server.

While for the communication from the client to the server unicast is used, the server informs its client about the actual game state straightfor-ward with a broadcast message. It may be appropriate to use also unicast