The game Sumur that I wrote some time ago was an interesting experiment in writing a multiplayer game in Godot using websockets and I thought I’d share how it is built and why.
The game has three parts. A client for handling the player interaction, a server for the rules system and a backend for handling persistent data.
The Client
The client is the view. It handles all the interactions with the player and gets instructions from the server on what to do as reaction to each player interaction.
It sets up a connection to the server when it starts but doesn’t really have much logic of its own (there is a possibility to play the game locally, so a part of the server is also available in the client for that case, but that is a subset of the possible games).
The Server
The server is the controller if we talk MVC pattern. When I first implemented it, the server had a database (sqlite) and could thus also be the model but that of course doesn’t scale if that would be interesting (and even if no one will ever play the game, it is made to scale).
The server is also written in Godot and using the websocket system of godot it keeps contact with the clients. The server has multiple game classes that are all derived from the same base class, one for each type of game, that it creates a new object of each time a new game is started and thus can keep the rules and the state of each game ongoing separately (the same game classes can be run directly in the client as well).
Since each game mode is written in a separate class that inherit from a common game class, adding a new game mode is very easy.
The server also keeps in touch with the backend, using the godot HTTPClient, where the user logins are stored as well as the highscores of the different games. Each time a game has an action, the highscore is updated and fed to the client in question so that the real time highscore can be dispayed.
When it comes to scalability, there is no limit to how many servers can be running at the same time and each server can handle 100 players at the same time (a completely arbitrary number I made up out of thin air). However the current deployment only has one instance of the server running as I don’t see the risk all that great that it gets over loaded.
The Backend
The backend is a standard Django REST application. Why Django? The ORM is amazing, the Admin mode is superb and the language is almost the same as the one used in Godot so there was no need juggle multiple ways of doing this when writing the code.
There was really no need to write the backend like this in Django. Each server could have done all the work needed itself and just needed a database to connect to. The reason I still went with Django is that this is what it does well. Godot can do it too, but connecting to database, handle migrations, do queries and so on are not what it is built for. Django is, and I think this shortened my development time considerably. Pick the correct tool for the job.
Security
With all these moving parts, the security is of course important. With the expected popularity of the game and thousands of players, it will certainly catch the attention of some bad actors that will want to break it, so what has been done to make sure that doesn’t happen?
- The client makes no decisions
- This ensures that a hacked client can not be used to cheat in the game as easily. Of course there are still ways as the client can see the entire board, but cheating is relatively hard.
- The client doesn’t handle the authentication
- All authentication is handled in the interaction between the server and the backend. The client has no decision power. If it doesn’t know the correct password it doesn’t get to start a game
- All communication is of course encrypted with HTTPS
Outro
I hope this was of some interest to you. This is way over complicated game, but it is a good proof of concept for making a multiplayer game in Godot that uses websockets. Since it does use websockets, the server part of the game can be deployed on a standard kubernetes based system like IBM Code Engine or similar and just work without any special protocols needing to be taken care of and thus it allows for easy scaling compared to hosting this myself.
Making this kind of potentially quite massively multiplayer game was definitely easier than I thought and Godots multiplayer system is really a joy to work with. Everything was extremely intuitive.
Now I just have to come up with a game idea that people actually want to play…