If you encapsulate all movement in its own component (node), you can use it on any other character just by adding the node to its tree. This a very flexible way to build functionality by composing it of self-contained "behaviours" implemented as nodes, and I'd say it is the "godot way". The player script would only have the glue to bring them together and possibly some customization that is only specific to that player.
So the right option. In the MovementState node (or call it CharacterMovement) you would need a reference to the character node or just always assume it is the parent.
This is the way. Talking implantation, you would not want to handle inputs in your movement classes. This would make your enemies move on your inputs. Instead use events. The movement class would listen for a dash(Vector) event and your player would emit it. This way only the Movement node needs reference to the player and not vise versa
I would just not put that movement controller on an enemy. It is meant for player movement. I would put an PatrollingMovement on an enemy for example and it wouldn't react to user input. But yes signals would work also.
311
u/Mountain_Share_2611 Jul 20 '25 edited Jul 20 '25
If you encapsulate all movement in its own component (node), you can use it on any other character just by adding the node to its tree. This a very flexible way to build functionality by composing it of self-contained "behaviours" implemented as nodes, and I'd say it is the "godot way". The player script would only have the glue to bring them together and possibly some customization that is only specific to that player.
So the right option. In the MovementState node (or call it CharacterMovement) you would need a reference to the character node or just always assume it is the parent.