I wrote an article 2 years ago for a new Game AI pro book, but the book doesn’t seem to be happening and my patience with the whole thing has worn out so I’ll be posting the paper here in the hopes that some people will read it!
Abstract:
The Behavior Tree (BT) is one of the most popular and widely used tools in
modern game development. The behavior tree is an extension to the simple decision tree approach and is analogous to a large “if-then-else” code statement. This makes the BT appear to be a relatively straightforward and simply technique and it’s this perceived simplicity, as well as their initial ease of use, which has resulted in their widespread adoption with
implementation available in most of the major game engines. As such, there is a wealth of information regarding introduction, the implementation and optimization of the technique, but little in the way of best practices and applicability of use.
The lack of such information combined with “silver bullet” thinking, has resulted in widespread misuse across all experience levels. This misuse has resulted in monolithic trees whose size and complexity has made it all but impossible to extend or refactor without the risk of functional regression. Combine the perceived simplicity with the lack of information regarding the inherent problems as well as the lack of information on how to best leverage the technique, and the result is a ticking time bomb for both new and experienced developers alike. This chapter aims to discuss the weaknesses of this technique as well as discuss common patterns of misuse. Finally, we will discuss the suitability behavior trees for agent actuation.
Taking Initiative 
Thank you for an article on Behavior Trees.
I just finished reading it and I think I understand the need to separate the actuator behavior from the decision making, but wonder what tool should be used for the decision making aspect?
Very interesting, and while writing BTs, you can easily notice you’re mixing high-level logic (“MoveToCover”) with low-level behavior (“MoveToPosition X”), and this definitely rings some alarms
I have the same question as mike though, how to describe the decision making?
I’m thinking both Decision Making layer and Actuation layer could be described in BTs, albeit distinct ones.
The decision-making behavior tree would be composed of purely conditional nodes and would decide which actuation BehaviorTree would be active. The actuation BehaviorTree would run strictly what it needs to complete its low level behavior, assuming that all pre-conditions are true.
If some condition changes, the decision-making BT would be responsible for aborting the actuation BT.
Although this conceptually separates the concerns, I dont know this would be true in practice.