I forget exactly where I originally read about the Godot Engine but I decided to give it a try after I completed my map generator. The verdict: Godot is extremely good. I should note that I have not tried using it for 3D projects, just 2D game projects. Here are some things that stood out to me.

Supported Languages

Godot supports several languages, including C++, C#, D (GDNative), JavaScript and Nim. It even has its own proprietary integrated language, GDScript. A Godot user created a benchmarking tool that helps give an idea of how well each language performs. C# support is still in its early stages, unfortunately, and you can’t use Visual Studio for debugging… Yet! Given some time these functionalities will be added. For now you have to use VS Code to debug, which admittedly isn’t that major of an issue.

Supported Platforms

Windows (and Xbox One by extension), Linux, OSX, iOS, BlackBerry 10 and HTML5 are supported. Other console support cannot be included with Godot as console SDKs are proprietary and all of Godot’s code is open source. There are ways to deal with this limitation, as outlined in the Godot docs.


Godot and Unity use a lot of similar approaches when it comes to organizing a game project.

Unity uses the entity/component paradigm with scenes and prefabs. Godot instead uses a tree approach to accomplish the same thing. Everything is a tree of nodes. Your scene is a tree containing several nodes for the interface, game elements, and so on. Prefabs are just a tree of nodes. Everything is organized in this manner.

What makes Godot stand out is that there is no distinction between scenes and prefabs like there is with Unity. Scenes and prefabs are the same thing, functionally. If you wanted to, you could instantiate several scenes inside of your main scene. There’s no limitations as to what you are allowed to do.

A GameObject in Unity can have several components, so you have to take a slightly different approach when you want to accomplish the same thing in Godot.

If this were Unity, some of these things would just be components of the base PlayerTest node. Personally i think i prefer Godot’s approach. This way, you can see every component at a glance without having to inspect entities to see which components they contain.

Each node performs a specific task. An AnimatedSprite node renders a sprite and handles its animations, a RigidBody node controls a rigid body, and so-on. When you’re used to being able to have several components on a single GameObject in Unity, it can be a little jarring at first. The upside of Godot’s node system is that it’s very easy to keep track of everything since every component is its own node with whatever name you decide to give it. Instead of having a bunch of components tied to a GameObject, you have a tree of the various nodes your game element requires.


Godot has an incredible integrated animation system that works for both 2D and 3D projects. The general workflow is:

  1. Set up your skeletal heirarchy.
  2. Create animations.
  3. Use blend trees and state machines to control the current animation state in-game.

Not only is the animation system intuitive and easy to use, it also allows you to wire function calls to specific keyframes in the animation. It’s been perfectly planned from start to finish.


Debugging a project can initially be more tricky with Godot compared to other engines like Unity. With Unity you can set up a scene then run it in debug mode and pause the game so you can browse the active scene in the editor window. This allows you to tweak variables and move things around in the live scene so you can really get an idea for what is causing bugs and how certain elements are interacting.

With Godot you can pause execution and examine the instanced entities in the scene tree but the interactivity isn’t there. You can’t see the active game instances rendered in the editor pane so you can’t dive in and disassemble things like you can with Unity. This is probably my biggest gripe with Godot’s debugging workflow.

Other Considerations

As mentioned before, Godot represents a game scene with a tree of nodes. In Unity you can access a GameObject’s component pretty easily. How do you do this in Godot when your components are organized in a tree structure?

var list = GetNode<VBoxContainer>("CenterContainer/Units/UnitContainer");

Nodes in Godot are organized visually as a tree, but when accessing them via code you use a string path.

I ended up writing some utility functions for creating nodes via code since it tends to get a little obnoxious without them.

public static T Instantiate<T>(string path) where T : Node
    string temp = "res://Prefabs/#.tscn";
    string filepath = temp.Replace("#", path);
    var node = GD.Load<PackedScene>(filepath);
    T inst = (T)node.Instance();

    return inst;


// Usage example
var player = Util.Instantiate<PlayerController>("Characters/PlayerTest");


Godot is shaping up to be the first open source game engine that is on par with existing game engines. Even in its current state i’d consider it a viable alternative to other existing 2D game engines. As it matures i expect it will get more and more attention.

Return Of The Glitch

In an earlier post i described an old program I wrote in C++ using Openframeworks. I tried remaking that program in Unity but the process of updating textures in unity simply took too much time and bottlenecked the entire program. I ultimately shelved it for this reason.

I decided to try once more to port this program over to the Godot game engine. Initial tests were promising. Texture updating was quicker compared to unity, but still not quite as quick as it was in C++.

Taking it to the next level

There were several improvements I had planned:

  • Allow the chaining of filters, so it would be possible to process several filters per iteration. Furthermore, i wanted to be able to visually connect and disconnect the filters. Something interactive like this would make it easy to combine filters for even cooler results, while also making the program intuitive and user-friendly.
  • Add a nice user interface that allows the user to toggle automatic image processing and save images on the fly.
  • Allow for any size of image, as opposed to hardcoding the dimensions.
  • Make it easy for the user to code new filters and register them.
  • Have a parameter system where data can be assigned to individual pixels by the filter, and give filters parameters that the user could modify through the UI. Exposing the parameters via the user interface turned out to be a bit more work than i had hoped, so i didn’t finish that functionality.

One idea I had was to make this a program that any person could download and use. There are two problems with this approach: This program is more fun to use if you know how to code your own filters, and I’m selfish and prefer to keep my algorithms secret.

Why is this so slow?

There was one critical oversight I made when I started porting the C++ program to Unity.

I presumed that images being manipulated in the old C++ program were 1080p. if i had looked closer at my old source code, i would have seen that the images were only 720p. with more pixels to iterate over, any new program I wrote would certainly take longer to process an image. This isn’t necessarily bad (higher resolution images are a good thing) but it contributed to the confusion as to why the old C++ program was so much faster than any new code I wrote.

I didn’t notice this key distinction until I started writing the program over in Godot. It made it a bit easier to live with the realization that my new program wouldn’t be as fast as it was in C++. I traded the speed of C++ for a better user interface, a more modular object oriented system and a nice interactive filter pipeline.

The pipeline

After handling the boilerplate code for the user interface and interactive filter system, all that was left to do was actually write some filters to test it.

Unfortunately, I didn’t keep track of all of my old C++ code, so I lost a lot of interesting filters that gave me fantastic results in the past. Still, using some of the code I still had access to, I could come up with some interesting new stuff.

It turns out that allowing the chaining of multiple filters was a game changer. If a filter gives underwhelming results on its own, then I’d simply combine it with a different filter. It’s damn near impossible to predict how filters are going to interact when chained together.

With the old C++ program there were a lot of “dud” algorithms that I would test and discard if they simply didn’t give interesting results. There was a lot of wasted code and dead ends. With the new filter pipeline, I can take duds and combine their logic. There’s a greater chance I might be able to salvage a filter by combining its effects with another.

Some of my most interesting recent results are the product of chaining filters together. What makes this even more interesting is that I can run the program on autopilot and let it iterate several times and if I don’t see favorable results, I can just pause execution and re-wire the filter chain. This wasn’t possible with the old program.

Enough chatter, show me the goods

The images you see below started out as photos taken on Lake of the Woods.