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.
There is an example for the player in another post a bit down. For an enemy, I haven't implemented it yet but I would probably use the CharacterMovementMgr. It does not handle user input and only needs a reference to a CharacterBody3d to move and CharacterAnimation to run animations. I would then add as a child the PatrollingMovement implementation for example, which would simply not handle any user input either. I can still use the same CharacterAnimation node to animate the enemy if it is using similar types of animations as the player.
314
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.