Why I ended up with Godot

My journey of game development

Hi, my name is Peter and as I write this article I am 30 years old. Since I first came in contact with computer games on my 80286 Tower PC with DOS as a child, I have been very interested in computer games. When I was 13 years old I got my first programming book “Delphi for kids” as a present. My parents were not very happy about the fact that I spent a lot of time with the computer and only played games. They told me to make something of my passion and maybe programming would be something I would like – and they were right!

I started to read the book over and over again until I had a first understanding of OOP and the development of small applications. I started to delve into genesis3D with bindings for Delphi in order to develop my own 3D computer games – which of course I failed because the challenges were far too big. Then I developed with C++, DirectDraw and later Direct3D until I started my studies in computer science. But that was all just prototyping and no finished products. The last, biggest plan was to develop a 3D drum simulation where you can build your own drum kit and have it play drum lines automatically from a tablature. All in C++, Direct3D 9, so I had to develop the 3D and 2D UI engine completely on my own – that too was too ambitious.

After my studies I now work for t2informatik, a software development service provider from Berlin. And of course my attitude has changed from “pure C++ is the best, because you can do everything with it” to “use the language that is easiest for the purpose”. An approach that helps me today as a professional C#/.NET developer for business applications in medicine, pharma, asset management and service-oriented architectures in general.

The game engine hell

I love to try games with different techniques to see how they help me solve my problems. My expectation is that the framework or game engine I use must solve my recurring problems, otherwise I’m not convinced to waste my free time with it. I’m not a student anymore and I want to have fun and not build my own UI framework again, because the engine or the library I use doesn’t offer me a suitable solution.

In the course of time I started to try out several libraries. The very first one was löve2d. It is a nice little 2d game engine based on Lua. It is great for game jams and is also suitable for quite big titles. For ease of use, it offers many basic tools for graphics, sound, physics and I/O. It is easy and flexible to use, so I have developed some games as a prototype and have been quite successful with it, as the following game prototype shows:

Then I started to use one of the bigger engines, the first one was Unity, of course. Some years ago it was my preferred choice for prototyping because I like the workflow, everything is in C# and of course there is the very useful Asset Store.

Unfortunately, I had a lot of trouble getting over the initial obstacles. I found the steadily growing scope of the engine particularly difficult. When I started with it, the engine was fast, but with each new version it became more and more heavy and slower to use. It didn’t offer anything new to me, I just wanted to program quickly in Unity and use it for prototyping. So I started to think about alternatives to Unity, although I know a lot about it and have invested a lot of time to build a lot of technical know-how for this technology. Probably I could write a separate article just about the things that bother me about Unity compared to Godot.

Next, I took a very brief look at Unreal Engine. To put it directly: not my cup of tea. Why do you have to use these blueprints? Really, mainly C++? That was my first impression, and that was it. I had the feeling right from the start that this engine was not right for me. It offers immense benefits and productivity for large development studios, but not for my “I want to have fun without too much effort” approach. Maybe I’ll take another look at the Unreal Engine sometime in the future and maybe I’ll change my mind then. We’ll see. 😃

In brief: I am too comfortable using libraries like löve2D or MonoGame, and it bothers me that many libraries have different approaches and feature sets. The big game engines do not satisfy my view of game development or even prototyping. Therefore I have implemented almost no games in the last years. But I kept looking …

My first contact with the Godot Engine

I read about Godot Engine for the first time on spieleprogrammierer.de, a german game programmer forum. There were and are many discussions about which engine to choose, and someone mentioned Godot Engine for prototyping. I was curious and took a look at the topic, even though I was not convinced at the beginning. I downloaded the current version (2.6, I think) and tried out some of the tutorials.

The concept of Godot Engine confused me a bit, because it was very different from any engine or framework I had ever used. I was so confused that I even stopped using Godot and started looking for updates regularly. Then I read that Godot would get a complete overhaul of the 3D engine and C# support. I started following the development of the Godot Engine on github. I liked how active and open the community was and how everything kept improving. It’s a really impressive example that shows how cool open source is and that it can be a real win for everyone.

How Godot convinced me

When version 3.0 of the Godot Engine came out, I was willing to try it for a week. And I was not disappointed. On the contrary: I was enthusiastic and still am. Godot is a fantastic 3D engine! If I can give you one tip: try it out. The improved documentation and the much better user experience gave me the feeling right from the start that I was investing my time wisely.

After playing around a bit, the next step was to test the engine and the editor with a real use case. I had an old game from a Game Jam that I had implemented with MonoGame and C# at a competition – two developers programming a game in 20 hours – over the weekend. I started porting the game to Godot to see how it works and if it automatically solves the problems I had to solve in C# myself. And I was surprised: It worked great!

The system helped me to structure everything into logical scenes, exactly as I had imagined it, without any disadvantage. The physics engine worked perfectly for my use cases, and the animation system is such a nice, simple tool. The first “this is a piece of cake” moment for me was the Y-sorting problem: In my game I implemented a DepthSortManager class that knew all instances and sorted and rendered them in the correct order. I thought that I had to implement this in Godot as well, but I found out that there is a node for it. All I had to do was place all objects as a child. Done. That was when I started to find out as much as I could about Godot – and that’s what I’m still doing today.

Gdscript vs. C#

Something that might keep many developers away from Godot is the custom scripting language called Gdscript (Godot script). To be honest, I also thought it was something completely unnecessary at first, until I read an explanation by the main developer Juan Linietsky. His primary argument was that the integration of scripting languages is difficult and that when choosing programming languages like Lua, you have to deal with anything that doesn’t fit your use cases, such as multi-threading and user-friendly integration of the engine’s functionality. Coincidentally, the same happened to me when I tried to use Lua as a scripting language for my system to connect it to my C# entitiy component system. Juan Linietsky was right.

It is also often said that Gdscript is a very simple language that can achieve a lot in just a few hours. In fact, I can confirm that. It’s really easy to learn the language, and the support and integration with Godot’s code editor is also very good. If you try it, I’m sure you will have a similar experience. And if you’re really not satisfied, just use C# as before.

Current development trends of Godot Engine

Godot 4.0 promises further major improvements, which I am already waiting for. The new version is expected to offer the following features:

• Vulkan Renderer
• True multi-window support for dialogs and docking windows
• Revision of the Gdscript regarding performance
• Navigation improvements with collision avoidance

From my point of view these are the most important features of Godot Engine 4.0, but of course there will be many more. If you take a look at github and/or follow some people like Juan Linietsky, Rémi Verschelde, the project manager of Godot Engine, or Godot Engine on Twitter, you should easily be able to keep up to date.

Conclusion

I wrote this article because I think Godot is really great. I love the way it was developed, the mindset of the people behind the product, and the idea of how it should develop in the future. I can only recommend to anyone who is involved in game development that you seriously look into the subject and play around with the engine. All you have to do is download an exe of about 50mb from the website and you’re good to go! Very few products are up and running that fast.

To get started I would recommend to begin with a small project idea in 2D, take Godot and just try to solve problems with it. I promise you that you will not be disappointed. And if you are, please contact the community. Most of the time this leads to one of two results: you missed something and it’s easy to solve. Or you have encountered a problem or a new, interesting use case, and are helping the Godot Engine developers to improve it. Win-win, so to speak.

Notes:

Peter Friedland has published some more articles here in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.