Introduction
Mar 18, 2018 The first video of my next big Code-It-Yourself! A top down role playing game in the style of Zelda and Final Fantasy. This video is long, but lays out the project plan and gets some of.
The State Pattern is an interesting design pattern in that it allows us to separate out portions of code into individual related modules, or states. This pattern is particularly useful for applications which need to retain state information, such as the current phase a program is in. While you can typically maintain this information using a basic integer variable, the State pattern helps abstract the specific state logic, reduces code complexity, and greatly increases code readability. This can make the difference between an application maintenance nightmare and a work of art.
This article describes how to use the State Pattern with C# to create a simple, console-based RPG role playing game. You’ll be able to see exactly how the State pattern fits into the flow of the rpg game and how it easily cleans up the code, in what might typically be a confusion of integer values and if-then statements.
If Then Else What?
The core problem that the State pattern solves is reducing the complexity of if-then statements, which we ultimately need when managing state information. Since we’re going to be creating a role playing game, knowing if the character is in an exploratory or battle state is important.
For our simple role playing game, we’ll consider 2 states that our character may be in and 2 commands that he can perform. He can be Exploring or he can be in Battle and he can choose to Look Around or to Attack. Since we have 2 states and 2 command possibilities, we’ll naturally have 4 situations to check for. They are:
Without design patterns, you might normally design a role playing game similar to the following:
You would then define the function for each situation listed above. While this would certainly work and might not look like much code, think about what would happen if you added another command, such as “Inventory”. You would have to add an additional two if-then statements. If you wanted to add another state, such as “InStore”, you would need to create even more if-then statements. You can see how the above code could end up becoming complex and more difficult to maintain. This is where the State Pattern comes in!
Cleaning House with the State Pattern
Let’s clean up the above code by implementing the State Pattern. Since we have two possible states, we’ll have two state classes which manage the details of each state, but the main loop will be reduced to the following:
In the above C# code, using the State Pattern, we’ve already cut in half the number of if-then statements. In fact, we only need to check which command the user selected and pass call the proper function for that command. The State Pattern itself takes care of determining which specific state should act upon the command. As you can see, this greatly reduces the amount of code complexity. Let’s take a look at how we put the State Pattern together.
There’s Always an Interface
We start by constructing an interface for the State Pattern controller to use. All states will implement this interface so that they have the same list of functions which the controller class can call. Depending on which state is currently active, the controller will execute one of the interface functions. The functions in the interface can be considered the possible commands the user can choose. The concrete states we construct from this interface can be considered the possible states the character may be in.
As you can tell, we’ll need to define the function bodies for each possible function in the state interface. In the case of impossible states, such as being in the Battle state and trying to Explore, we can either throw an exception and leave the function empty, or display an entertaining message to the user. In either case, the state pattern still helps us manage the complexity.
Since we only have two commands, our interface for the State Pattern is defined as follows:
Exploring the State of the Explore State
We have two states to create implementations for: Explore and Battle. We’ll start with the Explore state. This will also be the initial state that the character will reside in. Since the character can select two commands (Look and Attack), and since we defined two functions in the interface (Explore and Battle), we can fill in the body for the user commands as follows:
First, notice that the state implements IState. This means it has an Explore and Battle function, which are the two commands the user can do. When in the Explore state, upon exploring we’ll let the user either find a magical item which increases his experience, or he’ll find a monster that he must kill. For the code, we simply pick a random number, and depending on the value, let the user know he found a monster or magical item. If he found a monster, the user’s state will be changed to the Battle state. This allows us to call the same interface functions (Explore and Battle) but from a new state, the Battle state. On the other hand, if he found a magical item, his state remains in the Explore state. Notice that we also define the Battle function even though this is within the Explore state. Since the user can’t attack a tree, we’ll simply tell him there is nothing to attack. You could also throw an exception in the Battle() function if you wish, as long as the user interface prevents the user from choosing the Attack command while in the Explore state. In our case, the commands never change for the user, so we’ll define the bodies for all functions. At this point, you could easily draw a simple state diagram, that illustrates our game, but we’ll move on with the code.
Battling the Battle State
Just as we did with the Explore state, the Battle state will define the same two interface functions Explore and Battle. The difference is that since we’re now in a battle state, executing the Explore command should throw an exception (or display a message), and the Battle command will actually perform an attack. Nonton hiiro no kakera dai ni shoulders. We define this state as follows:
The beauty of the State Pattern is in how easy it is to add new states and commands to our application. Since the class implements the same interface (ie. the same commands), we can easily define this new Battle state. The only interesting part to this class is the contents of the Battle function, which simply picks a random number to tell if the user killed the monster. For each round the user fails to kill the monster (in one blow), the user loses potential experience. The faster a monster is killed, the more experience he gains.
It’s also important to note that in the Battle function we include a transition back to the Explore state (just as we did in the Explore state’s Explore() function if the user found a monster). Notice that we include a reference to the State controller’s context. This is just a pointer to the state controller, as the controller will ultimately handle which state we’re in and calling the desired functions. Let’s move on to describing how the controller works.
The Master Pattern Controller
As you noticed in the state definitions above, we have a reference to a “context” variable, which points to the state controller. The controller manages the current state and maipulates the state. Our main program will actually call the controller, not the individual states.
The controller can be defined as follows:
The first point to note is that we define an instance of each state within the controller. We define exploreState and battleState. We instantiate these variables to their designated concrete state (Explore and Battle). We also define a state pointer, which holds our current state. This is similar to defining the integer variable in the original example above.
Next, we define functions for each command that the user can select (or just copy the functions we used in the interface which coorespond to the same thing): Explore and Battle. For the body to these functions, we simply execute the current state’s method for that command. So for Explore(), we simply call state.Explore() and for Battle, we simply call state.Battle(). Remember, state is our current state and will point to either exploreState or battleState. Regardless of which concrete state it points to, the functions it can call are the same.
Myob Accounting Plus V18 Ed 18.0.0 serial keygen: Myob Accountright 2014.4, v.14.4.16.7861 key code generator. How to crack MYOB - Myob Accounting Plus (BPJUBC00) for question. Download myob v18 ed. PLEASE HELP As a result of a hard disk failure my MYOB V18 is corrup with a #48 error. Search Fixya.
We also define a few helper functions, such as the SetState() function, which lets us change our active state, and the GetExploreState() and GetBattleState() functions, which return a concrete instance of the particular state. These are used during the state transitions when we reference the “context” variable to change states.
Putting it All Together, I Think We’ve Got a Game
You might be surprised at this point to realize we pretty much have a fully functional state-aware game. The state pattern hides and abstracts much of the complexity that we normally have to manage in the main code. Since the states are tucked away in individual modules managed by the controller, we only have to use the controller to handle our game states. We can define the main program loop as follows:
The first thing we do is include a variable for the RPG controller. This is our key to using the state pattern controller. Next, we display a basic menu to the user and allow him to select a command on the keyboard. Our state pattern comes into play when we process the command in the DoAction() function. Depending on the command selected, we call the controller’s designated function for that command (Explore or Battle). The controller (and its concrete states) handle the actual details about what to do based upon the user’s input. So, when the user chooses to Look, we just tell the controller to execute a Look and it tells the current state to execute a “Look”.
There is one additional utility class left out from the above code, which manages selecting random numbers. This class is defined as follows:
Output
If you’d like to try the game yourself, you can download a copy of the compiled game to try it out. Of course, you’ll need to have the .NET framework on your PC. Once you put together the above code and run the program, the output of our rpg game using the State Pattern, will look like the following:
In the above output, you can guess which state the user was in when he performed each command and which action was called. For example, after slaying the monster, the user was returned to the Explore state, but selected the Attack command anyway. The response was “You find nothing to attack”, indicating the state transitioned from Battle to Explore successfully.
Conclusion
Managing state in an application typically requires utilizing an integer index variable with a series of if-then or case statements, which can often add to code complexity and maintenance issues. The State Pattern in C# helps us organize our states into individual modules with a single controller and helps us abstract away the details behind the state implementation. This allows us to reduce code complexity, increase readability, and ultimately reduce maintenance in the future. The State Pattern is an easy addition to your design patterns toolkit and can be used in any stateful object oriented application.
About the Author
This article was written by Kory Becker, software developer and architect, skilled in a range of technologies, including web application development, machine learning, artificial intelligence, and data science.