I’ve been using Unity for several years now but have wanted to shake it up a little. Over the past couple years I’ve been hearing about some open source alternatives, and Godot is one of the prominent ones making the rounds. I’ve been meaning to play around with it for a while now, but haven’t found the time until now. There’s currently a community game jam going on right now for Godot so I decided to participate with a learning project. I’ve made something very small that can be played online on itch.io here. Now that I’ve made something (albeit very small), I have a better idea of how to work with Godot, so I thought I would give some of my thoughts on it.

Learning resources are difficult to find

When starting work using any new tool, there are a couple different ways you can approach it. Often, I’ll first try to jump right in and make something. With Godot, I hit a road block right away. There’s a graphical interface that might look similar to something like Unity at first glance, but terminology differs greatly and it requires you to work in a very specific manner. Following this I decided to check some tutorials online, but this posed another road block. I found that tutorials tended to either skip over some of the basics, were for older versions that were hard to follow, or tried to show you something very highly architected and again, difficult to follow. I tried following some of these and downloading some sample projects, but quickly fell off. What actually worked best, was Godot’s own documentation where they show you how to build an extremely bare bones version of Pong. The tutorial is literally one page long, but introduces you to node system, input mapping, asset importing, and script editing. While this was a very basic tutorial, it got me started on making progress with my own simple game without trying to go too in depth on the rest of the features of the engine. At this point, I was able to figure out most problems simply by exploring the Godot docs.

Not all editors are treated equal

One of the nice things about time tested commercial game engines like Unity and UE4 is that they have robust and easy to use scene editors. When you launch Unity, you can very easily move around a scene with the arrow keys and rotate your view with a right click. If you know how to play an fps, you pretty much know how to move in UE4. Godot on the other hand…well, I still don’t really know how the 3D scene viewer works, and the 2D viewer still feels cumbersome to navigate. This brings me to another issue. I do all of my game development right now on a 13″ macbook pro. While I don’t expect full featured game engines to cater to laptop developers, there are some very basic issues that cause me big headaches while developing in Godot that I hope can be remedied in later versions. Mainly, scroll acceleration is all over the place and makes it really difficult to zoom in an out of a scene accurately as well as being difficult to scroll through the inspector or built in code editor. The one caveat I would say to this is thanks to the open source nature of Godot, I could feasibly look into fixing this issue myself or at least participate in the discussion of getting it fixed. One last issue that I never fully understood is that at one point the editor was continually using about 30% of my cpu while in the background, causing my fans to spin up and my battery to drain. There’s an indicator in the top right of the window that shows when the editor is doing a redraw and it was always spinning. I tried hitting some toggles and it seemed to do nothing. Eventually it fixed itself, so I don’t know what exactly caused this. This is just something to keep in mind, since this is a tool still in very active development.

Custom language, the good and the bad

When working with game engines, one of the concerns is how they expect you to make your actual code. Unity uses C#, Unreal uses C++ and a built in visual scripting language. There are engines out there that use these, or python, or ruby, or java, etc. Godot bucks that trend a little bit by using their own scripting language that looks a lot like python, called GDScript. Using GDScript seems fairly easy and more importantly, the api around it feels clean and simple to use. That being said, it still means you have to learn the quirks of a new language, especially if you haven’t used python before(I’ve dabbled in the past). It also means you either use the build in editor, or have to find syntax support for your favorite editor. Luckily, while it has some quirks, I found the built in code editor to be pretty decent. It’s fairly fast and does a great job of autocompletion based on both the api and your scene hierarchy.

Learn from my mistakes

All told, I was able to make something playable in a fairly short amount of time, despite some learning curve problems. Here are a couple things I learned that might be helpful.

If you want to have a button, a simple way to do it is by adding a button node to your scene, then going to the “inspector” at the bottom right and changing it to the “node” tab. From there you can select “pressed” and at the bottom hit “connect”. From here you can select the node with your game logic and connect it. This will automatically make a function in your script that gets called when you press the button.

If you want to actually export your game to either an executable or to a web/mobile version, you have to separately download the “Export Templates” file on the Godot downloads page and install that file by going to the “settings” button in the top right of the Godot editor and clicking “install export templates”. I didn’t realize I had to do this and when you try to export before doing that, it doesn’t tell you that anything is wrong. It will even build files that don’t work. It’s possible that I had an old version of the templates already installed, but I really wish it would have told me. This is a mistake that cost me several hours of trying to figure out why my builds didn’t work

In Summary

So far I’m pretty impressed with Godot. It has some weird quirks and there’s a lot I still don’t know, but when I got into a flow, my turnaround time on added features and edits was very fast. After getting over some hurdles I’ve also found that the flow on some features is pretty slick. I’ve just scratched the surface, but I’d like to spend some more time with it.