Designing Client-Server Games

We have mastered the basics of network and socket programming, so let's put on a designer's hat for a second and try to relate all this knowledge to a real game. Fundamentally, all the preceding sections expose the tools we have access to. Thinking about the goals for a moment will provide some perspective and focus. In this section, I will focus on a small area game (8 to 16 players), whereas the next section deals with massively multiplayer game design issues.

In a small area game, all players are running a game client, and one player (usually the one with the fastest computer and Internet connection) runs the server as well. This is the main reason that these games must maintain reduced user groups. A larger user base would make the server too resource consuming, and running a client and server on the same machine would become unfeasible.

In Figure 10.3, the architecture for this kind of system implies that the user running the server starts a new game, putting the server in an accept() call. This is usually performed through a "game lobby." At this point in time, the other users join the game, so the server can effectively stop accepting any further calls. Once the multiplayer game begins, no one can join until the server enters the lobby again.

Figure 10.3. UDP acts like a data relay, whereas TCP maintains session control and manages the game lobby.

This allows the game server to easily blend inside the main game engine, using the following algorithm:

Server, step 1: Create socket, and bind to IP and port.

Server, step 2: Listen, and wait in an accept call. Open "game lobby" and show IP/port.

Server, step 3: Now the server is awaiting connections. Two threads/processes are required: an interface thread running the game menu interaction and another running the accept call so the system does not lock.

Client, steps 1 to N: Open socket, and connect to the game server.

Server, step 4: Update screen for each accepted connection. Implement the desired connection policy (connectionless iterative, connection-oriented concurrent).

Server, steps N+1: At this point, all the clients are connected to the server. When the game menu interaction thread indicates a player has started the game, you can effectively close the main server socket, interrupt the accept call, and start the game with the connection sockets. The game server thus shuts down and accepts no further connections.

This method allows us to simplify our game code. The game server only works at boot time, and afterward it is all a data transfer issue. But there are some potential pitfalls we must be aware of.

What happens when a player loses his connection? The server will realize this either by the socket closing or simply by not receiving data over a long period of time. As soon as we detect this inconvenience, we must create a new socket, put it in accept mode, and wait for the lost user to (hopefully) resurface.