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.
Unreal Game Prototype
I stopped working on a Unity game prototype quite a while back for a game idea I really wanted to make. One of the reasons I stopped development was because I was becoming dissatisfied with the direction Unity was being taken in. I had always wanted to sink my teeth into an Unreal game project and develop those skills, and the pinch point was the Unity licensing debacle. After that I had decided I wouldn’t focus my energy on Unity anymore and any new personal projects I develop would be using the Unreal Engine. However, I’m not going to turn my back on over 10 years of Unity experience, that would be very shortsighted and naive. I still love the Unity Engine. It is incredibly easy to use, quick to prototype with and (as I would come to learn and understand) much easier to navigate than Unreal Engine.
C++ Terrain Generation
Now that I have working hex terrain generation prototype working in Unreal’s Blueprint system, it is time to throw it all in the bin and start over in C++. Why you ask? For a few reasons I answer. I like the Blueprint system a lot and it does seem pretty fast but ultimately I’m looking to build an infinite procedural world using hex-based chunks. I’m certain Blueprints can do it… and I’m pretty sure C++ can do it a lot faster. Additionally I want as much control over the procedural generation of the mesh, the subdividing and calculation of the height data as I can get and C++ will guarantee this too. Besides, with the complexity of the system I’m sure a Blueprint to handle what I want to do will end up looking like a lot of spaghetti and difficult to maintain. It’ll be much easier to handle things like caching of vertices and meshes in code. So why Blueprints in the first place? Mostly quick prototyping, feeling out the style and deciding if Unreal was actually the engine to do this in rather than Unity (I had already started on this project in Unity but had abandoned it for hopefully greener pastures).
World Position Aware Procgen
Before I can work on the Project Hex’s chunking system I need to ensure each of my hexagon terrain tiles generate height data topology that correctly matches up with its neighbours. The easiest way to do that is to base the Perlin noise calculation on world position, but its a little bit more complicated when dealing with scaling noise across different meshes. Regardless, it is still a function of world position but in my case I actually use a hex coordinate system (that will eventually be discussed in the Project Hex and so have to translate that into world position as well.
Runtime Chunk Loading
Hex terrain runtime chunk loading is now in and working well. Still not optimised yet but at this terrain resolution its not even breaking a sweat which is nice. Everything coded in C++ for the raw power. Eventually I’ll thread the mesh generation. I think it’ll be needed once I start layering the noise to make more realistic terrain.
Trees and Pseudo-Wireframe Shading
I have been experimenting with a shader that can draw the lines for both tri and quad edges (a sort of pseudo-wireframe shader) for my trees and other static meshes. Seems to be working decently enough. I’m embarrassed how long it took me to create that tree in Blender. I have no idea how 3D artists are able to put up with that terrible UX 😅
Rock And Roll
Finally found some time to work on my personal project and have been putting rocks into the chunk generation only for some of them to appear like they’ve fallen over or even spawned completely upside down.
Please note there is zero code in there for any kind of rotation. I eventually want variation but I’m not there yet. Very bizarre!
Working As Intended
I now have resource nodes (trees and rocks) spawning with the chunks. All looks perfectly normal, right? Cool. Task complete.
Feeling Treesick
Trees have been successfully attached to the ground. Now working on some windy tree swaying.
Yea, I’m having way too much fun with this! 😂
Gently Swaying In The Wind
I’ve got this really nice light wind loop going on now. The tree sway step is synchronised for all trees regardless of time of creation, but I’ve slightly offset it based on world X position to make it look like the breeze travels across the screen. There’s also a minor variation in sway amount. What do you all think?
What Is Project Hex?
Project Hex is the development code name for a personal gamedev project I’m creating in Unreal Engine. It’s a colourful lo-fi hex-based infinite procedurally generated terrain game. I have a pretty clear vision of what I want it to be in regards to genre and gameplay (and even have a few name ideas) but that’s all to come later on down the line. The ultimate goal of the project is pretty ambitious but the development will be separated into phases with each phase bringing in a core gameplay block that shouldn’t be too difficult to develop and launch by itself.
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.
Knightly Builds
Excuse the pun, I couldn’t help myself, and no, there definitely haven’t been any nightly builds either.
Now that’s out of the way, I’ve been growing tired of constantly looking at Manny (Unreal Engine’s prototype character mannequin) and he definitely doesn’t fit the style of the game. So he had to go… sorry Manny! In his place I’ve found an artist named Kay Lousberg (on Mastodon no less) who makes some absolutely amazing lofi art assets (ranging from character models and animations to props and structures). In fact, they’re so close to the colourful visual style I’m going for some of them may end up being part of the final game. I just wish they were more angular and they would be perfect. Anyway, check out their stuff at kaylousberg.itch.io.
