I wrote some comments on game networking last November, but we’re still seeing games with the same issues, so I’m going to add a few more recommendations.
In comparison to other technologies, basic sockets programming hasn’t changed much over the past 10 years. 10 years ago, game programmers were writing Direct3D 3.0 code. Today they’re writing D3D10 code. Playstation was the latest console 10 years ago. Today it’s Xbox 360 and PS3. The Winsock of 10 years ago, however, is the same as the Winsock today, and the same techniques still apply:
- Avoid small payloads. The packet overhead kills your bandwidth.
- Don’t send data too often. The best networked games send packets 10-20 times per second.
- Prefer UDP over TCP. The overhead of UDP is smaller, plus UDP doesn’t automatically resend dropped packets like TCP.
- Assume that it could take seconds for packets to arrive at their destination and build your engine accordingly. The Internet does not have the same characteristics as a local network.
- Don’t assume your packets will arrive at their destination. The Internet is a crazy place.
- Consider some form of secure packet authentication scheme. Hackers love to modify packets. Some platforms provide this feature automatically (Xbox) or provide it in library form. For games, it’s usually worth the effort to protect your packet data.
- Consider some form of packet encryption. Even if packets are authenticated (can’t be changed), hackers can still cheat just be looking at packet data and dropping specific packets on the floor.
Building a good networking engine is hard, and it’s not glamorous work, either. But your game players will definitely notice if you’ve spent the time to do it right.