Why I use Godot

Warning: Potentially controversial opinions about game and software development. What is a valuable solution for one person may not be valuable for another, etc.

In the world of game development, there are plenty of choices off the beaten path: Phaser, RPGMaker etc. I could not seriously ever list them all. But when it comes to professional indie development, there are have really only have been two viable choices at the head of the pack for a long time: Unity and Unreal.

However, I would suggest for many developers like myself, that Godot may be the best choice. Godot is an open-source game engine that has been rising in usability and popularity, and as of the release of Godot 3, can be considered a real contender to these more established engines. Why?

Well to start, I’m not a game designer by trade. I’m a full stack engineer, working in python, scala and javascript to develop web APIs and ETLs most of my career. As a result, I have a more "outsider" kind of perspective on these engines and languages. And frankly, when you have been working in these higher-level languages for a long time, it can be quite jarring to have to use things like C++ (the 90’s called…)

One of the first things that struck me when I started using Godot was how much more familiar the workflow felt for a traditional software engineer. Writing code was a breeze and the engine is designed for you to work with code first and foremost; everything is linked together in a dynamic tree structure that lends itself nicely to quick prototyping and "bottom-up" style development.

There has been a trend in recent years towards making game engines more "designer-focused". Don’t get me wrong, this is great and opens the door for more people to get their hands dirty with prototyping and developing games without studying programming for years. But at the same time, there’s a tradeoff when the code is practically hidden from the user.

By default, games in Godot are written using GDScript, a python-like language specifically created for Godot. You can get the brevity and expressiveness of Python while developing games! If you are anything like me, this is a godsend. For many in the industry, this may sound like a horrible idea: "won’t an interpreted language be too slow?" you may be asking. But here’s the thing, GDScript is compiled to a Godot specific byte-code, meaning it is as close to the hardware as C# is.

Godot was designed as a 2D engine. This gives it plenty of advantages in terms of efficiency and ease of use when making 2D games. In most other engines 2D doesn’t exist, it is simply 3D with a permanently orthogonal camera. Godot is later to the 3D party than most other engines, and truth be told, I don’t know the full extent of how well Godot fares in 3D game development, but it is certainly a main focus for the development team. If you are working on a 3D game, it may be best to use a more mature tool for now.

Deploying games with Godot is quite easy to do, however, you may find that its list of exportable targets to be lacking. Currently, you can export to PC (Windows, Mac and Linux), XBox One, Android and iOS. This misses the major consoles, so if you were hoping to target the Switch for example using a Godot, your options are limited (Console Support in Godot). For me, this is the real concern holding me back from using Godot for virtually everything. It is possible to get a third party company to port your game for you, but I don’t know how viable that is (I’m planning on trying it at some point though).

To sum up, if you are comfortable with code and plan to make 2D games, Godot is the best choice out there in my opinion. If you need console or 3D support, perhaps not now as of this writing.