At the end of November, I started looking into learning a new game engine in preparation for the next Ludum Dare game jam. My first Ludum Dare experience was so much fun that I knew 100% that I wanted to try it again… And one of the biggest things I wanted to do differently next time was to use an actual game engine. I’d used ReactJS the first time – which worked fine for UI stuff, but not so much for sound / animations / general polish. And as much as I’ve been dabbling in SpriteKit for iPhone games, it’s not very well suited for a game jam where ideally you’d want your game to be playable directly in the browser.
So after some research and recommendations, I decided to give Godot Engine a try. I started reading the docs and playing around with it in the few days leading up to Ludum Dare #43… And I went on to create and submit a simple but reasonably complete game over the course of a weekend. I’m planning to write up a full “postmortem” blog post on the whole game jam once the rating phase is complete, but for now, you can check out my entry here. And in the meantime, I wanted to share some thoughts on Godot Engine from the perspective of someone diving into it for the first time!
But First, More Background
Godot Engine is a completely free and open source 2D and 3D game engine. Feature wise, it seems to be pretty similar to Unity. (Which I’ve also heard a ton about, but never used firsthand.) It has a cross-platform visual editor, and it lets you export your games to desktop (Windows / Mac / Linux), mobile (iOS / Android), and web (HTML5). It’s nowhere near as popular as Unity in terms of the total number of users, but seems to have an enthusiastic community behind it, and this (combined with the free open source aspect) was what convinced me to try it over Unity.
I could see it being a little overwhelming when first trying to learn a new engine. Where do you even start? Here are a few resources that I found really useful:
- Godot Engine’s Official Docs, and in particular, the Step By Step Getting Started Guide (I felt like I got a good head start just by binge-reading this during my train commute).
- A few videos and tutorials from GamesFromScratch – specifically I found the buttons and sprite animation ones helpful early on.
From there, though, I think the most valuable thing for me was actually making a small game using the engine. And what better motivation to make a small game than participating in a weekend game jam?
The Awesome Parts
Once I got started, there were quite a few things that went really smoothly and that I enjoyed working with. This list isn’t exhaustive, but highlights a few:
- The Editor. I found the UI to be really pleasant to work with. It feels clean and uncluttered, and really lightweight as far as the amount of memory it needs. I also liked that you can move the panels around if you want. (This is all based on using version 3.0.6 on a Mac.)
- Buttons. After spending multiple days implementing my own crazy button system in SpriteKit, it was fantastic to have a built-in thing called “Button” that you could just plop onto the screen, and hook it up to a function, and have it all just work right out of the box.
- The Node System. In Godot Engine, everything is a node. You can structure your scenes in hierarchies of nodes, where each node can have different behaviors and properties. Coming from SpriteKit (which uses a similar scene structure) I found this to be really intuitive to work with.
- Animations. I’ve only really worked with sprite animations so far, but have found the UI for viewing and editing these to be really nice and intuitive to work with. (My game jam game ended up having like 18 different sprite animations with over 200 individual frames, and it wasn’t painful to manage at all.)
- Tile Maps. The system for working with tile maps was interesting. Basically individual tiles are nodes too, and can have child nodes. (This comes in handy for adding stuff like collision polygons to them.)
The Challenging Parts
There were also a few areas that didn’t go quite as smoothly as I would have liked. Only two specifically:
- Signals. Signals are Godot Engine’s version of the observer pattern. While I had no trouble hooking up pre-made ones (like a standard Button), at one point I tried to set up a custom signal… And it was the one thing I tried that I just couldn’t get to work during the jam. For the deadline, I ended up just stuffing references to everything I needed into one big horrifying singleton and then accessing it all directly… Which worked out well enough, I guess, but I didn’t feel good about it. So I’ll need to come back to this at some point and figure out how to work with custom signals properly.
- GDScript. Godot Engine’s own custom programming language. This one isn’t really challenging as far as difficulty goes, but rather more of a preference thing. GDScript is a lot like Python, dynamically typed with indent-based blocks… And Python is probably my least favorite programming language to work in for exactly those reasons. (For those who do like Python, of course, this one probably belongs in the “Awesome” column.) But on the plus side, Godot Engine also officially supports C# as a scripting language, which is more in line with the type of languages I tend to enjoy programming in.
Overall, I really enjoyed working with Godot Engine. I’m kind of amazed how easy it was to pick up… Less than a week between downloading it for the first time and submitting a Ludum Dare game. That experience may not be typical for everyone (having worked with SpriteKit before in addition to general programming experience probably helped a lot) but I think it says something about the quality of the documentation, and the amount of resources and StackOverflow answers and such out there.
Plans Going Forward?
All that brings me to the question: What shall I do with it next?
That’s a tough one. I still really enjoy working with Swift and SpriteKit, and plan to follow through and finish the small iPhone game I was working on. From there, though, I’ll have some soul-searching to do. Being limited to the Apple ecosystem is the one big drawback of SpriteKit that has been weighing most heavily on my mind… And switching to Godot Engine for future projects would solve that problem, making it possible to more easily release on multiple platforms.
The only drawback would be the sense of losing progress or going backward. I’d been building up my cozy little SpriteKit codebase with the intention of making certain parts reusable for future projects… And switching engines would make all of that useless. But that may be a matter of falling into the “ Sunk Cost Fallacy” if switching to Godot would provide better value and fewer drawbacks over the long term.
So in conclusion: I’m leaning toward it, but will put off any final decisions until it’s time to start working full speed ahead on my next real project.
And that wraps up my thoughts on venturing into Godot Engine for the first time! Coming soon on this dev blog: exciting installments such as the next progress update on my little iPhone game, and the full postmortem on Ludum Dare #43 with all the juicy time management related details. For anyone who’d like to follow along, feel free to follow on Twitter, subscribe to the blog’s RSS feed, or sign up for the email mailing list. Thanks for reading!