Hi all,
In this and other forums, I've seen lots of references to how using FSMs can be really helpful when designing and coding a game. Unfortunately, I've yet to find a really good article/forum post/tutorial that explains the concept in terms of game development.
I've tried reading up on State Machines on Wikipedia, etc, and using the forum search here, but I'm still slightly confused. Can anyone point me to some really good intros for a beginner?
Thanks in advance.
auryx
What is a (Finite) State Machine? Why are they useful for game dev?
Think of your typical AAA game. When you start the game you're usually presented with a splash screen featuring the developer, then after a period of time or pressing a button, you get another splash screen of the company they licensed IP from, then a splash screen for the publisher, then a splash screen for some of the libraries they used, and eventually you get to a loading screen. After the loading screen you usually see a main menu of some sort. From there you can load a game, start a new game, change your options, exit the program and maybe a few other menu choices like multiplayer. From the loading menu or from the main menu you can go to the game proper. And in the game proper you can usually pause the game, exit the game or go back to the main menu. One way to organize these different game states is as a finite state machine.
Another application is for enemy AI. Consider a sentry NPC. It can start off in a patrol state, where it just walks back and forth between two spots. If it hears a noise it can go into an investigation state, where it goes to where the noise came from. If it doesn't find anything, it can go back to the patrol state. If it spots the player it can go into an attack state where it tries to kill the player. If it loses sight of the player it can go into the investigate state to go look where it last saw the player.
Another application is for enemy AI. Consider a sentry NPC. It can start off in a patrol state, where it just walks back and forth between two spots. If it hears a noise it can go into an investigation state, where it goes to where the noise came from. If it doesn't find anything, it can go back to the patrol state. If it spots the player it can go into an attack state where it tries to kill the player. If it loses sight of the player it can go into the investigate state to go look where it last saw the player.
EDIT:
There are some advantages in implementing FSMs as objects
Without objects your game might look like this
[source lang="cpp"]while(GameOn)
{
if(state==menu)
menu.doStuff();
if(state==setting)
setting.doStuff();
else if(state==scene1){
if(playerDead) playerdead.dostuff(); else scene1.doStuff();}
else if(state==scene2)
scene2.dostuff();
//and so on
}
[/source]Everytime you need to add a scene, you have to add your scene to this if-else list. It can get complicated if a state has a substate.
but with objects, your game loop will look like this
[source lang="java"]while(gameOn)
{
currentState.doStuff
}[/source]
You can change what currentState refers to when needed.
For example, when the game starts currentState can refer to MenuState. But when you press "play" button on the Menu screen, you can change your currentState refer to PlayState.
There are some advantages in implementing FSMs as objects
Without objects your game might look like this
[source lang="cpp"]while(GameOn)
{
if(state==menu)
menu.doStuff();
if(state==setting)
setting.doStuff();
else if(state==scene1){
if(playerDead) playerdead.dostuff(); else scene1.doStuff();}
else if(state==scene2)
scene2.dostuff();
//and so on
}
[/source]Everytime you need to add a scene, you have to add your scene to this if-else list. It can get complicated if a state has a substate.
but with objects, your game loop will look like this
[source lang="java"]while(gameOn)
{
currentState.doStuff
}[/source]
You can change what currentState refers to when needed.
For example, when the game starts currentState can refer to MenuState. But when you press "play" button on the Menu screen, you can change your currentState refer to PlayState.
Without a finte state machine, your game loop might look like this
That's still a finite state machine. What you're talking about is the advantage of implementing a finite state machine with objects, not the advantage of having a finite state machine.
[quote name='lride' timestamp='1352047883' post='4997215']
Without a finte state machine, your game loop might look like this
That's still a finite state machine. What you're talking about is the advantage of implementing a finite state machine with objects, not the advantage of having a finite state machine.
[/quote]
Thanks for catching my error. I didn't consider the definition of FSM
Author
Thanks SiCrane and Iride for the replies. So, to use your examples SiCrane, what is the benefit of actually doing it that way? Is it just a "different" way to approach the architecture of the game? Or does thinking about the game in that way provide real benefits in terms of efficiency or clear coding?
auryx
auryx
A finite state machine is a quite general and abstract model for something whose behaviour can be described in terms of "states". There exists several different implementations and versions (they can be deterministic or not, they can be event based or not..). The use of FSMs is not motivated by efficiency or clear coding. These things depends on the specific implementation. FSMs are used because they can often model complex behaviours using a small and easy to understand description.
Author
Thanks Apatriarca, that's an excellent explanation. So it is essentially a modelling technique, I can understand that.
auryx.
auryx.
Can anyone show a pseudo-code example depicting a FSM-driven game loop and a non-FSM-driven game loop? I'm not 100% how the latter would look
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
