Category Archives: Games

The architecture of Sumur

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.

Conceptualized architecture

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?

  1. 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.
  2. 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
  3. 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…

Virtual Keyboard in Sumur

This has been a long time coming. Sumur has up to now not really been playable on mobile using the HTML5/WASM version due to difficulties loggin in. I saw the potential solution for this issue in https://godotengine.org/article/godot-web-progress-report-7 a while back where the Godot team had added an experimental version of an on screen keyboard to Godot.

This was for Godot 3.3 and we are now at 3.5 and there is still quite some work to do on this feature. But it does work!. So from today you can play on your tablet or phone (I still havent made an automatic Android or iOS build so that will have to do for now).

Nice work Godot team.

Building and publishing a Godot websocket server on Dokku

The title is quite specific, but I would have loved to have this article around when I moved my game Sumur from its old hosting at IBM Code Engine and to my own Dokku server. Also, I remember having had some issues packaging the game in a docker to begin with, so here is a short explanation of how that can be done. I am sure there are other ways.

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

I made a small game – Sumur

I made a small game a while back. I made it in C++, since well, that is how things get done, and all was fine. Until I wanted to change stuff in it and it all just became complicated (my code was a bit of a mess). So I tried out Unity, Unreal and Godot, and in the end settled on using Godot.

So here it is. A small math puzzle I made when thinking of ways to help my daughter with her math.

The game is a bit more complex than it needs to be (implementation wise), but I wanted to test making a networked game. So this game is running in a browser but has a server backend (also written in Godot) that is running on IBM Cloud Engine and that in turn has a database/API written in Django-REST on pythonanywhere. In theory, this should all scale pretty well if that would ever be needed 🙂

If you feel like playing it, just log in with whatever username you want and a password. If the username doesn’t exist a user is created. Else you just get an error so you have to chose another name. Then select a game and play. The highscores are live, so your see how you are doing compared to everyone else that has played.

Note: Since this was written the game has been moved from both IBM Cloud Engine and pythonanywhere.

Fallur: Video

One thing that every respectable game on the Google Play Store seems to have is a video. Now, as Fallur is a very respectable game, I of course had to make one as well.
[banner]
I took a part of the song No one knows (it’s a part of the game), shot some footage of me playing and massaged it a bit in iMovie to come up with this result.

Now the game is even more respectable I guess 🙂

Fallur: Making of 2.0

feature

Now, the game Fallur was released a bit early, just to be out in time for christmas (and the reason for that being that I had invested 30 minutes into making christmas graphics for the game). Now it’s time to make the game good enough to be playable for the rest of the year.

screenshotGraphics

The graphics in the 1.0 version of the game where all photography based, and the game ran in 360×540 resolution with 48×48 sprites. This is a quite nice resolution to work in when using that kind of graphics, but if the graphics is to be hand-drawn it puts quite a lot of pressure on the artist.

Screenshot_2014-12-29-12-36-15For the 2.0 version I decided to lower the resolution quite a lot (4x) to hide the fact that I can’t draw at all, and also that the added resolution really didn’t add anything at all to the game play.

For sprites I used the very nice Random Sprite Generator by Boris van Schooten (check out his site that’s full of games and useful stuff). That received me of the pain of having to do much graphics.

The rest of the graphics is just scale down of the higher resolution images used in 1.0 except for the background that I simply removed in favour of a simple gradient that makes the game more playable.

Sound

[banner]

Making music is one of my greatest passions in life. I am always playing my guitar and coming up with a new song. It’s like breathing. I have to do it. So making music for a game should be simple, shouldn’t it? Not really.

I make rock music mostly. I have once in a while made these “chip/synth”-kinds of tunes, but they are much more effort to make than a guitar based rock tune. So, I made this:

This is an early draft of music that could be added to the game, but I am not sure right now as it can’t be compressed below 2Mb of size without sounding really bad. I got it down to 1.5Mb by removing most high-frequency sounds in the song and then compressing to 80kbit. That will have to do for now..

Gameplay

The original gameplay was very simple. Hit all things that fall down (at varying speeds) but don’t hit the ghosts. Then of course the difficulty increased by increasing the number of things falling down as well as the speed.

The result was a game that was completely unplayable after level 20. It was simply to difficult. My analytics data proved the point by showing that most people failed early (or thought the game was boring and quit).

Change to the gameplay is now that there are 6 personalities with different behavioural patterns. For the first 10 levels only one, quite simple one is available. Then another, a little bit harder comes into the game and so on. The game is now playable for 60-70 levels for those who  fancy this kind of super simple game. It will be interesting to see on the analytics if anyone has the patience or interest to go that far or if people just drop the game after a few levels due to bordom.

What now

[banner]

The 2.0 version of the game is now live on google play. It has a bit more evolved gameplay than the 1.0 version and a rock soundtrack of quite low quality.

Now I will keep my eyes on my analytics to see if this appeals to anyone at all, fix issues and enhance if needed. Who knows, there might even be an iOS version of there is enough of people playing it on Android. But the goal with the game is the same as before. I do this for learning.

There will be updates. Possibly the music will be changed, the Facebook integration is very rudimentary, perhaps a google play integration would be a good thing, overlay screen showing when a new monster has been unlocked should be made, sound effects added and so on.

But now, let’s see if anyone plays the game.

 

Fallur: Why was it made?

After I made Lovur I experimented with some HTML5 frameworks for game development. I have always liked writing games but I’ve normally got stuck somewhere in sprite-handling routines and level editors but with these tools it was amazingly simple to prototype games.

Using the MellonJs HTML5 engine I prototyped two simple games in a few hours. That’s two playable games. I was intrigued by the efficiency of developing and of course I tried the games using Cordova on a recent Android phone and I got disappointed.

As nice and fast it was to develop in this environment the results on smartphone were quite bad.

I tried both games both using Cordova and also using crosswalk and CocoonJS for greater speed. I also tried re-implementing both games using Phaser (remember that I’m still writing about small prototypes of games).

To sum it up. Both games where jerky as normal Cordova builds, not reaching anywhere near 60 fps. With Crosswalk and CocoonJS they were playable, but at a high cost in file size and then just barely playable. I figured that if I would add any logic the playability would suffer. So I tried LibGDX.

I implemented both prototypes in LibGDX, this time taking a bit longer time than the HTML5 variants of course but with more control. The results where really smooth (I only tried on Android) and the development environment quite nice so I decided to continue working on the games a bit. After all, I have a few game ideas I would like to implement, but before I can do that I have to learn. Fallur is a place for me to learn.

I released it before christmas 2014, a bit ahead of time. The game isn’t ready, but it is playable (well, up to level 20, then it gets a bit too hard.. and perhaps a bit boring). I rushed it out since I had made a christmas theme for the game. The game will be re-themed later on and the game play will evolve.

As I am only doing this for my own sake and for learning I have no problem releasing an unfinished product on the world like this. Also, that is the reason the game is only available on Android. I will be updating it and that is simple and fast on Google Play. Also, as I will be evolving the game play and graphics (experimenting) I don’t have time to maintain different versions for different platforms even if the very nice LibGDX would make that possible.

Anyhow, I hope someone is enjoying the game despite it being in the state it is 🙂