In object-oriented programming, State Pattern is one of the ways to implement Finite State Machines. This pattern falls under Behavioral Design Patterns.
When in our software, an object can change between multiple possible states and change its behavior according to the state, then, this type of problem can be easily solved using Finite State Machines, and this pattern helps us to achieve the same.
A glance at Mario’s State/Behaviors in Game
Here, I’m taking the example of the Super Mario game. Most people are already aware of this nostalgic game. In this game, Mario changes his states and behaviour based on the events which occurred, which you can see in the below image which I got from Mario Wiki.
Let’s observe states/behavior and events in above image.
States
- Mario (We will refer as Small Mario hereafter)
- Super Mario
- Fire Mario
- Cape Mario
- Lost Life (Apart from the image considering this state)
Events
- Got Mushroom
- Got Fire Flower
- Got Feather
- Met Monster (Not shown in image)
State Transition on Event Occurrence & Earning Coins
The following table demonstrates how the state changes with different events. Apart from the state change, coins are also earned on the occurrence of events.
Current State | Event Occurred | New State | Coins Earned |
Small Mario | Got Mushroom | Super Mario | 100 |
Small Mario | Got Fire Flower | Fire Mario | 200 |
Small Mario | Got Feather | Cape Mario | 300 |
Small Mario | Met Monster | Lost Life | 0 |
Super Mario | Got Mushroom | Super Mario | 100 |
Super Mario | Got Fire Flower | Fire Mario | 200 |
Super Mario | Got Feather | Cape Mario | 300 |
Super Mario | Met Monster | Small Mario | 0 |
Fire Mario | Got Mushroom | Fire Mario | 100 |
Fire Mario | Got Fire Flower | Fire Mario | 200 |
Fire Mario | Got Feather | Cape Mario | 300 |
Fire Mario | Met Monster | Small Mario | 0 |
Cape Mario | Got Mushroom | Cape Mario | 100 |
Cape Mario | Got Fire Flower | Fire Mario | 200 |
Cape Mario | Got Feather | Cape Mario | 300 |
Cape Mario | Met Monster | Small Mario | 0 |
Earning Life
On every 5000 coins collected, one life will be awarded.
Implementing in Code
Just to make it clear, Nintendo hasn’t open sourced the Super Mario source code yet. I am just taking the example to help you understand State Design Pattern, like in other articles in the series we will start programming with some code and will be refactoring it gradually.
Approach 1 - Creating Method for Every Events Occured
We created enum (internalState) with the name of all the states, for each event we have methods, where after validating conditions we are setting State property value which is of internalState type and represents the current state of object/Mario. Refer to the below code,
Source Code
State Pattern / Mario / Approach1
As you see in the output it is changing state on the occurrence of different events.
Reviewing Approach 1
On the occurrence of each event, a different operation can be executed based on current state of the object. For example, GotMushroom event -- if it occurs for SmallMario, the character would be changed to SuperMario, but if the same event occurs for SuperMario, it will remain the same. It may lead to confusion to write the same conditions in each method.
Approach 2 - Moving All State Related Code To Respective Class
To address the problem of approach 1, here I created a separate class for each State, which all are inherited from IState interface. This interface contains respective methods for all our four events; i.e GotMushroom(), GotFireFlower(), GotFeather() & MetMonster(). All State classes are inheriting this. Now, before writing state specific code, we don’t need to check condition, because it’s being written for specific states. All 4 state classes are mimicking our State transition table shown above. Refer to the code.
Reviewing Approach 2
Everything related to states is within state classes now, but responsibility to create its object is still outside.
Approach 3 - Making State Classes SingletonSince our state classes having no variable/properties, all those are maintained in Mario class, so we can make state classes singleton. In event methods of all singleton classes, we will be passing current Mario object so states can be switched. Here, IState interface is changed accordingly to pass the Mario class object as parameter and inside Mario class there is no need to initialize all the objects.
Conclusion
All state related logic is maintained within state classes now, and in the final approach, a singleton is used, which can be implemented in various better ways. Here, we have removed conditional duplicacy & new states can be easily added. Existing state logic can be easily extended without changing any other class. In game programming, this pattern is frequently used.
Thanks for reading, let the suggestions/discussions/queries go in the comments.