Jump to content

  • Log In with Google      Sign In   
  • Create Account

State Machine


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Alundra   Members   -  Reputation: 867

Like
0Likes
Like

Posted 07 July 2014 - 04:13 PM

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.


Edited by Alundra, 07 July 2014 - 04:15 PM.


Sponsor:

#2 Álvaro   Crossbones+   -  Reputation: 13317

Like
3Likes
Like

Posted 07 July 2014 - 04:51 PM

State machines are not a must-have, but they are a useful tool.

I would suggest you start with concrete state machines for specific purposes instead of trying to have anything generic: Wait until you have some real experience and a good idea of what could be needed before you write a generic framework.

#3 Alundra   Members   -  Reputation: 867

Like
0Likes
Like

Posted 07 July 2014 - 09:51 PM

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 ?



#4 Ashaman73   Crossbones+   -  Reputation: 7500

Like
0Likes
Like

Posted 07 July 2014 - 10:52 PM

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.


Edited by Ashaman73, 07 July 2014 - 10:52 PM.


#5 haegarr   Crossbones+   -  Reputation: 4312

Like
3Likes
Like

Posted 08 July 2014 - 02:02 AM


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

* Understanding the Second-Generation of Behavior Trees

then come back for discussion, if needed :)

 

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



#6 Alundra   Members   -  Reputation: 867

Like
2Likes
Like

Posted 08 July 2014 - 06:18 AM


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;
  }
}
Go to AIGameDev.com, join for free (this will give you a restricted access), and read e.g. the articles / listen the recordings

Thanks for the link didn't knew that one smile.png


Edited by Alundra, 08 July 2014 - 06:19 AM.


#7 rouncer   Members   -  Reputation: 291

Like
-1Likes
Like

Posted 22 July 2014 - 01:22 PM

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.


Edited by rouncer, 22 July 2014 - 01:39 PM.


#8 wodinoneeye   Members   -  Reputation: 820

Like
0Likes
Like

Posted 23 August 2014 - 08:08 PM

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.


--------------------------------------------Ratings are Opinion, not Fact




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS