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.
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?
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.
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.)
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
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.
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
