As we work hard to make our stonepunk arena action game Antegods a reality, you can stay up to date on the nitty-gritty of development with regular blogposts from our design, art and code departments. This time, lead programmer Niels shares some insights into our networking code. How do we make those infernal PC machines talk to each other?
P2P or client-server
We’ve shown Antegods at several events, and for these occasions we obviously had to have a working, networked multiplayer game. This meant that we had to make a couple of important decisions early on.
The first decision: whether we wanted to make it peer-to-peer (P2P) or client-server. And if we went for client-server, whether we wanted to use dedicated servers or allow gamers to host servers themselves.
There are some advantages to going P2P over client-server, and definitely some disadvantages too.
Advantages of P2P:
- Game is always playable: when the server disconnects, everyone else can continue;
- Best game feel (input is handled locally and directly);
- Cheaper (no need to pay for dedicated servers).
Disadvantages of P2P:
- Cheating is easier;
- Latency is higher on average;
- Requires more bandwidth (compared to client-server).
We had quite a bit of experience doing client-server, as that’s how ibb & obb and Terraria’s netcode work. However, we also knew that for a fast-paced game such as Antegods, giving players direct control over their totems would be vital to the experience. That’s why Antegods will use a fully meshed P2P system, similar to the way Ronimo’s Awesomenauts handles its networking.
Networking libraries
Tom Jansen wrote a middleware library with the imaginative name ‘Network Plugin’, which we used. This initial implementation used lidgren3 as its underlying data sending library, however lidgren had some requirements that didn’t really match with what we needed.
Specifically, it required a master server for matchmaking, or finding other clients. This wasn’t an issue for us at the start, as we would only play on a LAN for the time being, and we’d just host our master server on a local machine. When going to events, it’d be hosted on one of our Steam Boxes and locally connected with static IPs, making it easy for each other to find a game.
As you can see, the Steam Boxes are connected with green CAT cables through a small switch. If needed, the switch allows us to connect the machines to the internet.
Having a master server create a connection between two peers can become quite problematic when you want to play online. Stuff like NAT punching, dropped packets, bandwidth and latency all suddenly matter.
Lidgren supports handling NAT punching and dealing with dropped packets. However, we found a blogpost from the team behind RUST, saying they switched from lidgren to raknet. Now we had experience with raknet, and can definitely recommend it when doing a C++ project… but Antegods is a C# project. We researched compiling raknet so it could be used directly from C# code, and we had it working. But ultimately we decided that possible debugging issues and maintaining the C++ code would’ve been problematic.
In the end we decided to run with the Steam library. This is also C++, but there’s a publicly maintained C# version named steamworks.NET. Debugging will still be troublesome, but at least we won’t be alone!
With this we’re one step closer to getting to a beta or even a public release of the game. All that is still far off, but we’ve taken a huge step in the right direction.
I’ll talk more about our netcode in the future. If you have any questions in the meantime, feel free to leave a comment or send me a tweet at @nielsuiterwijk.
Social media
To follow our development updates, please check us out on Tumblr, Twitter or Facebook. Or subscribe to our newsletter. Whatever is your taste in social media!
Antegods is supported by the Dutch Cultural Media Fund, Cultural Industries Fund NL and the MEDIA Programme of the European Union.
