Currently I have the follow states:

Need To Run
Need To Walk
Need To Fight

Am I misunderstanding it and mixig possible actions with states ?

I mean, to me Need To Run would either return true of false telling wether I should procced to the Run action or not and same goes for the other needs.

While I am fighitng should I have second FSM to threat what skills it should be using for example if it needs to heal or not ?

For instance inside the fight I would have the another FSM for

Need To Heal
Back To Fight
Use Skill

2 Answers 2


It does seem a bit odd to have Need To Run and Run states.

What might be better is having a Running, Walking and Fighting state. Your finite state machine then checks the appropriate logic (Do I need to run? Do I need to walk? etc) to determine what state to transition to.

Check out Programming Game AI by Example. In that book, there is an implementation of FSMs using the state design pattern. A nice, clean and flexible way of implementing FSMs.

You can find the source for it here: http://samples.jbpub.com/9781556220784/Buckland_SourceCode.zip

The state specific stuff is actually available freely online, but the book is a solid investment as an introduction to AI. The state explanations can be found here: http://www.ai-junkie.com/architecture/state_driven/tut_state1.html

Hope that helps.

Just to add some points regarding your second FSM, I would suggest looking into hierarchical FSMs as that's essentially what you're doing, but the same concept as above applies really. Later on, if you wanted to get really fancy you could use some sort of planner, or even swap it out completely to use behaviour trees. But they're probably a story for another day :)

  • \$\begingroup\$ thanks just brought it will take some time to arrive but would you mind telling me if the example is in C# or just generic ? \$\endgroup\$
    – Guapo
    Commented Mar 29, 2011 at 19:22
  • \$\begingroup\$ Sorry, I forgot to mention that the source code is available at Buckland's site. It's in C++, but it's fairly straightforward to work out what's going on since it's all set out in a nice OOP approach. I'll edit in a couple more links \$\endgroup\$
    – Ray Dey
    Commented Mar 29, 2011 at 19:30
  • \$\begingroup\$ About your edit, right now I am taking it easy doing some tests and examples to see how it work as a learn it, but that does seems interesting and I hope to be able to do it ;) \$\endgroup\$
    – Guapo
    Commented Mar 29, 2011 at 21:32
  • \$\begingroup\$ I figured as much, I just mainly put it in there for completeness' sake, but it's pretty interesting stuff whenever you want to get on to it :) \$\endgroup\$
    – Ray Dey
    Commented Mar 29, 2011 at 21:33
  • \$\begingroup\$ @RayDey thanks for linking to that article it was more than helpfull ! thanks. \$\endgroup\$
    – PeeS
    Commented Jul 26, 2012 at 17:15

Sounds like you don't need an FSM, but instead a behaviour system.

Each state becomes a behaviour, and should have a function that returns a priority, with that value being higher the more it wants to execute. So for instance your Heal behaviour would return a high priority when the entitiy is injured, and Fight would return a low priority when there is no enemies around. This priority calculation function is the "need to" state in your current system.

The behaviour that returns the highest value then gets to execute.

It's up to you if the priorities are recalculated at a set time step, and so states could flip-flop rapidly, or if once a state has control it is up to the state to yeild, which may lead to states monopolising control too much but is a bit more "FSM-y".

The drawback of this approach over FSMs is that there are no defined transitions. Depending on your implementation a state may have no say over when it loses control. This could make interfacing with your animation system difficult and may not be a good fit for some problems.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .