The IOs of Game Netcode
I’ve done a lot of coding over the years and learnt a substantial amount, either through reading tutorials, looking at examples, trial and error, reverse engineering, etc. So I’ve come to think I have a wealth of knowledge regarding the subject these days. For a long time I’ve been thinking that I’d like to give back in some way. So after some thought on what I could share I’ve come to realise that nearly all of the games and other projects I have worked on have networking implemented in some form or other, and for the most part, this has all been developed from the ground up with very little library use (you can take this as good or bad, probably a bit of both).
A Few Rules Of Thumb
First of all, welcome to the series! 🙂 This first instalment of The IOs of Game Netcode will cover a few rules that I’ve come to follow whenever I approach a new netcode project. Now, as I’ve been writing this I’ve come to realise that because netcode is mainly backend code, there isn’t going to be a whole lot to look at except large walls of text. I’m afraid I can’t do much about that.
Threading and Concurrency
In the last post of The IOs of Game Netcode, I talked about a few general rules of thumb I usually follow when starting a new netcode framework. Over the next few posts I’m going to go a little deeper into the technical options available to us as netcode developers and what routes I take based on different scenarios. The first topic I’m going to start with is threading, and the resulting issue – concurrency.
Synchronisation and Locks
We’ve already established you need to run your netcode framework on a different thread to your main game’s update/render loop, something which all netcode developers will agree is a requirement for writing good netcode. This means you’re already in danger of the threading and concurrency issues mentioned in the last post. So how do you ensure that you don’t run into these issues? Well, you have a few weapons in your arsenal to tackle the problem.
Blocking and Non-Blocking Sockets
In this post, we’re finally back onto some netcode stuff. We’re going to address the differences between blocking and non-blocking sockets. Both types are usually provided by the socket implementation that comes with your OS, or are provided as part of the standard library for that particular language. In addition, they may also be wrapped into a single interface, simply operating in different modes (blocking or non-blocking mode) or separate interfaces, one dedicated for each.
New Project, New Devblog
No, no, you’re not crazy. There are posts that precede this first devblog post. I’ve had several blogs in the past of various types but I’ve actually never had a personal development blog of my own. I usually am writing up of my development progress or articles on other sites like the Rogue Vector website or social media platforms such as LinkedIn and Mastodon.
However, with this new personal project I’m working on (Project Hex), I wanted a more permament and singular place to show my development progress and for any articles I write. Additionally, I am in the process of copying a lot of my social media posts about Project Hex to this devblog because there’s some good stuff there I don’t want to lose. I’ll definitely be rewriting the posts a bit to make them more blog relevant than social media. At the same time I’ve copied my The IOs of Game Netcode articles from Rogue Vector so they can live here as well. Be warned though, they were written 10 years ago and the information may not be accurate or correctly reflect my opinions any more, but there’s some useful stuff there and I definitely want to update them at some point and continue the series as well.
You’ll probably want to start with Unreal Game Prototype.