Hierarchical Behaviors with Behavior Trees

Use a Behavior Tree when the runtime must choose among prioritized or ordered behaviors as conditions change. Flow activates the tree; the tree owns selection; Success or Failure returns control to Flow.

Mental model

BTRoot is the entry boundary for a Behavior Tree branch. It owns the tree tick and exposes result routes back to normal Flow.

Inside the tree:

• BtSelector chooses the first child that can succeed.
• BtSequence requires children to succeed in order.
• BTCondition performs a pass/fail check.
• BTAction performs leaf work.
• Decorators modify child behavior.
• Services perform small periodic side tasks while the tree runs.

Child order is behavioral, not merely visual. Read children left to right according to the parent composite.

Author a decision tree

1. Add BTRoot and connect normal Flow into its Active control input.
2. Add child outputs on the root.
3. Choose a top-level Selector or Sequence.
4. Add Conditions and Actions as leaves.
5. Order children by intended priority or required sequence.
6. Route root Success and Failure to visible Flow results.
7. Enter Play Mode and change one decision fact.

此处插图应该是 Combat Behavior Tree 的 Flow Graph Editor 截图；BTRoot 连接 Reactive Selector，子项依次为 Attack、Chase、Idle，并标出从左到右的优先级以及 Success/Failure 返回 Flow 的连接。

Reactive and memory behavior

A Reactive composite reevaluates from its first child, allowing a higher-priority option to preempt lower work when facts change. A Memory composite continues from its running child until that child finishes.

Use Reactive behavior for priorities that must respond immediately. Use Memory behavior when a selected sequence should continue. Protect non-interruptible work with the supported decorator pattern instead of hiding it in a long leaf.

Split decisions from consequences

Keep the tree focused on choosing intent. Long animation, camera, audio, UI, and multi-system timelines are often clearer after the tree returns a result to normal Flow.

For example, the tree selects Attack and writes or routes that intent. Flow then plays the Gesture, waits for a Marker, applies damage, and triggers feedback.

Common mistakes

• Adding a root without connecting Flow into Active.
• Treating canvas position as decoration when child order controls behavior.
• Expecting a BTAction to replace a Condition for gameplay eligibility.
• Using Reactive reevaluation for work that must finish uninterrupted.
• Leaving root result outputs without a defined handoff.
• Putting the entire visible gameplay timeline inside decision leaves.

Related

• Choosing a Logic Model
• State-Driven Logic with FSM
• Branching, Guards & Execution
• Debugging Running Graphs