Is Making Advanced GUI Applications with Godot the Future?

Erik Engheim
May 26 · 20 min read

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.
Image for post
The Godot editor is a sophisticated GUI application made in Godot itself.

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

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! (downloading the SDK. Just supporting the running of Qt applications requires much less 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

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

Image for post
Add, duplicate and rename GUI components with keyboard.

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.

Image for post
Correct GUI component is quickly located with filtering.

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

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.

Image for post
Blocking child nodes from getting selected by accident.

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

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.

Image for post

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

Image for post

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

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?

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

Image for post
Image for post
Screenshot of Qt Creator in action designing a GUI using desktop widgets.

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?

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.

Image for post
Image for post

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

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.

Image for post
Image for post
SwiftUI in XCode. Life preview of UI while you edit code.

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

Image for post
Image for post
This is where my GUI programming started, on an Amiga 1000 running Workbench

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.

But What About Flutter?

My recollection from trying to learn it was that it was somewhat overwhelming. There is just a ton of documentation and a lot of noise. I suspect that part of it is that the whole crowd of young web developers simply work and think different from an old school developer like me. It is all very hipster and focused a lot of neat little animations, cool transitions, stying and all sorts of stuff that I frankly could not care less about.

Image for post
Image for post
The typical Flutter App is small and deals with simple interfaces

It caters to a completely different crowd from the one I am use to working with. In highly technical fields, these kinds of things that Flutter push front and center are not things anybody cares about.

The people I work with has tended to come from other technical fields or they have been C++ game engine developers. So not that far away from Godot style developers. Highly technical development does not seem to appeal to most web developers who care a lot about style, colors, animations, branding etc.

Flutter simply does not look like it has the kind of GUI widgets out of the box that developers like me need. While something like Godot already does. After all, all the widgets needed for the Godot editor itself is available. There is a dog food element there, lacking for Flutter. Where is the highly complex IDE or 3D modeling application made with Flutter? Maybe it exists but I doubt it.

Flutter and Godot GUI Designer

Godot may not allow switching back and forth quite as effortlessly, however Godot uses very version control friendly text format for storing data. Much simpler formats than XML or JSON e.g. They work well with line oriented tools such as version control.

[node name="Button2" type="Button" parent="Panel/HBoxContainer"]
margin_right = 43.0
margin_bottom = 183.0
text = "clear"
[node name="Button3" type="Button" parent="Panel/HBoxContainer"]
margin_left = 47.0
margin_right = 90.0
margin_bottom = 183.0
text = "clear"
[node name="Button4" type="Button" parent="Panel/HBoxContainer"]
margin_left = 94.0
margin_right = 137.0
margin_bottom = 183.0
text = "clear"Why Are Game Engines the Future?

This is an example of the storage format for scenes that Godot uses. Notice how it is quite good at avoiding nesting and thus is friendly towards text based merging.

And for people worried about the difficulty of multiple people working on the same GUI, Godot has a beautiful system for splitting complex UIs into multiple separate files. A Godot GUI is just a hierarchy of scenes, and every scene can be a separate file.

Why Are Game Engines the Future?

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.

What About Accessibility?

To answer this, I feel I have to stress strongly that I am not talking about any kind of GUI application. Rather I am talking about highly complex GUI applications used by professionals in highly technical industries. That has been my professional life for many years.

Petrel, released by Schlumberger as shown below is an example of such an application.

Image for post
Image for post
Petrel 2020, used by engineers, geologists and other experts in the oil and gas industry.

In this industry, no application is accessible to disabled people. These applications are just too complex. They are usually not even internationalized. They involved hundreds of dialogs with dozens of tabs and tons of settings in each. They use dozens of different visualizations of different data and with rich tools for manipulating and modifying data visually.

I have worked in Norway for Norwegians companies making this kind of software and we don’t even make the software accessible in Norwegian. It is only in English. The only international efforts has been around doing stuff like showing names of Russian oil wells in Cyrillic letters properly. But there is no actual translation of the user interface to Russian.

With this kind of software the demands from the users are already difficult enough to meet. Making such an application accessible to disabled people would be very far down the list of priorities for any CEO. These are not the kind of applications which a broad set of the population uses. A single license can cost hundreds of thousands of dollars.

What we are talking about here are people making highly specialized visually oriented applications for the medical field, engineering, oil and gas and science.

These are very large applications which are painful to work with, with existing tools. Something like Godot gives very strong tools for debugging highly visual and interactive tools, which rely on high performance 3D rendering for a lot of what they do. In many ways these tools have a lot in common with large computer games in terms of complexity and graphics performance requirements.

Like games, their highly complex visual and interactive nature makes them poorly suited for accessibility.

Real World Examples

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.

The Startup

Medium's largest active publication, followed by +720K people. Follow to join our community.

Erik Engheim

Written by

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

The Startup

Medium's largest active publication, followed by +720K people. Follow to join our community.

Erik Engheim

Written by

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

The Startup

Medium's largest active publication, followed by +720K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store