Why Godot

Back in the Summer of 2018, while I was working on my second game with Unity3D and C# on Linux I decided to install Haiku on a Virtual Machine. For those who don’t know, Haiku is the heir of the most interesting system ever developed at the time when there was a great variety of Operating Systems to choose from, the BeOS, an OS I had tried back then in the 90’s, liked back then in the 90’s, but could not use on a regular basis due to some issues not worth mentioning right now.
But this is not a post about Haiku but about Godot, and why I found myself developing my third game (first) with Godot. Introducing Haiku is needed because without Haiku I would have never being working on anything related to Godot, so it is a good reason to talk about this before going deeper into the “why Godot” topic.

Haiku running on a Virtual Machine (now I have it dual booting on my dev hardware)

While playing around to get to know my way on Haiku (and delaying the development of Roiny Froity with Unity3D and C#) I was searching for the software I use on Linux, and its availability on Haiku, in order to decide if I could move Game Development from Linux onto Haiku.
At that time, the Linux Editor of Unity was still in beta stage, not sure about that now, and I surely had some issues when working on Linux with Unity3D, none that stop me from keeping on with the development of games (long story) on my free time which is scarce.

Some would say I found an excuse to delay working on Roiny Froity, not really, as I kept working on it steadily, or as steady as my free time allows, but I found that on Haiku there was Blender, no Gimp, no Inkscape, no MyPaint, no Unity3D, no MakeHuman, no Octave (not the GUI version, there is the terminal one), no MuseScore, no VSCode… Basically the software I use to do the development, not that I use all of them everyday, though. These are the programs I have always installed and depending on the project, I would use one or another at a certain moment in the development process.

While digging through Haiku’s software store, HaikuDepot, I found a game engine I had never heard anything about of before: Godot. Not that I could use it on Haiku any time, as it always crashed before even getting to the editor, and always had issues with the Godot’s window rendering on screen, though I presume this issue is related more to Haiku’s video drivers and not using hardware acceleration, than to any other matter.

Godot Package on Haiku’s HaikuDepot

Nonetheless, thanks to this issue, I couldn’t test Godot on Haiku, though it triggered my curiosity so I searched online for it, found its website, which is a dot org one, found that there was a Linux version of the engine, that it did C#, and that it didn’t need to be installed, just download a small package, unzipit, and ready to go.

For a zipped package less than 30 MB in size I decided to give it a go on Linux and later decide. Compared to more than 1 GB of Unity, it was worth to try it.

Therefore I started to play around with C# on Godot on Linux while I kept the development of Roiny Froity on Unity’s Linux Editor. It was not that easy as C# documentation availability for Godot is not as broad as what is available for Unity. I kept on nonetheless. So at that time, I was pairing C# development of Roiny Froity on Unity with C# testing on Godot.

C# testing on Godot was quite hard as I had no idea on how to move myself around Godot’s Editor, and the different approach to game objects. In Godot, everything is a node, and had to do some mental changes in order to accept that change. Added to the lack of documentation, it took me some time to get used to the new concept.

This testing delayed the release of Roiny Froity about four months. Quite a lot for such small project. Due to the limited free time, and the need of doing TDM with other activities, well, the final outcome: delay.

Also, as I couldn’t do anything with Godot on Haiku, I tried several times to bring Godot’s 3.0.6 to Haiku by means of using Haikuporter, and even compiling from source. Lacking the skills, lacking the time and the TDM thing, the end was, as expected, an absolute failure. Never got anything done on Haiku, unable to run stable Godot there, there was nothing to do there. The only thing I was able to do was “porting” the Godot Icon to the Haiku default Icon Theme guidelines. Not much (see the image at the top).

Godot Crashing on Haiku

Until that point, while I was checking Godot on Linux I was actually enjoying it. It’s fast, customizable, comes with an integrated code editor, small footprint, nice. The nicest part of it is that it is open source, available on GitHub too.

So I decided to move to Godot when I start the next game project, give it a try at a “real” project, if anyone can call “real project” to the kind of games I am developing at the moment, and check how it behaves in my personal case on a real development situation.

As of this writing, I’m still working on BBiGL, codename of next game project, this time using Godot for the development, on Linux. And I decided to go with GDScript instead of C#, because of three reasons, namely:

1- Godot website does not recommend development on C# just yet, as there may be issues with the mono version of the engine.
2- There is no C# availability yet on Haiku. So if the Haiku port of Godot ever gets to be stable enough to do development on that OS, it would be the GDScript, standard, non-mono version.
3- I started to make some tools to help me with the development process, some that I found I need to ease the process of starting a new project, time management, blah, blah, blah, and I decided to go with Python as the language to use for this development. It’s said that GDScript is sort of a Pythonesque language, so, as available time is short, going the GDScript way saves time, or so I thought. Actually, I would rather Godot using Python as script language and adding the Godot API as a module, that would make things easier for me, but Godot devs may have their good reasons not to do so.

Therefore, moving to GDScript, and building my first Python app on Gnome Builder, and liking Gnome Builder for development, I decided to have Gnome Builder as the code editor for Godot, so I started with a first approach of GDScript highlight for Gedit and GnomeBuilder, which was not that hard, but not that easy due to doing it at my early stage of Godot knowledge. Not that such knowledge has improved a lot since then, though is growing step by step.

Albeit I did that, I ended up using the integrated editor because of, if Godot ever gets to work stable enough on Haiku, I would need to use the integrated editor, at least until someone gets some highlight and intellitype available to other code editors. Yes, I know, the Haiku thing all over again. If it weren’t for Haiku I would never be developing on Godot, though. Maybe?


Then, the main reasons I decided to use Godot for this project I’m working on right now, and most likely, for the next ones are:

  1. Godot is free and open source. I’ve been using opensource software for many years now. Finding a game engine such as Godot that is also opensource brings me closer to using 100% open source software.
  2. Godot has a small footprint. It’s fast to download, it’s fast to launch, and it’s good inside the editor moving things around (at least at my knowledge level, and the scope of my actual project). It actually runs on a small Atom tablet quite ok.
  3. Godot’s GDScript is sort of a Pythonesque language. Eases my jumping back and forth from Python soft dev to GDScript game dev. Short time does not allow me to jump from a language to a completely different one. It would be a waste of time.
  4. Godot might end up working properly on Haiku soon enough and I would like to develop a game project on that OS. As a matter of fact, it was Haiku who introduced me to Godot, should return such kindness 🙂

Those are the ones for now. When I finish BBiGL, I might come up with more reasons, and based on actual usage of the engine which might be more appealing to some. If that happens, I’ll update this.

BBiGL protoype:: Godot on Linux – GDScript