I would love a write up on design philosiphy. I'm currently learning Godot coming from web dev, and finding the distributed business logic impossible to organize. I just don't know who, what, or where business logic should be. My urge is to lift logic up to the parent of any group of interactions, and let nodes just be renderers. But I understand that is absolutely not the design philosiphy of Godot, and probably won…
It's impossible to be sure without knowing your programming experience in general across sectors, but it sounds like you are unused to the paradigms of game programming in general, which is centered on logic executed per-frame rather than per-flow (like in business applications, which is where the concept of "business logic" comes from). The default approach in game engines is to bind data including state to an actor…
I almost think if someone were to build applications with Godot (or another engine) that you would need to mentally translate from something like React components and their data to the actor/sprite+state in an event loop model.
For example a todo list in Godot might have an actor that is the checkbox with some text next to it and the state of checked/unchecked, then allow the user to click something which generates more of these actors/sprites dynamically. I think where it really becomes cumbersome with a game engine is no real organization of a scene exists without you explicitly laying out x,y pixels. There are concepts of "relative" but common application concepts of pagination, etc. would be hard to pull off in a simple way in the code I would imagine.