Understanding State Design Pattern By Implementing Finite State Machine In Super Mario Game

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.

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

1. Mario (We will refer as Small Mario hereafter)
2. Super Mario
3. Fire Mario
4. Cape Mario
5. Lost Life (Apart from the image considering this state)

Events

1. Got Mushroom
2. Got Fire Flower
3. Got Feather
4. 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.

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

1. public class Mario {
2. enum internalState {
3. SmallMario,
4. SuperMario,
5. FireMario,
6. CapeMario
7. }
9. public int LifeCount { get; private set; }
10. public int CoinCount { get; private set; }
11. private internalState State { get; set; }
13. public Mario() {
14. LifeCount = 1;
15. CoinCount = 0;
16. State = internalState.SmallMario;
17. }
19. public void GotMushroom() {
20. WriteLine("Got Mushroom!");
21. if (State == internalState.SmallMario)
22. State = internalState.SuperMario;
24. GotCoins(100);
25. }
27. public void GotFireFlower() {
28. WriteLine("Got FireFlower!");
29. State = internalState.FireMario;
30. GotCoins(200);
31. }
33. public void GotFeather() {
34. WriteLine("Got Feather!");
35. State = internalState.CapeMario;
36. GotCoins(300);
37. }
39. public void GotCoins(int numberOfCoins) {
40. WriteLine($"Got {numberOfCoins} Coin(s)!");
41. CoinCount += numberOfCoins;
42. if (CoinCount >= 5000)
43. {
44. GotLife();
45. CoinCount -= 5000;
46. }
47. }
49. private void GotLife() {
50. WriteLine("Got Life!");
51. LifeCount += 1;
52. }
54. private void LostLife() {
55. WriteLine("Lost Life!");
56. LifeCount -= 1;
57. if (LifeCount <= 0)
58. GameOver();
59. }
61. public void MetMonster() {
62. WriteLine("Met Monster!");
63. if (State == internalState.SmallMario)
64. LostLife();
65. else
66. State = internalState.SmallMario;
67. }
69. public void GameOver() {
70. LifeCount = 0;
71. CoinCount = 0;
72. WriteLine("Game Over!");
73. }
75. public override string ToString() {
76. return $"State: {State} | LifeCount: {LifeCount} | CoinsCount: {CoinCount} \n";
77. }
78. }
80. class MainClass {
81. static void Main(string[] args) {
82. Mario mario = new Mario();
83. WriteLine(mario);
85. mario.GotMushroom();
86. WriteLine(mario);
88. mario.GotFireFlower();
89. WriteLine(mario);
91. mario.GotFeather();
92. WriteLine(mario);
94. mario.GotCoins(4800);
95. WriteLine(mario);
97. mario.MetMonster();
98. WriteLine(mario);
100. mario.MetMonster();
101. WriteLine(mario);
103. mario.MetMonster();
104. WriteLine(mario);
105. }
106. }

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.