Encapsulation and Node Communication

Question

Hiya. I've been following Godot's development for a while now, and thought it was about time to pick it up and have a play with it. On paper I like the design philosophy of OO node trees, but in practice I'm struggling to work out how to actually structure anything larger than the demo projects. I've read through the documentation and searched around, but it's not clicking. I have been working primarily with UE4 and C++ for a number of years now, so I think my brain is having difficulties adapting.

So take, for example, character movement. In UE4, a simple character actor would have a root component, normally the physics body, which would handle purely physics behaviour, and then another component which handles purely movement behaviour. The movement component then queries its owner for its root component, and supplies it with force/velocity/position updates accordingly. Movement is encapsulated nicely, and doesn't need to know what the actual physics body is doing (for the most part). Then you can reuse that movement component on any number of actors, which could have entirely different components and component layouts.

In Godot, it seems as though the movement logic would have to belong to a script attached to the root node in order to move the current scene tree correctly, or else you would have to have the movement node reference the relative position of the tree's physics node by path, which feels horrible, and would also break completely if the node was added to a scene with a different structure. Likewise, moving all of the logic that requires access to other nodes to the top of the tree seems like a real easy way to end up with a blob class. Looking at the demos (which I appreciate are written to showcase certain features as simply as possible, so aren't exactly structural guidelines), this seems to be the case - mega controller scripts that handle input, movement, animation, everything.

So really what my question boils down to is: how do you effectively encapsulate logic and communication between nodes within the same scene for anything larger than a demo project? Firing signals off for mundane tasks like informing our owning node that we need to move doesn't seem like the answer, but neither does referencing nodes by relative path or moving all logic to the root node. Is there some key design philosophy here that I'm missing? Am I too far gone in UE4 land to save?

Thanks for reading my ramblings all! I hope someone can unfuddle my brain, 'cause I really want to like Godot!

tl;dr How should you approach logic encapsulation in Godot while avoiding a blob root script and referencing nodes by path?

Answer 1

As you said, Godot's scene hierarchy consists of nodes. But the root of the scene is not the only node that can have a script. Any node can have any script. So all of your logic doesn't have to be in one node. Each node can do their own thing inspite of other nodes.

---

If you want them to be affected by others, then all you need is a reference to it. Which you can get in a number of ways. For programming in GDscript, you can find how to do so somewhere in here. And once you have a reference to it, you can do pretty much anything with it. Get a variable, set a variable, even call functions on its behalf.

---

There is also this feature called signals. With signals, one node will be notified by another node when something happens. So like if a button node "emits" a signal like button_pressed, then another node can call a function when that happens. But only if that function is connected to that particular signal. You can get more info here (Yes it's the same link).

---

Now the really powerful feature of using nodes is that they can be instanced. What? Well that means that a whole scene can be reused in a totally different scene. For example, in the platformer3D demo, the player is a scene by itself. But then that scene is instanced inside the main game. This also applies to the enemies, the coins, even the tiles the level is made of.

If you still don't get here is one more link to wrap things up.