Player Movement

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 Inspector

The Player Movement script contains a number of configuration properties exposed to the Inspector, as shown below:

Walk Speed

How fast the player should move

Run Speed

How fast the player should run

Jump Height

How high the player should jump

Gravity

The gravity in the world.

Ground Layers

Any layers that we should use to detect if we're on the ground or not

Jump Timeout

How frequently we should be able to jump.

Fall Timeout

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.

Magic Number

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.

Code Architecture

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.