| The Indie Stone Community http://theindiestone.com/community/ |
|
| Game Flow and State Machines in C# / XNA http://theindiestone.com/community/tutorials-f12/game-flow-and-state-machines-xna-t33.html |
Page 1 of 1 |
| Author: | lemmy101 [ Thu Apr 02, 2009 4:57 am ] |
| Post subject: | Game Flow and State Machines in C# / XNA |
A State Machine is a system for allowing a game to pass through a list of states which define different sections of the game. These are insanely useful for defining your gameflow. Basically they are comprised of two base classes: StateMachine and State. The StateMachine contains a list of States, which it will move through sequentially. Each State has four main methods: Enter During Exit Draw A StateMachine has multiple States, each which have three Stages: 'Enter', 'During', 'Exit'. Each of the three stage methods; 'Enter', 'During' and 'Exit', can return whether the state machine should 'Remain' in that stage, or 'Continue' onto the next. When the StateMachine first moves onto a state, it will run the Enter method. This is where the state is set up and everything is initialised. The Enter method then returns Continue and the StateMachine ends its update. Next frame, when the StateMachine is updated, it will call the state's 'During' method, which will process the state and will return Remain for as long as the State is active and thus the StateMachine will remain in that state. As soon as, for whatever reason, you're done with it, return Continue and next frame the StateMachine will run the Exit method, and assuming that method returns Continue, the frame after the StateMachine will move to the next state, calling the Enter method, and so on... So where can this be used? The answer is in LOTS of places... In PAWS main game class, for example, we have:
Tada. By calling:
and...
...in the Update / Draw methods of the Game class, I can now have all these different State derived classes take care of all the gameflow of the game, the Game class itself simply taking care of the lower level stuff like updating audio systems, control systems etc that I want to happen in all areas of the game. As soon as the state machine reaches the end of the states, it will loop and I'll be back at the title screen! Providing each of the states takes care of reinitialising themselves in their Enter method, and cleaning up on their Exit method, this makes gameflow a cinch. You can use as many state machines as you like, perhaps having one for handling mission flow, game mode logic... anything you like! Here are the two classes. Beware that this is 'in progress code' so I make no promises about it being perfect and totally bug free, but it's working fine for me, so... StateMachine.cs
State.cs
Okay, so to use it, you just need to declare a StateMachine:
then derive your own State class:
And finally add the class to the state machine, as explained above in my PAWS example, and call the Update / Draw of the state machine from wherever relevant... In our MyState class, it will only process the Enter method on the first update, and then will go into the During and will remain there indefinitely until the Back button is pressed, at which point it will continue out and run the Exit method for one update, and then move onto the next state. Note it may, depending on your update times, call the Draw method before it's called the Enter method. So it's important to make sure you don't try and draw something you've not yet loaded... so you might want to add a check in to the Draw method to only draw during the During or Exit stages...
These are a great way to quickly get gameflow into your game. And they're quite easy to implement into an existing game in production too, if your game loads instantly in-game and all your main stuff is at the moment just plonked into your game class it's often quite easy just to lift all that out and put it into an InGameState class... move all the stuff in Init into the Enter, and all the stuff in Update into During, all the stuff in Draw into... well, Draw.... then you can start making menu states, credits states, or whatever, and Bob's your uncle! Oh there is one other useful override for the State class:
This method basically allows us to, on a whim, decide to divert the state machine to a different state after this one, based upon some kind of criteria... For example, if the player collected all the magic baboon droppings on a level, you might award them with a bonus mini-game!
Bingo! This will check if the baboon poo collection was prestigious enough, and return the minigame's state, otherwise returning null which will just progress the states as normal. If it does divert to a new state, it will then run that state through completely before resuming its original place in the statemachine's state list. What's useful with StateMachines (except the obvious, obviously) is that while coding a new state, you can just add it to your main StateMachine first before the titlescreen and there it will be as soon as you run the game. Once you've finished it you can put it where it's supposed to be. Likewise things like logos at the start of the game, or even the entire front end menu system, can be removed by simply commenting out the line adding the state to the state machine. Magic! Hopefully this proves useful! lemmy |
|
| Author: | bignobody [ Thu Apr 02, 2009 5:08 pm ] |
| Post subject: | Re: Game Flow and State Machines |
Awesome tutorial! Having had to do these tasks before, I'm really impressed with how clean this is. Thanks for sharing! |
|
| Author: | seregrail7 [ Thu Apr 02, 2009 5:30 pm ] |
| Post subject: | Re: Game Flow and State Machines |
What I like the most is how automated it is. I've been using enums all this time. They do the job but are a bit messy. |
|
| Author: | WorldMaker [ Sat May 09, 2009 8:34 am ] |
| Post subject: | Re: Game Flow and State Machines in C# / XNA |
lemmy101 wrote: Not to be confused with Finite State Machines a State Machine (in this context) is a system for allowing a game to pass through a list of states which define different sections of the game. Um, actually, that also is a Finite State Machine. You have a set of states, that can transition between each other (given some input), and there is a finite (countable) number of possible states. There's no context difference here, you really are describing the exact same thing. Certainly the math of the above Wikipedia page may seem confusing, or the number of subtly different models that are sometimes used, but the basics are the same for just about every FSM. There are probably things on that very Wikipedia page that could apply directly to your sample, and I would suggest that its worth taking the time to learn at least some of the basic "maths" of Finite State Machines. |
|
| Author: | lemmy101 [ Sat May 09, 2009 12:37 pm ] |
| Post subject: | Re: Game Flow and State Machines in C# / XNA |
Awesome thanks World Maker! |
|
| Page 1 of 1 | All times are UTC [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|