Godot Jam Review
At the beginning of the year I posted about the retrial of Godot, the most popular free and open source game engine around.
I’ve posted some pros and cons at the time. I then decided to enter into a JAM to motivate myself to try to actually use it for a real complete project. Even it being a jam-like game.
Now it’s time to do a review the whole process.
TLDR: I failed to complete the game. I tried to created a pipeline to build a nightly version for the latest version, with C# support. It is partially running ok.
The Jam theme was ocean. Bonus points for those that:
- all sounds in-game are made with your mouth(s)
- include a fishing mini-game
- include your favorite quote or pun in game
So I started. As previously said, I’ve planned to implement a old game of mine as the main game. The advantage was that I knew what was needed and the general need. Another plus was the fact that the game was abstract, so I could save a lot of resources and time on the presentation. And by doing the sound effects with the mouth, I could neglect this front until the end.
For the mini game, I looked for a small board game that I could easily implement in the digital form. After some research, I settled with Leaky Boat, a fast paced pen-and-paper game with dice.
So I started to code. But the problems with the C# integration was getting in my nerves. Godot editor crashed more than 30 times in the very first night of coding. It was not blocking the path, but it was making it very very difficult.
New Version from Scratch
As a potential solution, I checked if the undergoing development of Godot 4 (I was using the “stable” version of Godot 3.5) had any nightly build available. I’ve found a guy that was creating theses nightly builds! But only the original non-C# version. The repository was open so I checked if anything was possible to salvage. Not much.
So, as a detour, I decided to build a pipeline on Gitlab that would compile the source code and build it. Eventually I would schedule it to run every night. However, the process of creating a build pipeline online is very tedious and laborious: on every change, I had to run in online. In the case of Godot, trigger the code compilation to eventually discover that 30 min the build start, it failed due some dependency on the build stack was not fun. It took me a whole day spending my personal CPU quota doing this.
So, as a second detour, I decided to host a local Gitlab instance in my computer. It would allow me to develop the pipeline itself. Once ok, I would migrate back to the online service. It took me 2 days to set this. I first decided to go with local Kubernetes, but it was getting too complicated. Then I migrated to a solution that I am more familiar with: Docker-compose inside a virtual machine. I created inside Virtualbox (instead KVM) because I planned to reuse it when I decided to use Windows.
Downloading and building several docker images takes a lot of space! I had to resize the VMs to a much bigger size than originally planned to accommodate the dozen images created/downloaded.
The plan was to create an helper image with all the tools needed to compile the code with or without C#, host/register inside Gitlab itself and reuse in the main pipeline. This step was working fine, but the actual build was failing time after time.
To check if the steps were right, I decided to compile inside my own machine. I did not wanted this originally to not pollute my pc. But worked. Since I “wasted” several days in this detour, I decided to use this local compilation into my project again.
New Version, Old Problems
Godot 4 renamed several classes. Also, it changed several small things internally and it took me couple of ours migrating to the new environment. Good thing is that I did not have much to convert. Done. And the game was working the same as before.
Now it was time to continue the development. But the problems continue the same way: the editor was crashing time after time. I managed to make both the game and the mini game functional, but with several restrictions. The pace was slow, because I had to investigate the way of doing things all the time. And the documentation was definitively not comprehensive for C# users.
After 5 days, I gave up. :( I could theoretically finish the game in a certain state, but I decided to focus my attention to other projects instead. I might try to go with this engine later in the future, but for now, I will return to Unity until I finish one of my projects.
A couple of days after the end of the jam, Godot 4 alpha 1 was released. I still think that, if the devs do not provide a nightly version by themselves, my project has some space.
Despite the failure, I’ve learned a lot about Godot, Gitlab and Kubernetes. Specially the later two. I will use it in the future for sure, so I do not feel the pressure of failure.
All the code, even incomplete, are open source in my Gitlab profile.
Also, they are organizing a Jam every month. I can reuse all to the new jam, for certain.