Another Game Jam Entry – Tune Trail

A couple of years ago I participated in the VimJam2 GameJam and made the game The Boss and that was a fun experience where I tried out making a game in Unity (not really my thing.. just didn’t enjoy the process) but I think the humor became good and the music as well, so when VimJam4 came along this year I decided to jump in and try to make a variant of a rythm based game in DragonRuby. is the result.

It’s not a great game, but it didn’t take much time to make and I think I can build on this concept. The controlls are simple and with some design this can actually become fun to play.

Now, you might wonder why i chose to use DragonRuby, well. Its just feels right. I can code the game and I just need a command line and Emacs/VSCode or whatever. No installations.. And also the publishing system is excellent. I can simply just be a developer and understand this. I don’t need to be expert in a game engine. The concepts are simple and it just gets the job done and I can do the things I like. Develop.

I remember when making the Unity game the endless hours of trying to get a collision system to work correctly with the ground plane (it still doesn’t, its possible to fall through the floor..). This is trivial in DragonRuby. On the other hand, making a particle system in DragonRuby is probably a bit harder than in Unity where its just there. So what you use kind of depends on what you are making and WHY you are making it. I am making this for my enjoyment, so I use the tools I enjoy 🙂

As usual I put most energy into the tune. Hope you like it 🙂

DragonRuby vs Godot4 benchmark

What a click-baity title..

Amir Rajan, the maker of the excellent DragonRuby game engine put up a couple of Youtube videos comparing the engines performance to Unity and PyGame. Since I wondered how Godot 4 would stack up, I implemented the same benchmark there.

How did it stack up? They are quite similar from what I could see. DragonRuby a bit faster when handling 20-40k sprites but at 80k they were the same.

Code is here:

Is there any real take away from this simple comparison? Not more than both are plenty fast. If you land here since you are thinking about if you should use Godot or Dragon Ruby, then I think you can take speed out of the equation and focus on other differences. Both are excellent.

Todour 2.22

Time for a small update of Todour.

  • Potential bug for writing files fixed (flushing seems at times not happening on virtual filesystems)
  • Added documentation on GitHub pages
  • Added support for treating due as threshold
  • Added support for “business days”
  • Updated QtAwesome to a newer version
  • Changed name of icon files to todour.* from newicon.*

As always, you will find the downloads on

New game: Wordur

It’s christmas time and I am not working that much so that means there has been some time for pointless programming 🙂

I made a game called Wordur to sharpen my C# skills and use the very nice Blazor framework that Microsoft have been kind enough to provide now for a few years.

Play around with it! See if its any fun. It comes with bugs included so don’t expect a completely stable experience (just reload the main page and go from there).

New application: Kan Jag Duscha? (Can I take a shower?)

Due to the rising energy prices I have changed my Electricity supplier here in southern Sweden (Tibber) to one that bills me based on what the electricity costs when I actually use it (hourly), and that also has an API. So.. with an API comes the responsibility of making use of it of course.

I made this small application / website to tell me if its a good idea to take a shower or to wait, based on the electricity price right now.

Of course it only makes sense to you if you live in southern Sweden and have the same Electricity deal as I have, but if you do, this might be useful 🙂

More information is here

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.


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


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 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

COPY . .
RUN mkdir logs

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: 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

        - mkdir build
        cd build;wget;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
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 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:

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

Goodbye Heroku (for now)

Now the day came. Heroku has decided to stop with its free plans for running small web applications and their free redis and postgres plans as well. I don’t blame them for it, but I am of course a little sad that such a convenient deployment option is going away.

I am a rather recent Heroku user, but I use “server less” a lot in my work (where I mostly prefer using the IBM Code Engine. Its good, try it!) but for my hobby projects I recently found Heroku when playing around a bit with Ruby on Rails and its simplicity and price (free) really fits for small experiments. I don’t mind the cold start time being a bit slow, as if I would be serious with any project, I know I can just pay a small sum and I will get more power. But not anymore.

I can’t say that I think its reasonable to pay for all my dynos that I have. Most are just small things that I am playing with from time to time with one or two users. Each would need a dyno and at least one database. It would quickly add up, and also I don’t like that it should be any resistance to starting a new project. Free is nice in that it removes one obstacle to just starting. But I like the concept of Heroku and I want to continue to use the very convenient way with the Heroku buildpacks to publish and run my software.

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 🙂