Client_Server

Client/Server

< Concepts

This article describes the different approaches to client server gaming. Based on the selected method of the game the start up is different, The client code handles the user interface (the game view). Interaction that change the game model (purchase of wares, ....) are forwareded to the server. The server holds the representation of the world model.

Standalone Game

The client and the server code run in the same virtual machine.

The game is started by starting the appplication. This starts the server which brings the start up screen. Choosing new Single player game starts a standalone game, The server creates a thread for the user interface and a second thread for all the AI players. The game is not turn based, it is however clock driven. With each clock the AI thread iterates through all AI players. The communication between client and server after startup is solely done through the Event System.

Multiplayer game

The client and the server runs in different virtual machines.

A multiplayer game is started by first starting the server (same code as in the standalone case) and then selecting the multiplayer game. This lets you select certain parameters (network port, number of human players, ...) and some game settings (start year, difficulty, ...). Then the client application is started. This is basically the same as the client code from the standalone application superimposed on a network layer. To start the client, a connection to the server must be established. Changes in the client are gathered and sent to the server. The server forwards this changes to the other clients. The server also handles additional AI players. The setup phase involves duplicating the models of the server on each client. After this is done the changes are communicated though the Event System which is transmitted through the network with the Transmission Protocol. Changes on the client side are gathered to minimize traffic and necessary update actions. Periodically the state of the clients models are compared with the server model state and if necessary overridden.

Loading a multiplayer game

The game is save on the server side. The server has a web interface for saving and loading. Once a game is started on the server the web interface can be accessed and the player can join the game by selecting their player.

Multiplayer game with game server

The client runs in a virtual machine of the player whereas the server runs on a game server.

The setup is basically the same as in Multiplayer game though without the need to start the server.

Event Updates

One on the main issues is to synchronize the state between client and server. In the case of a standalone application that is easy as the state will be represented by the same instance. However as soon as the server and the client are running in a different VM, they must synchronize using the existing Event System. Thereby attention has to be paid to not introduce circular events: Event producer consumes his own event and thereby creates a new event. As the same code base is to be used in both cases, the distributed system will need some wrapper around the state, which will provide the functionality of synchronization:

The state is only updated through the engines. Other entities may query the state through various interfaces, but not change it (hence the use of interfaces). In the case where the server is not equal to the client (distributed) an AOP advice will create a wrapper around the state object. The advice will handle the input parameter and create the appropriate event to synchronize. The event will not be published on the event bus but it will be passed to the Transmission Protocol, so the event will be created at the other end. There the advice will handle this special event and update the state.