A Finite State Machine is a computational model used to design systems with limited specific states. It consists of states, transitions between them, and actions triggered by those transitions. In game development, a finite state machine is used to manage the behavior of game entities, such as characters or AI, by defining distinct states and controlling transitions between them based on player input or in-game events.
I developed two key classes: PlayerState and PlayerStateMachine.
PlayerState: This is the base class from which all specific player states (like idle, walking, attacking) are derived. It encapsulates the common properties and methods that all player states share, such as EnterState(), ExitState(), FrameUpdate(), and PhysicsUpdate(). By deriving specific state classes from PlayerState, I was able to manage each state’s behavior independently while maintaining a consistent interface.
PlayerStateMachine: This class is responsible for managing the transitions between different states. It holds a reference to the current state and provides methods to initialize and change states. The ChangeState() method ensures that the current state is properly exited before entering a new one, maintaining the integrity of the state transitions.
One of the states I implemented was the PlayerRiseState, which handles the player's behavior while they are rising in a jump.
The PlayerRiseState class is a derived class from PlayerState, which is the base class for all player states. By inheriting from PlayerState, PlayerRiseState can override essential methods like EnterState(), FrameUpdate(), PhysicsUpdate(), and ExitState() to define specific behaviors for the rise state.
In this state, the EnterState() derived function gets overridden by the RiseState() Class. This function gets activated when the state has been called by the StateMachine() Class. For this example, the EnterState() triggers an animation. On the FrameUpdate() the function calls for a condition check which will only transition to PeakStage limiting escapes from this state to only one.
I wanted to make a diagram to show what is happening visually.
So we have a jump consisting of 3 different states.
The Rise which is when the Y coordinate is increasing towards the positive direction.
Peak is when the jump is at its Apex where it is barely making any increasing movements but right at the part where it is perfectly still in the air.
Fall which happens when the Y coordinate is increasing towards the negative direction.
By Limiting the state transitions we made sure that the states won't transition to each other in an unwanted way. Rise will only transition to peak if the Vertical speed is slowing down close to 0. Peak will transition into only land or fall. If the player makes contact with the ground during the peak state then landing animation is played. If the player has made contact with the ground and Y velocity gets faster towards the negative direction then the peak transitions into fall. From there if the character makes contact with the ground fall is played.
This way we have cleared a lot of complications that we may have needed to create solutions for later. Idle will never translate into land in this game's settings. The player must be on the air at first to make contact with the ground again to play the Land and thus logic is created instead of needing to rely on physics rules to transition between states.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.