Every now and then an idea plants itself in my head that I want to pursue so much, it barely leaves any space in my mind to concentrate on other things.
This is how it always starts. You could almost say it consumes me until I either sketch it out and realize just how stupid it was or until I actually build the thing and hopefully make someone's life just a little bit better.
One of my greatest interests lies in building multiplayer games. Specifically around game server architectures and the intricacies of network code. It's one of the heavier topics in video game development due to its complexity and abstraction and so it's actually not easy to find up-to-date and relevant information on the matter. It's one of the things I tend to explore and blog about in my personal blog over on Medium.
The most typical model you see in the space nowadays is called a (centralized) authoritative game server architecture. In its essence, it's a model where a game company runs a fleet of game servers - on-premise or in the cloud - to serve players through dumbed-down clients. The role of the server is to validate every single move of the player, while the role of the client is to convey inputs from the player to the server. Of course, as with everything, there are hundreds of layers of detail between these two high-level steps, but at the end of the day it all boils down to this.
Infrastructure management and costs at scale can be quite hefty. It's a complex area with loads of nuance to it that we don't need to get into right now. Not only that, but there's also input validation, cheat detection, bot detection and all sorts of other fun topics to keep in mind.
There are, of course, alternatives. P2P used to be the go-to strategy a decade or two ago, where a player from the lobby took on the role of the game host. This came with its own set of challenges; most notably NAT hole punching and unfair advantages due to the host having 0 ping. It was also in an era of pretty spotty and weak internet connections rendering the topic even more complicated.
Then there's server hosting companies, such as Photon. The idea is noble, but you lose a lot of flexibility. Plus if you actually want to have control over the server-side logic instead of just using a relay server for proxying messages, you still end up having to deploy and manage your own game servers. Granted Photon makes it easier and abstracts away some of the complexity, especially around match making, but the point still stands.
However, what if there's a way we can take some of these learnings and put the best of them into a new solution? What if someone else can run a game server for you and you, your player and them would benefit from it? What if there was an ecosystem that rewards all its actors and makes it easier to build multiplayer games?
These are some of the questions banging on the doors of my mind that I'm looking to explore in this new series of blog posts. I don't know if I will succeed. I don't know if I can find satisfying and tangible answers to all of them. But I will try.
Join me on this journey if this is something that interests you.
I already have some of the basics sketched out in my handy notebook. I'm going to digitize those thoughts and share them in the next episode of this series. We are going to take a look at the basic roles and responsibilities of a system like this. We'll explore the core principles of blockchains and how we can apply them here while also avoiding bringing over the whole bubble of speculative investment nature of the space. It's going to be a fun journey!