Godot – A game engine as a UI framework?

Since the move by the Qt Company to restrict LTS versions to commercial licenses it might be time to look for alternative free open-source UI frameworks. Instead of looking at flutter or one of the multitude of web-based frameworks we will try a different angle and take a look at Godot. Now, Godot is an open-source game engine, not a dedicated UI framework, but since games usually have quite individual user interfaces, it supports the development of highly customizable UIs. In fact, the WYSIWYG editor of Godot itself is written in Godot.

To start developing in Godot you first need to download the Godot editor. The editor is only ~70 MB in size and can be executed immediately, no installation is required. This is especially useful when you want others to try out your UI. Since they only need to download a few MB, they can be up and running within a few minutes.

In Godot, the basic building blocks are ’nodes‘. These nodes include data and behavior. A script that modifies the default behavior can be attached to each node. The nodes are grouped into ’scenes‘. Scenes are trees of nodes that can be instantiated and reused as nodes in other, higher-level scenes. Each program needs to set a main scene that serves as an entry point. This means there are two main types of files in a Godot project: Scene files that describe the grouping, interconnection and properties of nodes and script files, containing additional logic. Our Main scene in the picture above contains three nodes. The LoginScreen and ContentScreen nodes are themselves scenes, while the AnimationPlayer node contains the screen transition animation. While the scene files are generated by the editor, the scripts are handwritten using either GdScript, VisualScript or C#. You can find the code for the above example here.

Similar to Qt, Godot employs a signal/slot mechanism where UI components expose various signals (such as pressed/released for buttons, or textChanged for text inputs and labels) that you can hook up to callback functions (slots). The connection between the signals and slots can either be done via the editor for static connections or from within the script if the connections need to be dynamically generated.

While UI components can be assigned positions and dimensions in absolute values, it is often desirable to create responsive UIs that adapt to resolution changes. For this, we can use container nodes. Container nodes are responsible for the alignment of their children. For example, there is a node for centering its children, one for enforcing a margin, one for creating a grid layout for its children, and so on.

To connect our UI to some backend, we can make use of Godot’s websocket client. In order to produce an executable from our Godot project we need to use an export template. Godot provides export templates for the most common platforms (for games), such as Windows, Linux, Android and iOS. You can also find instructions on how to create your own template for a raspberry pi here.

While using the editor to quickly assemble a UI is fairly straightforward there are some problems for larger projects.

The WYSIWYG part of the editor can be misleading when combined with layout containers. The editor will display component positions based on absolute positions, sizes and margins. These properties are often ignored by the containers during execution. Similarly, the hot reload functionality doesn’t work with some script changes, especially ones that concern initialization. In the end, you’ll end up constantly restarting the app to be on the safe side.

The dependency on the editor to create scene files is also a problem during remote pair programming since they cannot easily be written using e.g. VS Code Live Share. Each UI element may consist of two files, which can contain redundant or even contradicting information since we can override every property of the scene file in the ‚_ready‘ function of the script. This is also a problem during code reviews since you always need to look at both files in conjunction. It doesn’t help that the scene files are optimized for avoiding merge conflicts, not human readability.

All taken into account, I will probably still use Godot for some one-person hobby projects, as it is easy and quick to set up, but I wouldn’t want to use it in larger projects when pair programming, tests and reviews are the order of the day.

You can find more information on related topics in our fields of competence.