Category Archives: Cloud

The architecture of Sumur

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…

Building and publishing a Godot websocket server on Dokku

Godot websocket server in a Docker

Lets start with the Dockerfile:

FROM ubuntu:22.04

WORKDIR /app
COPY . .
RUN mkdir logs

EXPOSE 8080
CMD ["./game"]

As you can see, this is not all that impressive. We expose port 8080 (the server code is configured to listen on that port of course) and run the game. But what is this “game” that is being run?

Good question. It is not the executeable that Godot will give you as a result if building for Linux. Its rather the server version of Godot itself (when writing this, its the file found here: https://downloads.tuxfamily.org/godotengine/3.5/Godot_v3.5-stable_linux_server.64.zip) renamed as game.

In the same directory is the game archive, named game.pck (Godot will automatically load the pck file with the same name as the executeable).

Thats basically all there is to it.

Here is the relevant part of my Makefile for reference (the server code is in directory “server”):

build/game.pck: $(shell find server -type f)
        $(godot) --path "server" --export "Linux/X11" ./game.pck --no-window
        mv server/game.pck build

build/game:  
        - mkdir build
        cd build;wget https://downloads.tuxfamily.org/godotengine/3.5/Godot_v3.5-stable_linux_server.64.zip;unzip *.zip;rm *.zip
        mv build/Godot*.64 build/game 

linuxserver: build/game build/game.pck
        cp -R server/data build
        cp server/*.so build
        cd build;docker build -f ../Dockerfile -t sumur_server .
        docker tag sumur_server myrepo/sumur_server:latest

Deploying, running and re-deploying on Dokku

As I explained in Goodbye Heroku (for now) I have set up a Dokku server where I run all my server stuff (its quite amazing how much stuff one can run on one cheap cloud server) and mostly this has been simple. Running Django or Rails applications using Heroku buildpacks is a well documented and simple process. A docker container with godot server running websockets turned out to be less documented..

To start, set up a normal dokku application and hostname, letsencrypt and all that. Basically:

dokku apps:create sumurserver
dokku domains:add sumurserver sumurserver.yourdomain.com
dokku letsencrypt:enable sumurserver

Then you need to add the ports. My dokku defaulted to redirect http and https to port 5000 in the docker. To fix that:

dokku proxy:ports-clear sumurserver
dokku proxy:ports-add sumurserver http:80:8080
dokku proxy:ports-add sumurserver https:443:8080
dokku proxy:ports-add sumurserver wss:443:8080

Since websockets is supported by nginx, this “just works” without any more configuration. Now we’re all set to deploy the docker.

The simplest way is to deploy once and be done with it:

dokku git:from-image sumurserver myrepo/sumur_server:latest

This will work just fine, but I never got it to update the image when I rebuilt it and published a new container to my repository. How to fix that is described in the dokku documentation at https://dokku.com/docs~v0.25.7/deployment/methods/git/#initializing-an-app-repository-from-a-docker-image using the images sha hash instead of its lable. In my case:

dokku git:from-image sumurserver myrepo/sumur_server@sha256:9d187c3025d03c033dcc71e3a284fee53be88cc4c0356a19242758bc80cab673

Again, put into a Makefile:

publish-linuxserver:
        docker push sumurserver myrepo/sumur_server:latest
        TAG=$$(docker inspect --format='{{index .RepoDigests 0}}' sumurserver myrepo/sumur_server:latest) &&  ssh my.dokku.server.com dokku git:from-image sumurserver $$TAG

Goodbye Heroku (for now)

The replacement

The discussions on Hackernews suggested all sorts of solutions and services to replace Heroku, but I wanted the same kind of service and similar simplicity. Also, I have a cheap virtual machine on Azure that is just sitting there from some project I have long forgotten about.

It’s important for me that this works the same as before. I want to be able to just publish to Heroku again if one of my projects should take off and be worthy of a small investment. But until then it seems it is quite close to trivial to run all my projects using Dokku on my cheap virtual machine.

I found an excellent tutorial on how to set up Dokku and migrate my dynos and I couldn’t imagine it being simpler to move. My virtual machine is now running 3 apps (1 rails and 2 django), with postgres and redis databases (and Sidekiq and RQ) without any issues and I have for the moment closed down my Heroku account as I don’t need it right now. I think this is so simple that I will be moving a couple of more apps from other services I have used in the past to this machine and collect all my projects here. A couple of more Django applications, a Ruby web server that is back end for a game and a Godot game server are all on their way.

I am looking forward to see how to this setup will cope with these different projects. Perhaps I will write something about it in the future. Until then, happy coding, and I hope Herokus changes will make it even better 🙂

nerdur.com

A home for my nerdy endevours