Tag: godot

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.

Caveats

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.

If you love Godot as much as I do and want to see it succeed, consider donating on Patreon! This way, the developers can afford to hire more full time staff and create the game engine we’ve always dreamed of! Disclosure: I am in no way affiliated with Godot, I just love and support it.

Quick Tip for Godot 3 Signals

I figured I’d share a quick tip that I found helpful in structuring my project in Godot 3.

Signals in Godot allow you to loosely couple any component in your game tree using the Observer Pattern. This means that any object A can communicate with any other object B simply by signing up to listen for a particular signal.

Neither object needs to explicitly reference or even be aware of the other object as long as they both agree on the same interface. This is very helpful when dynamically generating the game tree out of many scenes since the parent can connect together all of the children as needed.

This works great for simple setups, but as soon as you need to connect parts of the game tree that aren’t direct siblings or children, things can get hairy. You may find yourself creating "pass-through" signals to forward messages down or up the tree. Or you may start making several versions of the same signal to handle edge cases.

I followed a strategy of making "handshake" signals for any major scenes that needed to be accessed throughout the code. My base_level.gd forwards a signal level_handshake that would connect on to any interested receiver’s _on_level_handshake function. In this way, any dynamically generated scene that needs to accessed elsewhere can be broadcast to any node that is interested. It simply says, "hello anyone who cares: I’m the level and here is my reference". The receiver can simply save this and use it as it sees fit.

Following this simple strategy has drastically improved the flexibility of my code in regards to updates and refactors. It’s simple, but it’s effective!