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.