Player Movement
Last updated
Last updated
The core of the system is the Player Movement component. This handles all of the user input, controls the movement logic and states and sends events to the other components (Player Animation primarily at this point) for them to act upon.
The Player Movement script contains a number of configuration properties exposed to the Inspector, as shown below:
How fast the player should move
How fast the player should run
How high the player should jump
The gravity in the world.
Any layers that we should use to detect if we're on the ground or not
How frequently we should be able to jump.
How long we should be falling before switching to the 'fall' state. Useful for handling stairs so you don't end up in random 'move / fall / move / fall' animation states.
Often we have to do things like 'multiply this value by Time.deltaTime and then by another random number' to get proper / reasonable values (for movement speeds, jump velocity etc). I have consolidated all of these into a single number. This may or may not be a good idea, but an attempt was made.
The core structure of the controller's logic flow works like this:
As you can see the PlayerAnimation class does very little, but wait for the onUpdatePlayerState event. This allows us to keep both systems in sync, and avoid running multiple update loops and trying to keep things organized.
Both PlayerMovement and PlayerAnimation rely on the PlayerState structure.
The various methods in the PlayerMovement Update loop will set and react to the various state properties and then PlayerAnimation reacts to the state and updates the character's animation accordingly.
This approach allows us to easily add additional support components that listen to this event and react accordingly. Some planned / future systems that can do this could include AI behaviour, head look IK, footstep IK, VFX etc.