Jumping aboard the Godot train

Wed, 28 Feb 2018 by Thomas ten Cate · Comments
 Game Development, Godot, Alakajam

As an indie game developer, I find that it’s important to invest time to get to know your tools really well, so you can make the most out of them with the least amount of time. This is often at odds with the urge to try something new and different, which will set your productivity back to square one. But with the eagerly awaited release of Godot 3.0, I felt that the day had come to check this thing out, and see if it could be of future use to me.

The occasion was the 2nd Alakajam! game jam, a Ludum Dare spin-off organised in the months that LD isn’t. If you don’t aim to win, a game jam is perfect to try something new, because you get time boxing for free. The game I made is called Misty Isles, and you can play in your browser here.

Enough with the intro already. What was my Godot experience like? Overall, I’m really happy with it, and I want to get to know it better. Don’t be put off by the long list of negatives that’s about to follow; those are mostly small things that can quickly be gotten used to, or easily be fixed!

The good

• The engine feels really solid and the editor is fast and responsive. I did not encounter any bugs.

• The API is very well designed conceptually. You build a game by composing nodes into a tree. Nodes can be of different (built-in) types, like Sprite, Path2D, Node2D (generic grouping thing), and also behind-the-scenes stuff like Timer and Tween. I’m sure it’s somehow possible to write your own node types, but I don’t think you’ll often need to, because scripting can add the functionality you need. It’s composition over inheritance all the way, and I love it. You can compose trees as well, by making them into a reusable scene, like a Monster or a ParkBench. And scenes can inherit from each other too, so you can make small variations.

• The build-and-run cycle is really fast. It’s less than a second between hitting F5 and having your game show up. Speaking of running, F6 runs the scene you’re currently editing, which is awesome for testing a particular level or other entity in isolation.

• The built-in GDscript language is alright. It’s been compared a lot to Python, because it looks syntactically similar. This is misleading, because it’s enough unlike Python to be a wholly different language. For instance, built-in types like Vector2 are value types rather than reference types, and functions are not first-class citizens. Scripts can be attached to any node, and can access that node as self, but they can also traverse the entire tree up and down. This means some discipline is required if you don’t want to end up with an unmaintainable mess. Propagating stuff upwards through signals and downwards through exported properties seems the way to do this.

• Documentation is fairly complete, especially for an open source project. However, the structure of the docs could be better; I often stumbled by accident onto pieces of information that I had needed, and searched for, hours before.

• The built-in documentation viewer is pretty nice, especially because it contains hyperlinks. Better integration with the editor would be nice though (think IntelliJ’s Ctrl+Q for showing JavaDocs of type/method the cursor is on, and Ctrl+P to show parameters of the method call you’re currently typing).

• I struggled a bit with setting up a Makefile for exporting my Inkscape SVG files to PNG for use in Godot, before I realised that Godot had been quietly importing my SVGs already all along! It does seem that some effects are not supported though, like blur and clipping.

The bad

• That update spinner! There is a spinner at the top right that spins when the UI is updating. What the…?! Really?! I can see that the UI is updating, because the frigging UI is updating. As a debugging aid for Godot core developers, sure, but don’t stick this thing in every user’s face by default. And if you absolutely must have it, at least remember between runs that I turned it off.

• Code completion in the editor does not always work. It mostly seems to complete function names on the current node and on nodes whose names were hardcoded in that very line, but it doesn’t seem to have much smarts beyond that. It’s a hard problem to solve though, especially for dynamic languages.

• There is a style guide for GDscript, but neither the autogenerated code nor the documentation follows it. In particular, they put spaces on the inside of parentheses ( ugh ).

• It would be nice to have some better refactoring support. If I rename or move a node, many references from code to that node could be updated automatically. I concede that this isn’t always possible, but it should be easy enough for the common cases. Alternatively, provide a way to find nodes without referring to their position in the tree, for example using an “id” (which should be unique within the branch you’re searching). If this feature is there, I haven’t found it in the docs.

UI structure

• The order of the menu bar is Scene, then Project. Illogical, because Project is the overarching container, and acts like the “File” menu in most other GUIs.

• The organisation of the UI is confusing. There are buttons 2D, 3D, Script and AssetLib at the top, which may be intended as different “workspaces” for different roles (artist, programmer, level designer), but don’t really work out that way. Tabs represent scenes, which are 2D or 3D, but it visually looks like all your scripts are also “on” a tab, even though they stay if you switch between tabs. One tab per item (be it a 2D scene, 3D scene or script) would make much more sense to me. However, it is convenient to see the tree of the node you’re currently scripting against.

• Similarly, the pane at the bottom right contains the Inspector, where you set properties of the current Node, and then Node, which itself has two tabs, Signals and Groups. Why not make this a three-tabbed thing, with Properties, Signals and Groups on equal levels?

• It would be more logical to have the Import pane on the left by default, below the FileSystem. Admittedly, it would take up valuable space there, so maybe that’s why it’s currently in the same spot as the Scene pane.

UI gripes

Note that most of these are really nitpicky, and no doubt you quickly get used to them. It would just be a better first experience for newcomers if these things were fixed.

• Menus act a bit differently from all other UI toolkits. You can’t click, drag down, release. You can’t hover over another menu to open that one instead. A second click to close them doesn’t work if it follows too soon after the fist. Dropdowns can’t be closed at all by clicking them again; you have to click outside them. It all feels a bit clunky for 2018.

• Shortcut keys for 2D/3D/Script are F1, F2, F3, respectively, while F4 is Help. So F two opens three D, and if you want two D, you have to press F one. Wouldn’t it be much more intuitive to have F2 for 2D, F3 for 3D, and F4 for Script? Bonus: Help can be moved to the almost universal standard of F1. (I can probably change this in the settings, but it should be the default.)

• Hovering over a checkbox in the inspector tells me in a tooltip whether its value is True or False. A bit pointless.

• The Delete key doesn’t always do what you expect. In the FileSystem browser, it deletes the currently selected Node. In the Signals pane, it deletes the currently selected Node. In the Groups pane, it deletes the currently selected Node. Sense a pattern?

• Similarly, Ctrl+A doesn’t do Select All in the currently active pane, but wants to add a node regardless. This should be something like Ctrl+N instead (which isn’t used for New Scene either).

• The search function within a help page is annoying. It pops up a dialog on top of the text you’re searching, doesn’t let you press Enter to dismiss it, and makes the entire text too dark to read to boot. The search function within script code is much better, and should be used for docs as well.

• The ubiquitous ellipsis (…) to indicate that a menu item will pop up a dialog is not always present. And when it is, it’s spelled as .. (two dots).

Conclusion

The “bad” list is much longer than the “good” list, but note that the bullets on the “good” list are all big points. The “bad” list are mostly little points that are easy to fix. In fact, if I do choose to adopt Godot for some future project, chances are that I’ll fix some of them myself. Overall, it was a pleasant experience, so chances are good!