Converting an Existing XNA Game into a Networked Multiplayer One

Video demo is at the end.

In the GAM490 – Multiplayer Networking for Games class that I took at DePaul University, we studied a lot of interesting networking topics and then tried to apply them on a game-development related project. In order to prepare for that final networked game project, we studied and implemented best ways to serialize objects, taking into consideration the data sizes and their alignment requirements, so that objects can be efficiently stored and transferred over the network. Each student implemented his own TCP and UDP servers and clients using Windows Sockets, in order to understand the differences between the two protocols. We also studied how to write good data-driven programs employing input and output queues in order to make the processing of sent and received networked packets over the network simple and easy.

For the final project, we were supplied by and XNA game written by a previous student that each student was required to individually convert it into a networked multiplayer game. The requirements of the final game were:

• Refactor the game code to make it completely data-driven using input and output queues to process the different game events.
• Adding the ability to create a multiplayer network session either as an XNA system link, or an Xbox Live session. Each player must be able to either create a network session or join an existing one.
• Adding a Game Lobby screen, in which players can view other players joined in the current session and from there they can start playing the game.
• The game must be multiplayer playable on two separate machines connected by the network, and the game play must be exactly as that of the original locally-playable game.
• The game must include network quality simulation configurations, simulating different network latencies, and percent packet loss.
• The game must implement prediction and smoothing algorithms to account for the network latency and packet loss.
• The game must be developed as incremental submission to Perforce with detailed description of each submission.
• Detailed design documents must be submitted.

I had to choose between implementing the network topology of the game as a peer-to-peer topology or a client-server topology. I went for peer-to-peer as I thought it would be easier to implement since the game is a two-player one only, but in fact it was more challenging to implement as I had to deal with a lot of synchronization issues between the two machines which occur due to the network latency and the packet losses. To deal with these issues, good smoothing and prediction algorithms were very important.

Periodic update packets were added to the game to account for any losses. The number of these packets per one frame is adjustable by the game host, and they only contain the ships’ positions and rotations. Smoothing is done by linearly interpolating between the current ships position and rotation values and the new ones received from the newest periodic update. This makes the transition from an old value to a new value appear to be very smooth.

For the prediction, my algorithm is very simple. It starts by calculating the latency; i.e. the time it took the newly received periodic update packet to be delivered. Use this latency value to try to predict where the ship should have been now had this packet arrived on time.

Testing and debugging this game was a challenge, since I had to use two machines and constantly synchronize any code changes between the two. Perforce was very important for this project.

The final game is reviewed in the below video.