Hi all,

I'm new in AI, it's a whole subject, not easy, all must be done in a good way and need to be efficient.

I saw some books and a lot speak about state machine and some speak about hierarchical state machine.

State machine is a must-have to have a good AI system (action,state,condition,state-machine) ?

Is it good to have a generic state machine ?

Thanks for the help.

The good point of state machine is it could be reused for my motion system, who is good if the state machine is generic.

But someone told me behavior tree is better, any information about that ?

First look at what requirements you have, then look for a good solution to meet these requirements. Yes, state machines are good, behavior tree are good too and in certain situation one is better then the other. If you create a generic FSM first, without knowing the exact requirements, you will most likely over-engineer, or in other words, you will create some really complex, needless, slow stuff.

As example, I use a mix of behavior trees and FSM, my fsm are integrated in my BTs and look something like this:

int state = getState();
if(state==INIT) {
...start movement...
state = MOVE;
} else if(state==MOVE) {
  // check if target reached
  if(targetReached()) {
    state=DONE;
  } else if(movementBlocked()) {
    state=BLOCKED;
} else if(state==BLOCKED) {
  if(timeoutReached()) {
   state=MOVE;
  }
}
setState(state);

You dont need any fancy, tool supported, generic state machine for simple stuff like this. More complex stuff is handled by my BTs.

But someone told me behavior tree is better, any information about that ?

Go to AIGameDev.com, join for free (this will give you a restricted access), and read e.g. the articles / listen the recordings

* Understanding Behaviour Trees

* Behavior Trees for Next-Gen Game AI

then come back for discussion, if needed :)

BTW: You'll find accessible articles on state machines there, too.

As example, I use a mix of behavior trees and FSM, my fsm are integrated in my BTs and look something like this:
int state = getState();
if(state==INIT) {
...start movement...
state = MOVE;
} else if(state==MOVE) {
// check if target reached
if(targetReached()) {
state=DONE;
} else if(movementBlocked()) {
state=BLOCKED;
} else if(state==BLOCKED) {
if(timeoutReached()) {
state=MOVE;
}
}
setState(state);
You dont need any fancy, tool supported, generic state machine for simple stuff like this. More complex stuff is handled by my BTs.

This is what I have in my character animation state machine using if/else without state machine system :

enum TPlayerState
{
  PS_IDLE = 0,
  PS_MOVE = 1
};

// Animation state machine.
if( m_MoveDirection != DE::CVector2( 0.0f, 0.0f ) )
{
  ...
  m_PlayerState = PS_MOVE;
}
else
{
  // Check if we changed of state.
  if( m_PlayerState != PS_IDLE )
  {
    ...
    m_PlayerState = PS_IDLE;
  }
}

Thanks for the link didn't knew that one

forgive me if everyone already knows this :), I typed this out before I read enough of the posts, but I like it so im going to leave it.

I think really generally about things, and state machine, behaviour tree, scoring program, they all do the same thing, they are a commander, you do them all slightly different ways I guess.

Even an adaptive self programming robot has a state machine or something like it, controlling his global will, so they are cool, just they handle the actual way to achieve the broader goal, and the low level implementation is left variable for it to work out the exact way to win given the circumstance. Thats what im into at the moment.

The state machine you have to write has to include every minute detail of implementation, but a cool way to do it, is to leave the actual low level code to a call from the main supervisor, like so:

MAIN SUPERVISOR -> if(happy) walk to blue light, if(sad) walk to green light

SECONDARY LEVEL -> find position of thing walking to, send to movement code.

MOVEMENT CODE -> deal with obstacles, move legs over tough terrain, and get to the position.

Breaking it up into modules makes a really hard job easier, especially if you worked for NASA, making some automonous planet rover.

A self programming bot isnt really necessary, a manually coded one works fine, and uses a much smaller processor, but as im into ai hardcore, its a more worthwhile goal to me.

Theres more than one way to 'generisize' a state machine.

A number of years ago there was a Paper in one of the the AI Game Programming Wisdom books (two I recall)

about using C macros to do alot of the very low level detail structuring implementing Hierarchical FSM which helped make creating the game logic more into a scripting process.

I used something like that for a simple reactive control system for a simulation, unfortunately the AI required additional complications --- every 'turn' there was a sensor aggregation phase , a decision against that aggregated situation info, and finally the action phase. With continuation between turns for some actions and linked actions between multiple objects it got rather more intricate (the key idea was to keep the different phase logic grouped/encapsulated within the script form). It worked but I saw that more complicated AI for some 'smarter' objects required a Planner type mechanism.