My point was that it''s not really a state. What I meant is this:

while(true){   DrawFrame();   if(Soldier.See(health)) Soldier.MoveForward(1 unit)   if(Soldier.UnderFire()) Soldier.MoveBackward(1 unit)} 

Soldier isn''t in any particular state at any point in time. In fact, I could replace it with any other Soldier, and get the exact same behavior, because they don''t hold any state. If they did hold a state, then replacing a Soldier that is in the state BERZERK with a soldier that is in the state FEARFORHISLIFE would not yield the same results. My perception is that a fsm soldier''s code would look like this:

while(true){   DrawFrame();   if(Soldier.See(health)) Soldier.state = SEEINGHEALTH   if(Soldier.UnderFire()) Soldier.state = UNDERFIRE   switch(Soldier.state){      case SEEINGHEALTH: Soldier.MoveForward(); break;      case UNDERFIRE: Soldier.MoveBackward(); break;   };} 

So even if the soldier stops seeing health, it will still keep it in mind, because Soldier.state persists from one frame to another.

But I''m probably confusing ''memory'' and ''finite-state machines''.

Cédric

cedricl,

Consider the transition condition

If (Soldier.LoseTarget()) Soldier.ChooseRandomAction() 

A well designed FSM should account for when things STOP happening, as well as when they first happen. Most people only think of FSMs in terms of the start of events that trigger state changes. For instance, coming under fire is likely to make the AI react (hide, run, return fire). If you fail to provide the AI with a state transition to leave that state - for ALL possible transitions out of the state - then you haven''t designed the AI with sufficient detail.

For instance, the AI might consider itself no longer under fire when it believes that:

a) the firer is dead;
b) the firer is out of ammo
c) the firer has fled out of range;
d) the AI has fled out of range;
e) the AI hasn''t been fired upon for x seconds.

So, if the AI finds a place to hide and keeps their head down for x seconds, they might reasonably believe that they are no longer under fire. Until they pop their head up of course! So transition cause e) might have a conditional test on it... stick head up for a brief moment and see if it gets shot off! If it doesn''t, confirm the transition OUT OF the ''under fire'' state. As to what state the AI transitions to... perhaps ''hunt down'' the firer (if they weren''t killed) or perhaps ''return to state that was prior to fired upon''.

I hope this makes things a little more clear.

Cheers,

Timkin

Thanks Timkin... I keep looking in on these threads when I don''t have enough time to explain fully.

Dave Mark
President and Lead Designer
Intrinsic Algorithm Development
"Reducing the world to mathematical equations!"

quote: Original post by cedricl
Like, in the original Mario Bros., there wasn''t any FSM at all.

Yes there was - different things happened when you ran over a critter depending on what state it was in - if it was face-up it got kicked off the ledge, if it was face-down you died.

FSMs are everywhere, often in latent un-intentionally-coded forms. If the states and transitions are not sufficently complicated, it''s not worth the bother of coding up state-machine mechanics - but it they are complicated a FSM framework helps to organize it alot.

quote:
''return to state that was prior to fired upon''.

FSM are often implemented using a state stack to facilitate this behavior (often along with a message queue to supply event notification, OnEnter, OnExit being important ones).

quote:
Original post by cedricl
Like, in the original Mario Bros., there wasn''t any FSM at all.

Original post by Magmai Kai Holmlor
Yes there was - different things happened when you ran over a critter depending on what state it was in - if it was face-up it got kicked off the ledge, if it was face-down you died.

Yeah, but it''s a physical state, like ''seeing health'', ''under fire'', or its position. I would argue that you can replace an upside-down turtle with any other upside-down turtle and get the same behavior, because they don''t remember anything about their environment.

But fine, FINE! It''s a FSM! I give up . Thanks a lot for all the replies, everyone

Cédric

quote: Original post by cedricl
I would argue that you can replace an upside-down turtle with any other upside-down turtle and get the same behavior, because they don''t remember anything about their environment.

I understand your point cedricl, however it is not relevant to the definition of a FSM. FSMs don''t require a memory of their environment as they are a simulus-response model for an agent function. An FSM is just an object that transits between states (from within its state space) based on stimuli, or the removal of stimuli (which is itself a stimulus).

I''m curious as to why you think a FSM needs a memory of it''s environment. Perhaps you could explain please?

Thanks,

Timkin

[sorry for the late reply; my Internet died]

It''s probably just a misconception. I must''ve understood it the wrong way at the start. I thought that if ''Any time you can tell if a game is saying "if this then that" it is a form of finite state machine'' is true, then indeed, every game has this ''incredible feature'', and there''s not much point in talking about it.

OTOH, even if FSMs did involve memory of its environment, it wouldn''t really be any more interesting

I must''ve been impressed by the term ''Finite State Machine''. It sounds mean and complicated.

Cédric

quote: Original post by cedricl
I must've been impressed by the term 'Finite State Machine'. It sounds mean and complicated.

Cédric

Actually they're pretty simple.

The basic idea at its core is this:

An object has a state and reacts a certain way based on that state. So as long as it is in a certain state it acts that certain way.

So, an object may be in the state ATTACK. So whenever this object is to do something it will attack.

Then perhaps something may change its state. Maybe the object gets wounded or something. This may change the object's state to FLEE. Then the object would flee until something changes its state again.





[edited by - Nazrix on June 24, 2002 4:41:29 AM]