Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I dont know much about finite state machine in AI or other game behaviors in game, except this quick tutorial with a Miner: http://www.ai-junkie.com/architecture/state_driven/tut_state1.html which is object oriented.

I don't really know if this tutorial describes the State pattern or not, what do you think ?

I'm not speaking about other more arithmetic-oriented stuff like steering or physics or path-finding or collisions, but rather about game logics, state-driven AI, and things that involves a lot of simultaneous states and ifs and/or switches

What are the pro/cons of using either a State Pattern or a sequential check of a plain state structure like this:

struct States
{
bool is_walking, is_running, holds_a_weapon, is_crouch;
int weapon_id, int id_team;
};

void HandleStates (States state)
{
//etc
}
share|improve this question
2  
I think you might need to form your question a bit better, but a quick answer to above so that you might do that is in general the state removes the If checks. switch (state) { case blah } to create a jump table, or my personal favourite way of doing things, function pointers or delegates on a stack or queue if AI should return to what they were doing before or move on to the next thing... –  James Jan 19 '11 at 16:40
add comment

1 Answer

up vote 8 down vote accepted

I will try to answer this as best as I can, but there are certain "best practices" which I am unsure on, but I'll try to break it down as cleanly as possible.

FSMs

Firstly, the Miner tutorial is from Programming Game AI by Example by Mat Buckland (which I do recommend you get as an introduction to AI). He uses an enum for each state, NOT a struct. With the struct in your example you have booleans as the states, so you could have any number of these on at the same time. This might lead to behaviour you want, but more often than not with FSMs (Finite State Machines) it leads to undesirable behaviour.

For example:

enum
{
WANDER_AROUND,
ATTACK,
RUN_AWAY,
};

Secondly, that's not the only way he describes states. The way I personally prefer (depending on the situation) is to create an abstract class called State that has an Enter(), Exit() and Update() functions. Then create my states as subclasses of the State class.

Like this picture (found on page 2 of that link actually): alt text

State Pattern

In my personal opinion, the state pattern is just a part of software design where the software has a number of states. The implementation is down to the developer. I don't feel there's a proper difference between using a big switch statement or creating a complete state machine to run all your states like I've outlined above. They're essentially doing the same thing. So in that respect, the answer to one of your questions is yes, I do believe that page describes the state pattern.

Pros/Cons

There are pros and cons to any method you use to implement a state-driven design.

Using an If/Else or Switch Statement

Pros:

  • Very easy to add and check conditions of states
  • Can be prototyped very quickly

Cons:

  • When you've got a load of states, it can turn very ugly, very quickly.
  • Keeping track of transitions, effects when the state is entered/exited or anything specific to the state is difficult

Using an object-oriented state machine

Pros:

  • Highly extensible - the only thing you need to do is create a new state that inherits the abstract State class
  • Easily maintainable - You don't have to worry about spaghetti looking code as each state resides in its own class. You can easily see the conditions associated with that state without worrying about the other states.
  • Intuitive - If you're working on a team project with this sort of state machine, it will be so much easier for the person reading your code. They won't have to read through lines upon lines of code just to get to a certain state ("Always program as if the programmer maintaining your code is a psychopath who knows where you live!" :))

Cons:

  • Slight learning curve - This design may take a while to get your head completely round when implementing it
  • I honestly can't think of any more, since I do prefer this way, but if anyone wishes to add to it, just comment and I'll add them.

I hope that answers all your questions. In fact, I've just opened up my copy of Programming Game AI by Example and Mat does mention that the state machine is known as the "state design pattern". Personally, I disagree, but to each his own.

Hope it helps :)

share|improve this answer
1  
+1 this describes essentially how I created my State Machine. It is working out well. –  Kyle C Jan 21 '11 at 2:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.