Game Networking Resources

There are some pretty good resources on game networking out there, but they are pretty scattered and sometimes hard to find. To remedy this, in this post I’m going to collect all the good game networking links I know. Please share any links you would like to add in the comments section. Thanks!

First up is The Unreal Networking Model by Tim Sweeney. This article covers the concepts of writing a general purpose networking engine on top of a distributed object model. Take careful note of Tim’s ideas about bandwidth vs. CPU growth (still true today), his replication statement design, and the concept of authority enabling selective simulation on the client. Pay special attention to his explanation of client side prediction!

Of course, Tim’s document is very high-level. It doesn’t really explain how you would actually send that stuff over the network. That’s fine if you are going to use Unreal, but for the rest of us who want to write our own engine, there is The Tribes Networking Model. Key ideas include their notify protocol for reliability over UDP and their concept of independent event channels with different reliability guarantees. You can even take a look at the source code for this as part of their open source library OpenTNL. Lots of good stuff here.

Another way to synchronize your game data is via delta encoding as described in the Quake3 Networking Model. Here Brian Hook explains the technique developed by John Carmack for Quake3. The basic idea is to delta encode the entire game state, ensuring that everything gets across without needing to worry about the complexity of using events to synchronize state. Be careful though, because this technique is only applicable if you have a small set of data. Why? Well your packet needs to contain the *complete* difference between a previous base state and your new state, so don’t try using it for open world streaming games!

No networking resource list is complete without Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization by Yahn Bernier. This document describes the key techniques differentiating Counterstrike and Team Fortress 2 from the original Quake networking model, namely their latency compensation techniques for player aiming so you don’t have to lead the player by the round trip time (RTT). Take note because this technique is why these games are so goddamn popular, and simultaneously why they are so prone to cheating

Eventually you are going to have to get familiar with low-level networking issues, especially NAT (network address translation) routers and how to establish connections with players behind them. The standard technique for this is called “NAT Punch-through” and it basically involves “fooling” the router into exchanging packets it would otherwise would not allow. You can find a good overview of this technique here.

As you can imagine getting this working across every router ever made is very tricky. Even the big guys have trouble with it (EA, microsoft etc…). So don’t get arrogant and expect that you are going to get it right first time! Take my advice here and use an existing library that has already worked out all the kinks. If you are writing a PS3 game then PSN NP has matchmaking services for you that handles the NAT punch-through, as does XBox-Live on the 360. But, if you are on the PC you are SOL so take a look at one of the following libraries: OpenTNL, Raknet, Quazal. Do not write this yourself if you can possibly avoid it!

Ok that’s about it for now, I have a lot more docs to add, but that covers the big ones that should get you started.

Let me know in the comments if you have any other good docs to add, cheers!.