What is the difference between FSM and Behavior Trees?

So rexrainbow asked me via PM what is the difference between FSM (Finite State Machines) and Behavior Trees. I was unable to reply due to the spam filter and thought this would be better suited for an open forum discussion.

[quote:3bqwqc4m]On the Unity Forums SteveB asked an interesting question: why a behavior tree and why not a finite state machine (PlayMaker)? According to some, the age of finite state machines is over. We aren't going to go that far, but we are going to say that a finite state machine should not be the only AI technique that you use in your game. The true power comes when you combine both behavior trees and finite state machines together.

Before we continue, we want to point out that finite state machines are by no means required for behavior trees to work. Behavior trees work exceptionally well when used all by themselves. The CTF and RTS sample projects were created using only behavior trees. Behavior trees describe the flow of the AI whereas finite state machines can be used to describe the function.

[quote:3bqwqc4m]Behavior trees have a few advantages over finite state machines: they provide lots of flexibility, are very powerful, and they are really easy to make changes to. But they definitely do not replace the functionality of finite state machines. This is why when you combine a behavior tree with a finite state machine, you can do some really cool things.

Lets first look at the first advantage: flexibility. With a finite state machine (such as PlayMaker), how do you run two different states at once? The only way we have figured it out is to create two separate finite state machines. With a behavior tree all that you need to do is add the parallel task and you are done - all child tasks will be running in parallel. With Behavior Designer, those child tasks could be a PlayMaker FSM and those FSMs will be running in parallel. In addition, lets say that you also have another task running in parallel and it detects a condition where it needs to stop the PlayMaker tasks from running. All you need to do for this situation is add an interrupt task and that task will be able to end the PlayMaker tasks immediately.

One more example of flexibility is the task guard task. In this example you have two different tasks that play a sound effect. The two different tasks are in two different branches of the behavior tree so they do not know about each other and could potentially play the sound effect at the same time. You don't want this to happen because it doesn't sound good. In this situation you can add a semaphore task (called a task guard in Behavior Designer) and it will only allow one sound effect to play at a time. When the first sound finishes playing the second one will start playing.

Another advantage of behavior trees are that they are powerful. That isn't to say that finite state machines aren't powerful, it is just that they are powerful in different ways. In our view behavior trees allow your AI to adopt to current game state easier than finite state machines do. It is easier to create a behavior tree that will adopt to all sorts of situations whereas it would take a lot of states and transitions with a finite state machine in order to have similar AI.

One final behavior tree advantage is that they are really easy to make changes to. One of the reasons behavior trees became so popular is because they are easy to create with a visual editor. If you want to change the state execution order with a finite state machine you have to change the transitions between states. With a behavior tree, all you have to do is drag the task. You don't really have to worry about transitions. Also, it is really easy to completely change how the AI reacts to different situations just by changing the tasks around or adding a new parent task to a branch of tasks.

Just like behavior trees have advantages over finite state machines, finite state machines have different advantages over behavior trees. This is why the true magic happens when you join a behavior tree with a finite state machine. You can use PlayMaker for all of the condition/action tasks and Behavior joining Behavior Designer with PlayMaker is where the true magic happens. You can use PlayMaker for all of the condition/action tasks and Behavior Designer for the composite/decorator tasks. With this setup you'd be playing off of each others strengths. The flexibility of a BT and the functionality of a finite state machine.

I got this info from -

www dot opsive dot com/assets/BehaviorDesigner/documentation.php?id=49

TL;DR - It would make AI development, iteration, and execution allot easier and more flexible. Hope that explains that for you.

It might be more clear for me. - Understanding Behavior Trees.

[quote:35s9rw0u]Behavior trees focus on increasing the modularity of states by encapsulating logic transparently

That's why I am confused.

In this page,

This is Hierarchical FSM

And this is Behavior Tree

It looks like that Behavior Tree is still a Hierarchical FSM.

Just encapsulate the IDLE, ATTACKING, etc into sub FSM. In runtime, when main FSM go to IDLE state, create a sub FSM to handle the detail. On the other word, this sub FSM is a task of IDLE state.

rexrainbow -

Ah Ok,

So from my understanding - Behavior Trees just a very simplified Hierarchical FSM but it allows logic to be reused in a highly modular manner.

So for example - You would have code for Idle in one script, Suspicious in another and Attacking in another. But you would call them in a certain order. Your AI does not go from Idle to attacking straight away.

Your AI needs to be suspicious first before attacking.. That said I could be wrong.

I had made FSM plugin before.

It separates transfer logic into dedicated condition. So that I guess it could make behavior trees. (I had used main FSM and sub-FSM before,)

I had made before.

It separates transfer logic into dedicated condition. So that I guess it could make behavior trees. (I had used main FSM and sub-FSM before,)

Awesome!

Keep me in the loop

glerikud rexrainbow jayderyu Nesteris jojoe

I'm confused which is the best combination or stand-alone solution (Behaviour Machine Indie/pro?)

http://forum.unity3d.com/threads/playma ... pt.105875/

playmaker & uscript

Uscript:

If you wish, you can combine both tools just fine-- in fact I think they work very well together!

Playmaker:

Also, bear in mind, with the 1.2 update, PlayMaker now has generic Get/Set Property Actions that let you interface with Unity components without writing custom actions.

And I'll also be spending some time with uScript to see how to maximize PlayMaker + uScript (e.g., making PlayMaker actions with uScript). That could also be a killer combo!

Dreamora:

The difference is that uScript is a visual scripter for "general purpose code", so you can do basically everything but you are also responsible for managing it meaningfully.

PlayMaker on the other end is no visual scripter in the same sense, its a Finite State Machine Editor. That has its benefits and cons, but especially if you are no savy programmer this is a major benefit as it ensures that you think about stuff in a clean way.

uScript / Universe both don't lend a hend to prevent beginners from creating spaghetti code in graphs - which out of my view and experience means that you create even worse code than in text as a graph takes several times longer to be understood especially if it missbehaves.

So combining the two and making best use of them where they really shine is likely the best thing you can do

...

uScript is a visual scripter -> replaces writing text by placing the more or less same stuff in nodes

PlayMaker is an FSM editor -> you define states, define what happens when a state is entered, what happens upon exit of a state and upon transition and basing on whta such transitions happens

Thats the difference

anything beyond requires that you read up on the two things and what a Finite State Machine is

...

Conversion to uScript would be relatively easy depending on what it does (anything thats very set enumeration / loop heavy can be hairy to deadly), but conversion to PlayMaker is basically impossible unless you had clean, state based code right from the start.

Its out of my view impossible that you can track down errors in logic faster with any form of visual scripting than you can with debugging gives gives you clear insight. As uScript at the time lacks a visual debugger, I would have to point you to Antares Universe if you want to stand a chance to even identify errors in logic, uScript requires that you are able to pull of educated guesses to godlike guesses to find such errors or that you annoy yourself to hell by using the comment functions which let nodes that are activated fire off a text (thats as bad debugging wise as debugging was in unity 2.x prior the mono debugger support)

There is one exception to this 'impossible': If you have a heavily state based environment, then PlayMaker will definitely allow you to find state transition problems and state mixup problems significantly faster than code level debugging as you aren't flooded with a lot of info you didn't want and didn't need

...

They generate functionality, they have nothing to do with "gaming tools" nor would I define them as RAD tools as they aren't limited in any such way, they can do what you feed them with through adding custom functionality.

Also PlayMaker is no "YES/No" way thing but a state machine. State machines have nothing to do with yes / no or even branching as such. If you search for an analogy think of a DVD player thats in fast forward, rewind, stop, pause or play state, that for example would be a state machine. Games to a very large degree are state machines so its very well suited for this usage. There are only a handfull of areas where it can't be used and where you would need to use independent code or uScript, but half those areas also required that you are an advanced programmer with experience or interest to learn about the field indepth.

For Unity:

Playmaker

Uscript

AI For Mecanim

Behaviour Machine Indie/pro

Behave 2 for unity

Node Canvas

uFrame Game Framework

Antares Universe

Some of theme are now on sale.

What can Ashley use from these for C3?