Hello game developers!
A few months back I got into building high-frequency (realtime) multiplayer games to get my boss's attention. Ben Gamble is extremely passionate about game development, and it’s impossible to have a tech conversation with him without game dev coming up.
When I started, I had so many misconceptions about game dev. I underestimated certain aspects and had misconceptions about scalable game architectures. But I've learned so much about it since then and have built multiplayer versions of a few classics such as Multiplayer Space Invaders and Multiplayer Flappy Birds.
Since then, I have extensively written and spoken about game dev on various platforms. For each such presentation, I made improvements to the games by not only making them more efficient but also having them use the best and latest features of the underlying programming language. For example, I used Node.js worker threads (which was released as a stable version in January 2020) to simulate the idea of having multiple game rooms so different groups of people can play the game simultaneously. Ably's namepace feature made this strategy possible by ensuring none of the rooms had any access to the data from the other
A look at some of the many challenges of implementing a client-side WebSocket solution for realtime apps built with Node.js.
More games = boilerplate?
I continued to think of more multiplayer game ideas that were cool enough to convince my team to let me work on them during working hours, but I realized there are some commonalities in all these projects.
All of my multiplayer games so far follow the Client/Server game strategy. The basic networking architecture is exactly the same and has the following aspects:
- The server maintains the game state and publishes it at high frequency to a channel that all the players are subscribed to. This ensures all players are in sync.
- Each player (client) sends their current state (based on user input, etc.) on a unique channel dedicated to that client. The server is subscribed to this and uses this info to maintain the up-to-date game state mentioned above.
- The game has multiple game rooms.
- The host player has options to start and end the game.
- In general, there's awareness of every player's score, position, alive/dead status, join/leave updates for the game, etc.
These are the elements that most realtime multiplayer games require, and building a networking framework lets game developers quickly add multiplayer functionality to any game. I built it with Ably to easily scale it and for all its realtime communication features (like message ordering, availability, guaranteed message delivery, etc.).
Multiplayer games scalable networking framework
The framework serves as a starter kit to add multiplayer functionality to your game using the Client/Server strategy. It provides a communication framework for your players to interact with a central server, in realtime, for the entire duration of the gameplay.
It also lets you implement a “game rooms” feature using Node.js worker threads. This is analogous to spooling up dedicated servers on demand, letting you spin up multiple instances of the game, each with a separate group of players. It comes with a skeleton demo app where this functionality can be simulated. The idea is for game developers to take this framework and add their game logic to make it their own.
You can find the full project with a detailed guide on Srushtika’s Multiplayer Games Scalable Networking Framework on GitHub. You can also try my new realtime quiz framework for EdTech developers . If you have any questions or suggestions, feel free to send an email to [email protected] or reach out to me directly on Twitter, where I'll be happy to talk about this. Don't forget to share any multiplayer games you build with this framework — I'd love to check them out.