Posted On: 2023-11-06
As I mentioned in the previous post, I recently switched to using Godot, and have found the new workflow much better than anything I had while using Unity. For today's post, I thought I'd cover three specific advantages that Godot brings. Importantly, many of these are new or improved with Godot 4, so earlier versions won't see these same benefits.
The C# language is continuously improving, and as new features and design paradigms become available developers gain new ways to solve problems and (potentially) improve their own productivity. Unfortunately, many of these require support from the underlying framework, and most engines (including Unity and earlier versions of Godot) only work on specific versions of specific frameworks. As a result, which language features are available is entirely controlled by the engine creators.
With Godot 4, however, some of that control has been loosened, and now game developers define which framework version the engine uses (rather than the other way around.) While it's still somewhat limited (it cannot be older than .Net 6, since that is used to build Godot itself), it was specifically designed to accomodate newer versions of the same framework - making it easy for developers to use the latest language features.
Designing an appealing interface is seldom a simple task. While arranging and designing the general locations of things is an art, getting the specific positions and ratios between elements requires the precision of an engineer. Tools tend to favor one or the other of these two, making it difficult to create something that is both artistically interesting and precisely arranged.
Anchors (which are used in Unity, Unreal, and various other systems) are often useful for defining the relationships between elements, but are not great for repeating patterns or fluid layouts. Designers have to explicitly specify where objects are in relation to other objects, which can be tedious and error-prone, and anchors are limited to only holding one relationship (usually the parent object), making it difficult for an object to be positioned relative to one object (ie. centered below a popup), but scaled relative to another (ie. 50% of the width of the screen).
Containers (as they're called in Godot) serve as an alternative paradigm: where anchors define object sizes in terms of ratios and relationships, containers implicitly size themselves based on their settings and content. As such, containers offer a quick way to get things mostly right - as well as a flexible/reactive system that gracefully handles a wide variety of input (ie. user-generated content). While containers offer fewer ways to customize how they display, they implicitly provide precision: scaling and positioning child elements along select axes, making it easy to accomplish many common layouts (ie. grids, lists, etc.)
Despite the signficant differences between anchors and containers, Godot lets developers mix them together however they wish. This makes it possible to use each for their respective strengths, allowing developers to create dynamic and expressive interfaces that naturally stretch and scale to fit their contents.
The Event Pattern is at the heart of nearly every user interface. Buttons and windows respond to user input, and they do this by defining how they should react to some input (ie. clicking a button), and then patiently waiting until that input happens. C# provides first-class support for events, which makes it simple to work with them, while the language itself enforces best practices (ie. only a button is allowed to say when it's been clicked - no other object can claim that the button's been clicked).
Godot 4 (unlike Unity and earlier Godot versions) leans into this, exposing every event in the entire Godot engine using C# events. This makes it much easier to design interactive elements, and enforces constraints so that they remain well-designed, regardless of the project's scale. Using the language's support for events is also a massive help for C# developers learning Godot: development tools (such as the IDE) are designed to make it easy to discover methods, properties, and events - and clearly distinguishes which type each belongs to. In Godot 4, a developer (with help from an IDE) can spot a relevant event in seconds, whereas engines that rely on so called "magic strings" for their events (ie. Godot 3) require developers to comb through documentation, cross-referencing which events are supported on which types, and which scenarios they represent*.
While these three features are great, Godot isn't without its downsides. Ideally, I would provide an example weakness for each advantage I listed, but I am simply not familiar enough with Godot to do that properly. Many of the issues I run into right now are simply due to being unfamiliar with the engine, and there are plenty of places that I assume work correctly, but I may well be mistaken. Thus, I'd like to close instead by simply saying that every engine has its weaknesses and Godot is no different - even if I am enjoying it immensely at the moment.