Progress Update

Photo by Hayley Murray on Unsplash

It has been a long time since the last update, but for good reason. The easier part, building out the smart contracts and the blockchain code, is completed and we’re in the midst of the much longer part — building out the game infrastructure for online play.

The online game infrastructure is something that has always been expected to be a major challenge. Any sufficient online game needs to be planned out and architected from the ground up in order to meet the challenges of the game on which it will be built. It’s typically why most online games don’t use many of the “shake and bake” networking stacks — they aren’t optimized for the style of game and you’ll have to make substantial changes to them to work your game onto that stack. Since I’d spent a LOT of time doing this previously (and Unity’s network stack remains — “less capable” than what we need), it became time to roll up the sleeves and do the unpleasant thing of building a network stack from scratch. But what does that really mean?

In a server-authoritative game, the server is the “authority” on what is really happening in the game. The players trust that if they need to know what’s happening, they can reach out to the server and what it says is accurate. This is different from pure peer-to-peer networking stacks where one of the clients acts as both the “relay” server and as one of the participants.

Server-authoritative persistent gaming comes with a large number of challenges, and the past few months were spent resolving SOME of those challenges. There are many others still left to tackle, but with the help of Google’s Framebuffers and a LOT of Rust code, the server code is starting to shape up into something that can handle the task — and do it substantially better than Unity’s Netcode for GameObjects. Automated testing has already started and the number of players (not going to disclose that — don’t ask) is actually very impressive. We’re in business, but there is still a LOT to be done to manage player desync (i.e. if you’re interacting with a loot box — other players should be able to observe you doing it — if they observe you walking around or still fighting the enemy that dropped the loot box you’re not in sync… or desynchronized). We’re not building a 1st person shooter so that helps a LOT (those infrastructures look a lot different from what we’ve built here), but the style of game that’s we’re building demands a lot of state management which is a different, no less difficult, challenge.