this post was submitted on 18 Sep 2023
87 points (97.8% liked)
Godot
5692 readers
28 users here now
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
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
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
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
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?
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)
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
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
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.