Making Advanced GUI Applications with Godot

I have been trying out the Godot Game Engine lately, and I have been mightily impressed with what I see.

While it was designed to make games, it has an exceptionally sophisticated system for making graphical user interfaces. I think this is the future for advanced GUI applications. Not convinced?

Look at the the image below. This is from the Godot Editor. It looks pretty sophisticated right? You got:

• A canvas of nodes connected nodes used in a visual programming system (in addition to several other supported programming systems).
• Resource management.
• A sophisticated tree widget for manipulating a scene graph.
• Inspector with properties you can filter.
• Code editor with syntax highlighting, advanced code completion, jump to definition, realtime warnings etc.
• Tile map editor, animation editor and tons of other editors for audio, and many other things I haven’t even gotten time to explore.

How do you think they made such a sophisticated GUI? Was it Qt? Electron? Cocoa?

No, this was all made with the Godot Game Engine itself. They are really eating their own dog food . So everything you see here you can accomplish in your own application using Godot.

Sure you can find sophisticate GUIs like this through other tools. E.g. some of the competing engines use Qt to make their editor.

It is Tiny

But here is the kicker:

All of Godot with Engine end Editor is a mere 31.1 MB download. One click installation and the editor launches instantly.

When I unpack and install it is still just around 70 MB. That is an absolutely tiny install relative to the amount of functionality you get. Let us put this a bit in perspective. Merely downloading Qt5, requires 5 GB of free space!

Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB.

How about Xcode? Downloading it is over 5 GB. After installation it takes around 10 GB on my hard drive. That is a different league altogether. Android Studio is 500 MB, and Android SDK is 1.5 GB. These things are big, despite the fact that it is not clear that they offer significantly more functionality than Godot.

Keynote which is just for presenting stuff comes in at a hefty 433.5 MB. And that probably excludes shared frameworks, it uses.

Let is look at what kind of applications Godot compares with in size. 1Password which manages passwords is 55.5 MB installed. Quite close to Godot. Mail is about 30 MB, Photos 50 MB.

In other words Godot is in size much close to applications with a very narrow set of functionality.

It is a Blast to Use

Godot GUI design is insanely fast to work with compared to what I have been used to before. They have really thought through so many of the common problems when constructing a UI.

You centers your GUI building around the scene tree shown below.

You can move up and down this tree with the keyboard. So I can e.g. use the arrow keys to move to a container or panel I wish to add a GUI component to. Then I can hit Cmd+A (on Mac) to open up a dialog to select a GUI component.

You get the dialog below popping up.

Now you can expand a large tree showing tons of nodes here using the mouse. But what is very efficient is that when the dialog opens you are immediately in the search bar. I can start typing “Button” to see what button like nodes exist. As I am typing the list gets filtered.

While this is happening I can at the same time move in list with my arrow keys to make a selection. I don’t miss focus on the search bar even if I do that.

So I can just select the node I want and hit enter. It get added as a child to the node I had selected earlier.

This way I use the keyboard entirely with arrow keys, Cmd+A and Enter to build up a GUI. If I hit enter on a component I can change its name. If I hit Cmd+D I duplicate it. Hence I don't need to open and search for say a label multiple times. If I know I need 10 labels. I can just make one label and duplicate it 10 times.

Sane UI Component Selection

But the efficiency in which you work with this system does not stop there.

One of the most frustrating things for me in various UI design tools is selecting UI components made up of multiple other components. E.g. in Qt Creator I would frequently try to select a layout containing child components only to accidentally select a child component and pull it out of the layout.

In Godot accidentally selecting a child component is not a problem. Notice the little icon I have circled in pink next to the MarginContainer below. This icon got toggled because I had earlier clicked on the icon in the toolbar circled in yellow. It makes it so children cannot be selected on the canvas. I can still select them in the tree, but if I click on the component as it is laid out I will get the parent instead.

This is really practical because it makes it easy to deal with layouts. In other editors selecting a layout can be tricky. Another important detail in Godot’s favor. You don’t change parent relationships on the canvas, only in the node tree. Hence you don’t accidentally pull out a component from a hierarchy. All you would do in that case is to change the relative position of a child component to its parent.

Superior Customization of UI Components

In any advanced GUI you will need a lot of special customized GUI components configured in particular ways to fit your application.

This never plays nice with traditional GUI designers. You may be able to subclass a component but often it will just show up as a gray rectangle in the GUI editor.

And if it does show up, you cannot configure it much. Everything will typically have to be done in code. Not so with Godot.

In the image below you can see we have attached a script to the node called ColorPicker which is of type OptionButton . Attaching a script to a node in Godot is the equivalent to subclassing that node. That is why you can see the script code says extends OptionButton .

OptionButton is a dropdown menu. Out of the box Godot does not have any mechanism in the GUI for specifying what elements it should contain.

However we can add our own properties to the Godot Editor’s inspector for any scene node object. You see in highlight I have written this code line:

export(Array, String) var itemvalues = ["red", "green", "blue"]

This tells Godot that the member variable itemvalues should be visible in the Godot editor. I also tell it that it is an Array with String elements. The language used, GDScript is dynamically typed so these are more like hints.

The result of this is that you can see that when ColorPicker is selected the Inspector shows an entry for itemvalues where I can modify elements. You can see I changed the last value from "blue" to "cyan" in this example

The _ready function gets called when the component has been loaded into the scene and is ready to be used. In this case we use the opportunity to read of what the user had set itemvalues to and add each entry to the dropdown menu box.

The cleverness does not stop at that point. If I duplicate this component and use it elsewhere the same attached script will be used. If I change the code on one component it will change on all others. Thus they do not easily get out of sync. If I truly want custom behavior I can detach the script on a particular component. Or I can extend it with a subclass to refine the behavior.

Editing and Modifying Running Applications

I could go on about dozens other little details which makes GUI editing a breeze in Godot. But I hope I have gotten across the point that they have really thought about ergonomics.

So many of the problems I have faced in the past hindering me from working efficiently with GUIs they seem to have anticipated.

But perhaps the real killer feature is that you can run your application and modify its GUI layout and the code of attached scripts while it is running and those changes get immediately reflected in the running application.

Sure this kind of functionality where you can edit code while you are running exists many places in some form. But if your experience is anything like mine you know this stuff tends to be quite brittle and limited if you deal with compiled languages.

Godot uses a dynamic language with Python syntax called GDScript which was specifically tailored to integrate with the editor. This means it was designed to handle reloading and syncing. And you can tell it works really well.

It is a super easy language to learn. I picked it up in basically a day. It integrates exceptionally well with the engine.

You can command click on anything to jump to its documentation of definition. You get great command completions. Even though it is not really a statically typed language it is amazing good at figuring out types. And just like modern Python you can add type hints wherever you want to improve the guessing.

It not only completes type names and function names. It will even complete strings when you are writing paths to nodes in the scene graph.

What About the Competition?

The alternative is of course to use something like Electron, Qt Widgets, Qt QML or Cocoa. The first issue with the alternatives is that they are huge bloated lumbering beasts.

Think about it if somebody wants to look at some GUI you are working on, you can send them the Godot project files and they are a 31 MB download away from looking at it. Oh did I tell you that Godot is entirely free, open source and under an MIT license?

That is right, anybody can download it at no cost and do whatever they want with Godot.

Qt Widgets

Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find the free version.”

Not to mention that if you use Qt Widgets which is supposed to be used for large professional GUI applications which is my topic of discussion here then you have to use a GUI designer which quite frankly sucks. In fact that is why I made my own markup language ERML, just to allow some more sane editing of Qt ui files other than Qt Creator’s GUI.

Why does Qt Creator suck you ask? Many of the things mentioned through this article. Selecting and working with nested layout of components is next to impossible. And the object tree structure doesn’t let you do anything useful.

It is basically a “write-only” system. You can make a complex GUI fairly well, but good luck coming back to it later and making significant modifications. You will beak the layout and you will not remember how to put it back to how it was before.

And there is no sane way to define custom components which you want to use in the editor. In Godot this is trivial. You can make arbitrary complex components made up of other components and easily reuse them. Sure you can copy paste a collection of GUI components in Qt Creator, but if you decide you want to make a modification you are screwed.

In Godot in contrast you can use a collection of GUI components you made as a template. Change the template and all other GUI components based off that template changes as well.

Not to mention you cannot do life changes to you user interface. A Qt C++ project easily gets a very slow turn around time which totally kills productivity when making a GUI.

Qt QML to the Rescue?

So what about QML then? It solves many problems and utilize a dynamic languages which makes on the fly types of changes easier.

Honestly I don’t remember much of the details of what QML was like working with. I just remember it was not as intuitive as I would have wished. The editor took quite some time for me to wrap my head around and it really did not feel polished at all.

A lot of stuff just felt slow. The GUIs I made did not work great. Even fairly simple stuff was very bad in redrawing when I resized the window. Perhaps because it was made for mobile it was not optimized for windows changing size? I don’t know.

Despite various tests I could not get decent performance in drawing. But perhaps the biggest killer was that there was no comprehensive set of advanced widgets to build an advanced GUI application with.

Cocoa and SwiftUI

I have used layout managers based off a constraint based system when working on iOS applications in Xcode with Swift. It is a very powerful and advanced system.

At first I thought this was really the way forward. However in my experience it was just too complex to work with. Even for simple screens I sometimes ended up with really complex constraints which can be hard to debug.

While I have spent a lot of time with Xcode and Swift perhaps the ultimate test of how well it works is how much time you spend jumping into it again after being away from it for a while.

That did not work well for me. I cannot make sense of a lot of stuff I have done in the past. Swift is getting too complex. It is a nice language but it is developing some of the same problems as C++ and Haskell ironically. The complexity and strictness of the type system is getting in your face a little bit too often.

It is a double edged sword. When I began using Swift I loved how the strong typing caught many mistakes. But it was always with a mixed feeling, as battling the type system was a regular occurrence. Now it seems to have gotten worse especially when dealing with closures.

The whole setup just easily gives you a mental overload. I cannot be effective working with the system because I simply am not able to keep all the stuff you need to know in my head.

SwiftUI seems like a promising alternative. It is kind of following the same approach as QML. Which I think is a promising model. I am not against QML because I think it is a bad idea, just because I think it is poorly executed.

I have only used SwiftUI briefly. To me it looks like a clear improvement but IMHO it still falls short of Godot. While you get a GUI inspector panel for your GUI components you are still forced to largely write the GUI in code. I think GUI editing should support both. GUI design is a very visual process IMHO.

Perhaps more importantly one still does not have the ability to make live changes and modification to a running application. For a complex GUI application with large projects which have to be loaded before you get to the thing you want to test, this is a killer.

Electron, HTML5, CSS and JavaScript

My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000.

Still I must concede there are many things I like about web technologies. In the browser you can do live editing and changing of properties and see immediate changes to a GUI.

There are a couple of really big problems I see however:

1. It is really complex. My personal experience in learning modern HTML5, CSS and JavaScript frameworks take considerable amount of time. My attempt at giving an overview of different web technologies and how they relate may give a sense of this.
2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage.
3. It is not made for reusable components, like real GUI toolkits.

The latter needs some explanation. The web way of creating reusable components is through some kind of templating. You are basically just copy pasting a chunk of HTML several times representing your new custom component.

This means you are typically working through templating engines and there is no one to one mapping between what you are writing and what is going on in the web browser.

This contrasts with Godot e.g. From a development standpoint I can create a custom component and instantiate that. When I do live modifications while my app is running these things are one and the same. I got the same nodes in live application as when I was coding. This helps on he whole round trip and lowers mental complexity in working with it.

Now it may seem crazy to use a game engine for making an application given that it does steal more CPU cycles due to the need for constant rendering. However in many ways that pales in comparison to the resource hog web based applications are.

Editors like VSCode and Atom show that you can make some great stuff using web technologies. However we also have companies like Insomniac Games which tried making their game engine editors using web tools.

That was mostly a failed experiment. The problem as they saw it was that it works too poorly to make complex custom GUI components. Most use of web technologies today don’t have problem with that because the don’t use custom components. Atom e.g. doesn’t have color pick with a color wheel.

Why Are Game Engines the Future?

It seems crazy to use a game engine to make a GUI application. And people may feel it is instinctively wrong to do so.

But I think there are very good reasons why the world may end up that way. It is all about where the money is and what incentives are at play.

The gaming industry is huge. Games today have massive complexity rivaling most actual applications. Game development faces some rather brutal conditions to survive.

They must allow the development of very high performance code which squeezes every ounce of performance out of your computer. They have to do this while iterating and experimentation has to be really quick and easy when making a game. Games are almost be definition not something you can clearly define up front. A lot of tweaking, experimentation and playing will be needed to get a game right.

This has caused game engines to solve the problem that has faced those of us working on large complex GUI applications. Live modification of running code is a normal thing in the game engine world. It has to be. You cannot reload the whole damn thing each time you want to tweak something at a particular level you are trying out.

Combine this with the massive amounts of money thrown at the problem. Large complex GUI applications are a small niche, games are not.

This is why people who made simulators for robots eventually switched to game engines. The market for engines meant game engines where far beyond robot simulators in quality, performance and ease of use.

This way of utilizing a weird thing seemingly unrelated due to economics of scale is not new. E.g. Tesla was built on the idea that instead of building a car using custom car batteries, they opted for the seemingly insane idea of using 7000 laptop batteries to power their car.

It seemed like a nonsensical solution, but it worked because the laptop marked was so huge and this had caused laptop batteries to be really good and cheap.

This will happen with traditional GUI toolkits: They will fall behind what is happing in the hyper competitive game engine world.

The key downside of using a Game Engine is that is renders constantly which causes a higher constant GPU and CPU usage. Although as many who read this article have pointed out to me repeatedly, Godot does in fact have a low CPU usage mode. Apparently this only renders when objects need to be re-rendered. Perhaps we can have a cake and eat it too?

I wrote this story thinking Godot was the answer to the challenges people who make large complex GUIs have. But perhaps this is actually a solution to everbody. Godot Engine adds an overhead of 20–30 MB has to a solution as far as I know. For quite moderately size applications that may be acceptable. It may seem much relative to my day-to-day editor TextMate which comes in at 30 MB. However compared to the Atom editor which comes in at a hefty 500-600 MB it is a steal.

So why should be jump to web technologies to get cross platform GUI applications? We got a tool, Godot, that runs on all major platforms which uses minimal resources and which anyone can get started using quickly.

To be humble, reality is that web technologies are far better known, and that will keep them dominating. However I think for large complex GUI applications we have been starved for choice and web technologies simply don’t cut it. If Godot is to break into the application development market they may have to do like Tesla, begin with the high performance sports car and work your way downwards to the everyday car.

Real World Examples

Seeing is believing. Not sure if you can make real applications with Godot? Check out some of these guys. We got Alfred Reinold Baudisch who was kind to share his experience with using Godot to make a Trello clone.

And we have Andrew Wooldridge who made this extensive guide to making an RSS Reader in Godot.

There are also some rather spectacular examples, such as Wonderdraft which is used to make fantasy world maps.

And I am sure there are many more examples, but I am a beginner to Godot and don’t have any full overview.