Unity-Verhaltensbäume

Behavior Trees and Unity Behavior Graphs

Inspect the existing NPC architecture, installed Unity Behavior/third-party framework and update schedule. Extend that framework when suitable; a new reusable tree runtime needs a concrete task-driven reason.

• Define per-NPC blackboard keys, types, writers, validity and reset behavior. Share facts deliberately; do not let a static blackboard accidentally merge every actor's state.
• Conditions normally resolve immediately; actions can remain Running. Define success, failure and cancellation for movement, animation and timed tasks so a missing target cannot leave a branch running forever.
• Distinguish memory and reactive composites. A memory sequence resuming an action may stop checking an earlier guard; re-check the necessary conditions or use the framework's supported reactive/abort semantics.
• Specify selector priority, sequence failure and parallel success/failure policies. A higher-priority interrupt must release reservations, motor commands and listeners owned by the abandoned branch.
• Keep cooldown ready-times across branch resets when intended. Re-entering a branch must not bypass its cooldown or duplicate a one-shot effect.
• With Unity Behavior, inspect the installed custom-node lifecycle and blackboard API. Use Editor-aware graph tooling when available; do not invent serialized node identifiers or assume a graph was generated successfully.
• Build/reuse nodes at initialization and tick on a chosen decision cadence. Trace the active branch, guard result and transition reason without allocating a new tree each frame.

Verify a running action losing its target, a higher-priority interrupt, branch re-entry, pooling/reset, parallel failure and a no-valid-action fallback. Report framework/version and observed graph behavior.

Reference: Unity Behavior custom nodes, matched to the installed version.