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 use it myself for a real complete project. Even if it is a jam-like game.
Now it’s time to write a review the whole process.
TLDR: I failed to complete the game. I tried to create a pipeline to build a nightly version for the latest version, with C# support. It is partially running ok.
Bootstrapping
The Jam theme was “ocean”. Bonus points if:
- 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 an 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 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 were getting on my nerves. Godot editor crashed more than 30 times on 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 these 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 online. In the case of Godot, trigger the code compilation to eventually discover that 30 min the build started, it failed due to some dependency on the build stack was not fun. It took me a whole day to spend my CPU quota doing this.
So, as a second detour, I decided to host a local GitLab instance on 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 it inside VirtualBox (instead of 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 a dozen images created/downloaded.
The plan was to create a helper image with all the tools needed to compile the code with or without C#, host/register inside GitLab itself, and reuse it 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 them inside my machine. I did not want this to not pollute my pc. But worked. Since I “wasted” a couple of days on this detour, I decided to use this local compilation in my project again.
New Version, Old Problems
Godot 4 renamed various of its classes. Also, it changed countless small things internally, and it took me a couple of hours to migrate to the new environment. The 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 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 on 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. Especially, the latter two. I will use it in the future for sure, so I do not feel the pressure of failure.
All the code, even incomplete, is open-source in my GitLab profile.
Also, they are organizing a Jam every month. I can reuse all to the new jam, for certain.
