Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I read discussions about state machines vs. behavior trees, it is often in favor of using one over the other. However, this seems odd to me that you wouldn't still need a state machine to manage the player character and static game entities (weapons, equipment, food, money, etc.). Do behavior trees translate to those concepts as well, even though they aren't technically AI?

share|improve this question
as stated in wiki page behavior trees used in games are mostly something like a finite state machine. I'm not sure if there really is a need to define which one your AI is using since for games it's usually a combination of algorithms that gives the best answer. – Ali.S Sep 29 '11 at 19:28
up vote 7 down vote accepted

A behavior tree is essentially a sub-type of a (possibly non-deterministic) state machine. Behavior trees are used not because they can do something FSMs can't, but because they are simpler to follow and understand for us humans.

Generally, AI has tons of states, and behavior trees are used to make them understandable. Other management, on the other hand, usually uses few states, and is perfectly clear even with most brain-dead FSM implementation.

If you, for some reason, have really complex behavior outside the AI - for example, you're making a game about alchemy, with tons of interlocked recipes, item properties, etc - using behavior trees instead of state-machines might be helpful.

share|improve this answer
+1 This is possibly a better answer than mine! – Roy T. Sep 30 '11 at 16:29

Look at it like this, an enemy entity (clearly something in need of AI) is something that needs a behavior of some sort. We need this behavior to be conditional and not totally predictable. A behavior tree (with weighted-random chances when making a choice) is a good fit for something like this.

Now let's take a look at a gun. This clearly is not an item that is in need of a complex behavior, frankly I would not even suggest a (complex) state machine. All the gun needs is a few rules:

  • Trigger pulled + clip is not empty = fire bullet
  • Trigger pulled + clip is empty = make click sound
  • etc...

So that's basically how I see how someone could make an educated guess on what system best to use, of course there are always exceptions but always first try the simplest solution imaginable, often simple rules are the most fun (since people can understand them and mechanics do not become a black-box).

share|improve this answer
I like seeing "etc." there because that can cover the rare occurrence of a "mechanical error" (e.g., the firing mechanism jammed), defective ammunition (e.g., the bullet was a dud), etc. +1 for a really good answer. – Randolf Richardson Sep 29 '11 at 23:32
@RandolfRichardson tbh I haven't played a game that has that mechanic. I also said "of course there are always exceptions but always first try the simplest solution imaginable". And a mechanic that randomly breaks things or misfires things isn't a behavior tree at all. It's just a random chance per execution of a rule. Trigger pulled + clip not empty = fire bullet unless dud-roll > 5. – Roy T. Sep 30 '11 at 5:42

Your Answer


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.