Player

The Player class is a wrapper class intended to tie together all our other components. It initializes the non-monobehaviour scripts and grabs references to the monobehaviour components.

State Machine

The State Machine keeps track of the current state.

At the start of the game Player.cs will call StateMachine.Initialize(IdleState) which makes Idle State the CurrentState. Then the State Machine will call CurrentState.Enter().

The current state’s LogicUpdate() and PhysicsUpdate() are called continuously by Player.cs using StateMachine.CurrentState.LogicUpdate() & StateMachine.CurrentState.PhysicsUpdate().

To transition, Idle State (or it’s Super State) will call ChangeState(NextState) with the state to transition to. ChangeState() will then call the Exit() function of the current state, and the Enter() function of the next state.

Player Checks

Player Checks fires Raycasts/Boxcasts and draws Gizmos to visualize them. It exposes variables such as IsTouchingLedge and IsGrounded which states can use to determine when to transition between states.

Info

Gizmos only work in the Unity editor which is why the public demo did not include them.

Player References

Player References is a class that handles our references. At the start of the game it caches the references to various scripts and components then exposes the read permission publicly.

Info

Some classes (like PlayerBaseState) may instead cache their own references in order to have shorter code.

Player Data

A class where we store all our data related to the Player. Is made into a ScriptableObject to allow customization in realtime in the editor.

Input Manager

Input Manager is a wrapper class that collects information from the new Input System and exposes variables containing information on whether certain buttons are pressed.

Tip

If you wish to use your own Input System, change InputManager.cs to collect information from your Input System and store that information inside the variables exposed as public

Player Action Check

Player Action Check is used to check if a state can transition to another state. The main goal is to centralize transitions in one script for ease of access. It contains a plethora methods with the state parameter. Each method is dedicated to one action, and may have different conditions depending on which state is calling it (identified using the state parameter)

Player Base State

Player Base State is a class that is meant to be inherited by all other states. Any state that inherits PlayerBaseState.cs can act as a state in the StateMachine.cs. This is a type of Polymorphism. Player Base State also makes a few methods, variables, a constructor and some logic to play animations/change sprite direction: logic that is used by all states.

Super Classes

Super Classes inherit from PlayerBaseState but are not initialized as a state in Player.cs. Their purpose is to group logic between Sub States. An example of this is PlayerGroundedState, it contains logic to apply friction to any state that inherits from it. Additionally, it contains transitions that all states that inherit from it would use/require.

Sub Classes

Sub Classes are classes inheriting from PlayerBaseState (eg. PlayerFallState) or a Super Class (eg. PlayerIdleState) that are initialized as a state within Player.cs. These are states that can be swapped into the State Machine to become an active state.