Hi guys, I have no idea how I would search this question which is pretty simple, so I have a Player with multiple nodes inside, and I was worried that this wont be a good practice. My player has multiple nodes inside that hold their own logic with the player having the main script that handles all the nodes in it, for example, Player (main script) > Player Movement Node under it which has the movement code in a function, is it okay if I put this function process_movement in the main code inside _physics_process like this?
var player_movement : Node = $Player_Movement
func _physics_process(delta):
player_movement .process_movement(delta)
This way I can have all the handling in the main script with states and stuff like that and have a small state machine kind off because my logic for this game is simple. So basically my question is, is this bad practice? is there a better way?
Hey one question, would something like this be bad practice on the movement node since its a child node of the player? since its separate, i have to get.parent() would that be okay or is it better i just do all movement on the player it-self
There are pros and cons to both ways.
The usually accepted standard is “calls down, signals up”, which is kept with your first approach, but broken with your second one, so probably there will be people agueing against the second one.
However, I think you shouldn’t just blindly apply every standard to every project. All should be placed in the context, and in the context of this problem - I again don’t see anything wrong with either one of these approaches.
I personally even prefer the second one and I built a couple of components like this myself. This way you can build your PlayerMovement component to be easily reusable as you can put it under any CharacterBody node (or whatever it is designed for) and it will work right away, without having to wire any references on the main node.
Especially when your game is not too complex like you mentioned, you don’t need to worry too much about interdependencies. The problem might only arise when you have other components in the future that also modify player’s movement in addition to the general movement controller, or you need to access some values from this component in other nodes - then you might need to take that into consideration and maybe redesign your structure.
thanks for the detailed explanation as always what do you mean by calls down, signals up? and get_parent should be okay? sorry i deleted the previous reply cuz i sent it too early without writing extra stuff i wanted to ask lol
This means that information going from a parent to the child (“down” the tree) should be done using function calls (e.g. child.set_parameter(parameter) on the parent node), whereas information from a child to the parent (“up” the tree) should be done using signals (e.g. parameter_set.emit(parameter) on the child node and an appropriate signal catching function on the parent). This way, the child doesn’t need to know what its parent is and can work as a standalone node.
But you can just as well think the other way around, so that the child is in the driving seat and has all the control, with the parent being the oblivious one - which would be your second approach.
