Godot: The Open Source Game Engine

I have been watching a lot of game development coding tutorials over the last couple of years. This includes things like the excellent Game Developers Conference (GDC), Sebastian Lague and his wonderful coding adventures series, and Yahtzee's dev diary series to name a few.

It's difficult to not see developers use Unity when demonstrating their game developing online. Some developers will directly reference it, whilst others will simply look at the code they are writing. Unity, though, didn't appeal to me as it comes with some licensing costs. You only need to pay those licensing costs if you release a game, but as a hobby developer who advocates free and open source development Unity just didn't sit well with me.

A couple of months ago I came across the Godot game development engine and I have been following along some tutorials to get to grips with it. I have really enjoyed getting into the platform and so thought I would write a quick introductory article.

Godot (pronounced "god"-"oh", just like the Samuel Beckett play Waiting For Godot) is a game development engine that allows for 2D and 3D graphics. More than this, the system has a mature development environment built on top so the game can be developed and tested right inside the tool. Whilst quite a lot can be done from the interface itself, you can also add functionality with scripts. Godot has a build in scripting language called GDScript, which is a python-like language, but it also supports C++, C#, as well as a number of other languages supported by community plugins.

When you first open Godot, the interface is pretty daunting as there is no clear indication of what to do or where to go. You can create a scene easily enough, but making it do anything needs some understanding of what needs adding to the scene. I floundered around with this for a while before finding my footing. The documentation is really quite good, but there is a lot to take in before you can make sense of things.

Perhaps the steepest learning curve is knowing what nodes to add to perform specific functions, but also the relationship between objects that require a hierarchy. Once you get the hang of things though you can create all of the different types of objects you need. As you start to dig into things it becomes clear that the Godot interface is highly polished. Not once did I see any bugs or other crashes in the interface.

The scene Scene interface then starts to look at little more fleshed out with different items interacting with each other.

For me, following along a few tutorials was essential to getting started. I have heard that experienced game developers who swap from Unity have no problems picking up Godot, but for me not having used either I needed that help to get things going. I highly recommend some of the free Godot tutorials created by GDQuest, who take you from nothing to a fully featured platform game. What's great is that they build upon each part of the game, showing best practice approaches and how all of the different nodes and scripts interact with each other.

Here is my game created after following through their tutorial.

After I started to get the hand of things I looked at creating my own game. I decided to do something simple to start off with and started to create my own asteroids clone. After a couple of hours of experimentation I had the ship and asteroids models working well, along with their collisions. Here is a work in progress screenshot from the game (with some random stolen art assets).

Before you ask, I probably won't be releasing this game, at least not in its current form.

My top tips on getting into Godot are:

• Remember that everything is a Scene. This means that everything the player interacts with, the player entity itself, the levels the player sees and even the interface are all scenes.
• Scenes contain nodes (some of which are other scenes). There are many different types of node in Godot, each of which provides a function or feature to the scene. If you need to add an image then a Sprite node. If you want to detect a collision then you'll need an Area2D node that contains a CollisionShape2D node. The trick with Godot is knowing what node to add to the scene to create what functionality and how those nodes interact with each other.
• Interfaces are hidden away in Godot until you need them or have something on the screen that interacts with them. This means you don't have a cluttered interface so the animation controller doesn't appear until you add an animation node to your scene.
• You can do an awful lot with the built in GDScript, but there are some limitations. GDScript is python-like, so you need to learn a few of the differences before you feel comfortable with it. If, however, you are already familiar with C++ then you can use that as well. Using Godot with GDScript allows you to export your game to many different platforms without having to recompile or translate that game. That said, GDScript is slightly less performant than native C++ and so if you game requires highly performant code then it might be a good idea to look into C++ as an alternative.
• As everything in Godot is basically configured using plain text files this makes the tool very good for collaboration projects, especially when source control is involved. This means that merging another developers code into your project won't cause binary merge conflicts.

If you want to give Godot a go then you can download it from the main website at godotengine.org. You can also find a showcase of Godot projects and the all important documentation, which is actually pretty good.

I will definitely be continuing to learn Godot. I have managed to get my head around some of the key concepts and what I have managed to create has been very promising. I hope to add more articles in the future detailing anything interesting I find. I will certainly be turning to Godot to go things like sorting colours in three dimensions as this is built for that kind of graphics processing.