Asteroid Belt Assault, the game I’m using as foundation for this series is basically a combination of Galaga and Asteroids. The player controls a spaceship that is flying through an asteroid belt. The asteroids themselves fly across the game screen and can bounce off each other. In addition to the asteroids the player is faced with waves of enemies that follow a pre-determined path and fire shots at the player. The player can move around the screen and fire his cannon at the enemies and asteroids.
There are various network topology choices available when making a multiplayer game. In this article series I will make use of a client-server architecture. I find that thinking about game networking in terms of a dedicated client and server helps me to better understand (and explain) what happens when.
In a pure client-server model the server typically handles all the game logic with a client being a dumb terminal only concerned with rendering the game state. This would be the easiest to program, but unfortunately in reality this model is not suitable due to latency and bandwidth constraints.
In order to mask the effects of network latency we need to do some processing of game logic on the client. There is therefore a lot of similarity between the game logic on the client and server, in fact they could essentially be the same code. So why do we need a server then?
The server is responsible for the game state, it needs to coordinate starting a game, ending a game and everything that happens in between. What this means is that the server in this game is responsible for generating our enemies, asteroids and making sure that the whole simulation remains in sync.
The following screenshot shows the solution structure for our game.
The actual game code is contained in the XNA (windows) project called MultiplayerGame with its associated content contained in the MultiplayerGameContent project.
The Client and Server projects are console projects used to start up separate instances of the MultiplayerGame project. The reason for this is to allow us to have both a client and server instance of the game while we’re debugging. To achieve this we set multiple startup projects as follows:
From the above solution structure you will notice that I didn’t create a separate client XNA game project and a separate server XNA game project. The reasoning is that the game itself is identical on both the server and the client except for who owns the game state i.e. the server.
In the next article I will cover setting up the connection between the client and the server.