Hacker News Reader

Comment by anigbrowl | Hacker News Reader

Re-upping this blog post (sadly overlooked when first posted to HN) which asks the reasonable question 'why not just use Godot for general-purpose applications?'

https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

View on HN

There's a lot of functionality that a general purpose UI library has that Godot will likely never approach, like support for input methods in text editing.

Productive applications require extremely robust text editing, something that game engines don't spend a lot of time with. Stuff like selection, text input for non-English keyboards, IME popups, that sort of thing. Even RTL text display is usually minimally unsupported.

I also don't know of any game engine that supports multi-window display in any coherent way.

Godot is open source. There's nothing stopping people from adding this functionality.

I'd argue multi-window would require a substantial redesign of the graphics layer, so much that the maintainers would be uninterested in supporting it, and consider it out of scope.

I can imagine IME support being integrated, but a giant pain, due to the wide variety of APIs across platforms, the fundamental disconnect in how text input is done in games vs. elsewhere, not to mention the "Linux wars": will you support ibus or fcitx?

So it requires someone to step up and do the work, and don't be fooled: it's a lot of work.

Godot 4.0 recently acquired multiple window support for the editor (which is built with Godot's UI and rendering system) and APIs for applying it to your own games

Just to clarify for those following along. Godot IDE is using the same UI components that you can use in your games. Godot 4 will support multiple windows. They're working on RTL I believe and it actually has a very robust code editor with debugger in the editor. Most of the points being raised here don't seem to be based on actual experience with the framework.

The Godot editor has a pretty good IDE. It's not VScode/Atom levels of functionality but it's improving steadily.

Looking at the github issues they seem to have made a lot of progress with non-English inputs. Again, not perfect but improving.

Godot 4 is adding multi window support. I would hesitate to judge it until it stabilizes but there's some hope there. It looks good from what we have seen so far.

The rate this engine is improving is incredible, i'm finding a lot of reasons to be optimistic.

The parent poster is referring to accessibility of the applications produced with Godot, not the accessibility of the IDE. Edit: it's not .NET it's C++.

I don't understand, the IDE for Godot is created with Godot.

Thanks, that's the point I was trying to make. It's more clear when you have read the article.

So you think that the Godot IDE which allows code editing will not support robust text editing? I don't know how robust it is currently but there is no reason why it wouldn't possibly support that in the future.

IME do have some uses for games, like for in-game text chat. I think it is reasonable to ask for at least some IME input capabilities in a game engine UI library. It is a must if one wants to make a multiplayer game targeting CJK markets.

If you use the Godot editor you'll see it's already sophisticated enough for general purpose UI applications. Of course you can keep expanding the requirements until no software in the world meets them but if you know what you're building then it might be the right choice. The main benefit that you won't get with almost anything else is true control over how every pixel gets actually rendered to the screen. It's able to make cross platform applications which since you're in full control over how they're actually rendered gives you tons of control. Resource utilization is fairly low and again you have full control of the stack so it's as good as you're willing to make it. C# is supported nowadays which gives you access to a mature ecosystem of libraries.

Is it the right solution for all UIs? Clearly not but IMO the UI landscape is a mess at the moment for anyone who wants to be able to build cross platform applications. There aren't really any adequate solutions as far as I can tell.

Regarding multi-window, I notice that most electron apps don't support multi-window.

It's not impossible, but apparently very hard.

Would it be possible to write an app in, let's say, Swift + SwiftUI for an Apple device, using the native primitives to render the UI, and use Godot just for rendering the 3d part?

Let's say that you're working on a 3d model viewer or some AR app.

We often hear saying game engines redraw every frame so it is not appropriate for UIs.

In Godot, you can set an option to redraw only when something change like in UI libs (for e.g Godot Editor use this option)

However , I think one main aspect missing from UI libs is damage tracking (=redraw only the part of the screen that changed and tell the compositor to also only redraw that part).

In terms of architecture, Godot is all I want. I wish I could build general purpose apps with it. Everything is a node & just simple trees. Abstraction of everything you need over all platforms. GDNative let you access everything from any language.

I really wish I could build everything with Godot. I enjoy it so much more than web dev or android dev even for UI

>I wish I could build general purpose apps with it.

Why can't you?

I mentioned this in the previous thread about this, people build general purpose apps in Unity all the time. And Godot's own UI is a Godot application. There may be some edge cases where it doesn't work, but considering the current standard for native applications is to wrap webapps in individual Chrome instances, I can't see Godot being subpar.

As I mentioned, the lack of damage tracking is an important problem. It leads to high CPU/Battery usage which isn't great for laptop & phones.

Electron/Web might eat lots of ram but I think the renderer is more optimised for UI and will use less CPU/Battery.

Also Godot has an internal architecture made for games which might be a bit overkill/less elegant for UI-only apps :

https://godotengine.org/article/why-does-godot-use-servers-a...

I'm not sure if the separation of logic and rendering in separate threads like that is the way you would build a high perf UI library

You can just make sure to set the low processor mode and you're good. The latest 3.2.2 introduced some fixes which help as well. It will only draw whenever a component actually requests an update.

You can. This is exactly what Flutter does, as I've commented on that thread you refer to on HN. It uses the Skia renderer that is like a 2d game engine to draw all the elements on the screen. They've had to reimplement everything though, like text fields and accessibility, so perhaps this is why it's not done more often.

To be fair this is what Electron does too via the browsers. It's just doing it via the worse possible way by leveraging technology that's awful for building UIs. I'm a fan of flutter they're definitely onto something. I hope they can bring it to the desktop in a way that works well too.

People already do to some extent.

That article mentions one example, the Trello clone (frontend?), but there are others like in this Reddit article: https://www.reddit.com/r/godot/comments/a809ij/godot_for_app...

* The Godot editor itself: https://docs.godotengine.org/en/stable/getting_started/step_...

* GUI Toolkit: https://github.com/Quark-Toolkit/Quark

* Pixel art editor: https://www.orama-interactive.com/pixelorama

* Particle effects editor: https://benhickling.itch.io/blastfx

* RPG builder: https://www.rpginabox.com/overview/

* Fantasy map editor: https://www.wonderdraft.net/

* Brainfuck IDE: https://github.com/wmww/BrainfuckIDE

* 3D presentation editor: https://github.com/janparkio/3d-presentation-godotengine

I've looked in to this myself and noted the following:

* It's easy to compile out features you don't want (3D, physics, etc.): https://docs.godotengine.org/en/stable/development/compiling...

* While Godot has a small file size, it's Hello World memory usage is ~300MB, which I think is even more than a Hello World in Electron (perhaps fixable by removing features)

* There is a setting to stop UI updates when the window loses focus which means it doesn't chomp CPU/GPU while not in use

I'll put https://news.ycombinator.com/item?id=23308303 in the pool for inviting a repost.

Yes please I have always wondered why is this not a thing

Because of Electron.

I can't read the linked article without logging in but in my experience its not ideal for several reasons.

Game engines are designed around game loops executing code every frame and not around power efficient layout caching.

Orthrographic hierarchies are how UIs are usually laid out and its a mild pain to move to a system that's depth sorted, with custom shaders etc. You can do more but you need to think about more and its harder for the UI system to know what parts of the screen can be redrawn. Games usually just draw it all every frame.

Specifically for a game engines, they usually don't do things like OS integration for accessibility, subpixel font rendering, that sort of thing. In theory they could but usually game engines seem to roll their own system for this.

I really love ImGui but what you described (accurately, I don't know why you got silently downvoted) is my biggest problem with it for general UI use.

It's actually quite difficult to hack to make it not need 60+ fps updating; I've tried and was not really successful, wrote about some of the issues on reddit: https://www.reddit.com/r/cpp/comments/hcpoc0/how_to_add_a_gu...

It's interesting. Can you easily deploy a Godot ui to the web?

It supports web as an export target, although there are some limitations:

"""

Unimplemented functionality

The following functionality is currently unavailable on the HTML5 platform:

- Threads

- GDNative

- C#

- Clipboard synchronization between engine and operating system

- Networking other than HTTPClient and WebSocketClient

"""

https://docs.godotengine.org/en/stable/getting_started/workf...

Much of these are not limitations of the export but of the platform. Web workers don't rise to the functionality of threads (wasm will surely grow decent thread support one day)

GDNative by definition is for native.

My game using C# exports to web fine, So that's working. Still a fairly huge download for a web game though, not really any worse than the Unity ones though.

Reply on news.ycombinator.com