The main target of the Godot Engine are game developers. But Godot’s easy workflow and functional UI elements, makes it also a good fit for non-game applications. There are already some out there you may know, like Pixelorama, an Open Source 2D sprite editor.

12 points

There’s tends to be one major difference between games and non-game applications, so toolkits designed for one are often quite unsuitable for the other.

A game generally performs logic to paint the whole window, every frame, with at most some framerate-limiting in “paused” states. This burns power but is steady and often tries hard to reduce latency.

An application generally tries to paint as little of the window as possible, as rarely as possible. Reducing video bandwidth means using a lot less power, but can involve variable loads so sometimes latency gets pushed down to “it would be nice”.

Notably, the implications of the 4-way choice between {tearing, vsync, double-buffer, triple-buffer} looks very different between those two - and so does the question of “how do we use the GPU”?

permalink
report
reply
1 point

Does this mean you’re against using Godot for apps?

Personally, I feel like the extra load to reduce latency is worth it, but I honestly don’t know how different the load is or how much it could be optimized. But really snappy reactive software, even when long-running processes are going, feel much better to use. I’m getting tired of using web apps for everything.

As far as what does the GPU do, right now if we’re talking like b2b stuff you could do a lot more local number crunching or do really rich graphs with compute shaders etc. In the future, maybe the CPU handles most of the app and the GPU handles an AI workload in the background?

permalink
report
parent
reply
4 points

I guess I forgot to mention the other implicit difference in concerns:

When you are a game, you can reasonably assume: I have the user’s full focus and can take all the computing resources of their device, barring a few background apps.

When you are an application, the user will almost always have several other applications running to a meaningful degree, and those eat into available resources (often in a difficult-to-measure way). Unfortunately this rarely gets tested.

I’m not saying you can’t write an app using a game toolkit or vice versa, but you have to be aware of the differences and figure out how to configure it correctly for your use case.

(though actually - some purely-turn-based games that do nothing until user enters input do just fine on app toolkits. But the existence of such games means that game toolkits almost always support some way of supporting the app paradigm. By contrast, app toolkits often lack ready support for continuous game paradigms … unless you use APIs designed for video playback, often involving creating a separate child “window”. Actual video playback is really hard; even the makers of dedicated video-playing programs mess it up.)

permalink
report
parent
reply
1 point

Most UI frameworks are already graphically accelerated. But as stated above do the absolute minimum when updating the screen.

You don’t need to redraw a static label 60 times a second.

They have totally different use cases and are written very differently.

Games use as many resources as they can to get maximum performance for rendering. This is not desirable in an application.

permalink
report
parent
reply
2 points
Deleted by creator
permalink
report
parent
reply
1 point

I mentioned above but Godot has a low processor mode that gives you some control over the refresh cycle when nothing is happening. I doubt this completely alleviates the problem but I think it’s worth profiling it for individual use cases.

permalink
report
parent
reply
1 point

I know many Mac users who use Safari just because it’s doesn’t drain the battery as much as Chrome. That’s a big difference for desktop applications, and constantly redrawing the window at 60fps definitely will kill your battery.

permalink
report
parent
reply
2 points

For sure! However Godot has low processor mode that lets you control the frequency of the update when no changes are being made. That update time can even be changed from code so you can adjust it situationally.

permalink
report
parent
reply
4 points

My 0.02 - I’ve been developing a code diagramming tool in Godot. It’s been really nice to work with. I think its much easier to build a decent App UI in Godot than in, say, Android or (fucking) Swing.

It’s not as expressive as the combo of html/css/js, but it’s also much faster to get something useful put together with standard widgets.

I’ve been able to put together a combination of a text editor, buttons, menus and then my own custom graph-drawing widget.

Highly recommend!

permalink
report
reply
2 points

How does it compare to Flutter?

permalink
report
parent
reply
4 points
*

Without much experience building UIs aside from web, my limited experience with Godot leads me to believe that building an application this way would lead to a lot of decentralization of logic, which might be a bad thing for complex applications. For example, various UI elements might have a bunch of logic attached to them instead of having a centralized place where the logic lives. I guess this happens in web too, and maybe native UI frameworks/toolkits?

permalink
report
reply
4 points

Would you not be able to decentralize/centralized as you please? Usually this already happens for high performance godot apps, with c++ (and there’s autoloads if you want mor)

permalink
report
parent
reply
2 points

I guess it’s more likely to have “decentralized” code using Godot to build an app because of how it’s used in game dev. But that’s seen a lot in web dev too. You might have a react component handle state and children components with their own logic. Sometimes those components are “pure” and only deal with data given to it, sometimes they’re “stateful” and you end up needing to pass data up to the parent.

With proper planning, one could probably avoid mixing up what parts of the app should be pure/stateful.

permalink
report
parent
reply
1 point
*

Is there a good way to make a redux-like central state container in Godot?

(I’m sure there are many ways to do it but wondering if there is someone who has found a good practice for it.)

permalink
report
parent
reply
2 points

You could pretty easily do this as an autoload so it’s accessible from anywhere. You could store the actual state as a dictionary or a resource, or even a whole db if you wanted depending on what you’re storing.

It’s a little old but looks like someone even implemented a redux inspired store! https://github.com/glumpyfish/godot_redux

No idea if that still works, but probably would be too hard to use it as inspiration or even update it to the latest 3.x version

permalink
report
parent
reply
2 points

Like others have said, it’s pretty much the same as web development. The logic can live anywhere, so you could build your own app with whatever architecture you want and even use best practices from other fields as inspiration (Like the Redux comment.)

What we’re missing is mostly more people actually doing it, having opinions on how best to organize app-like builds. I’ve built some small apps using it but nothing complicated enough to answer these questions.

But there are some examples that are open source to look at.

https://github.com/LyffLyff/Veles

https://github.com/Mad-Cookies-Studio/mad-productivity

https://github.com/RodZill4/material-maker

permalink
report
parent
reply
2 points

I think that’ll depend on the application. For a painting program like Pixelorama, the logic being attached to the UI element, like the brush button dealing with the brush specific logic, it makes sense, it should be intuitive to look for how it works on a “brush.gd” file.

With Godot, the logic tends to reside within scenes and, without taking a look at Pixelorama, I would wager that most of the logic is already centralized, as I suspect the scene containing all the canvas-interacting buttons (fill, color pick, brush, select, etc) are all coupled in the same scene. Most of the time, you’ll have 1 script per scene, so all the logic of that scene is “centralized”

From my very hazy recollection, that decentralization was a problem with Delphi/Lazarus (Pascal), each UI component had a separate file to handle its logic. Might be remembering it wrong.

permalink
report
parent
reply

Godot

!godot@programming.dev

Create post

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

  • Posts need to be in english
  • Posts with explicit content must be tagged with nsfw
  • We do not condone harassment inside the community as well as trolling or equivalent behaviour
  • Do not post illegal materials or post things encouraging actions such as pirating games

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

  • The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
  • The banner is from Godot Design

Community stats

  • 708

    Monthly active users

  • 704

    Posts

  • 2.8K

    Comments