I recently made my first “real” game in Godot: Corporate Fulfillment 2058. It’s a puzzle game where you combine materials to make products for amoral corporations. As you might expect from the name and the screenshots, it’s inspired by games like Threes and 2048, but instead of simply trying to make larger tiles, each level gives you a different set of components and asks you to make a different set of products from them. Some levels mix up the rules by requiring you to ship out finished products yourself, or giving you more control over how you move tiles around, or even by disabling parts of the play space. The game is available right here for Android and right here as an HTML5 version, if you want to play it.
This isn’t the first project I’ve made with Godot; I’ve made a simple endless runner and a game jam entry previously. This is definitely the largest and most complex project I’ve made with the engine, however, and I have some thoughts on using the engine. The process was mostly smooth, with a few… quirks of the engine, and some bugs I ran into, that caused some difficulty.
UI
I don’t like doing UI work. I don’t think anyone especially likes it, but it’s one of my least favorite parts of game development. Using Godot, however… well, I still don’t like it, but it’s less painful. At least, it’s less painful now that I have a better understanding of how the Control nodes work. For a while I was running into confusing issues where buttons and text weren’t always behaving how I wanted them to, due to the nodes they were parented to. I feel a lot more comfortable with the Godot way of building a UI now, so I can appreciate some of the decisions that I would have criticized before.
GDScript
I haven’t used python in quite awhile, so back when I started using Godot I was wondering how easily I would adapt to using GDscript. My previous projects taught me rather well, and by the time I started this game, I was only occasionally turning to the reference to refresh my memory. Why did I use GDScript instead of C++ or C# or another language? Well, mostly because I didn’t want to do the work to set up support for another language.
GDScript certainly got the job done. CF2058 isn’t a particularly complex game, and it’s not pushing the engine to its limits, but it’s not a trivial project. Using another language with Godot for the sake of performance was unnecessary for this project., and with the speed at which I was able to prototype my ideas with GDScript, I was having a great time. Of course, there were a few sticking points.
One of these was the fact that GDScript is very loose when enforcing some of its rules. Specifically, the fact that I could accidentally use an enum value that doesn’t exist, or access a non-existent function of an object, and these wouldn’t be caught until that particular line of code executed. I was bit by both of those specific examples, and more, spending several hours tracking down and fixing bugs that would have been caught at compile time in a language like C++. That was certainly annoying. GDScript makes some compromises for the sake of ease-of-use, friendliness, and prototyping speed, and that’s great! However, I really wish a few more mistakes could be caught immediately upon hitting compile/run.
Speaking of compiling, another feature I wish GDScript supported is conditional compilation. Sure, I can use OS.has_feature(“mobile”), to have specific behavior on mobile devices, but I’d prefer not to have these checks at runtime. Additionally, there are cases where I don’t want to include, for example, some code for particular features in a demo version of the game. This is especially true for HTML5 builds, where the source is more easily accessible. I’d rather not have to worry about someone being able to access levels or features that aren’t supposed to be in the demo. I ended up just having multiple versions of a couple source files that I swap manually for demo/non-demo versions, but that’s a kludgy solution.
The Editor
The 2D and 3D editors work well enough, and I don’t have much to say about them. I do, however, need to complain about the text editor. It’s fine for the most part. It gets sluggish sometimes with large scripts, but that’s not a huge issue. What is a huge issue though, is the frequently-breaking undo/redo stream.
Here’s what happens: I’ve just written some code, say added a function call:
- somefunction()
Then, after running the game, I decide I want to change this to a different function. I select the function name and type a different function name:
- anotherFunction()
So far so good. I run the game again, then decide I want to see what happens when I run the original function again. I just hit undo:
- someFunction
Uh oh, the parentheses are gone! Maybe if I hit redo it will correct itself?
- anotherFunction
Nope. The undo/redo stream has become corrupted, and no amount of undoing or redoing will put this code back into a syntactically valid state. This is an easy to fix example, especially because I’ve only hit undo once. It’s still quite annoying, though. In cases where I’ve undone more than a few edits, or the corruption is more than missing parentheses, this issue becomes rather scary. I no longer have valid code that I’ve written. I notice this issue often, but what if it’s happening at other times when I’m not noticing it, because the game compiles and runs? This is one of the most annoying issues I’ve encountered with Godot, and is the main reason I’m using an external editor to write my scripts.
Oh yeah, Godot also supports external editors. That’s a good feature.
Shaders
I don’t really have a lot to say on the subject of shaders, except that the ability to immediately see the effects of a shader in-engine, as you write it, is pretty awesome! I hadn’t done much with shaders before, so without this feature the process of writing and testing them would have been much slower, which probably would have caused me to use fewer, and simpler shaders than I was able to use.
Exporting
The export process is actually pretty nice. Setting up export templates is quick and easy, and afterward, exporting for a platform just takes a few clicks. The export menu offers customization of many options, and for Android at least, allows for a custom manifest for additional customization.
It’s easy to select which resources to include in a build, to update the version number and build code, and to change whatever other settings are necessary. It’s even possible to have multiple export templates for a given platform. This is probably the easiest time I’ve had building games for Android. The only criticism I have to offer is that the option to toggle a debug build is almost hidden. It’s just a small toggle on the final “Save a File” dialog.
Other Stuff
I have approximately 490 assets in the project. At somewhere around 150 assets, Godot slowed way down at startup. Other projects with few or no assets don’t have this issue, so I know it’s not due to a newer version of the engine or something similar. I remember being impressed with Godot’s speed way back when I first took a look at the engine, but with a “real” project, startup times are not impressive any more, often taking well over 45 seconds to load from an SSD. With more assets, in a larger project, I’d expect the engine to be even slower to start up.
It’s not just startup times that are quite long, however. In my smaller projects, saving open scenes and launching the project with the debugger are almost instant. With CF2058, Godot often takes almost a minute to become responsive again. It’s not the most annoying issue in the world, but it’s a real pain when trying to make iterative changes.
The good news is that Godot’s live reloading works quite well! Making changes to an object’s position in the editor, or an object’s script while running the game was super useful. If it weren’t for this feature, the long wait for the project to save or the debugger to launch would be even more of a momentum-killer.
Overall, I really like the Godot engine. It makes prototyping super easy and fun, and I’ve watched the engine get better and better with each release I’ve tried. I’m hoping the issues I ran into will be solved, and the sticking points sanded away, making for an even better piece of software.
Thanks for reading my thoughts. If you would like to check out my game, either on itch.io or the Google Play store, I would certainly appreciate it! :)