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.
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.
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 🙂
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 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 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 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?
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
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…
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).
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:
COPY . .
RUN mkdir logs
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?
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:
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 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 🙂