domains / families / software-engineering / behavior

behavior

separate

Drive Unity Behavior behavior graphs and blackboard variables

When to use

• Wiring NPC/AI decision logic
• Working with behavior trees/graphs
• Reading/writing blackboard variables
• Behavior graph asset discovery
• Agent wiring
• Blackboard variable access

When not to use

• The authoring node graph is stored as a `[SerializeReference]` polymorphic `List<NodeModel>` with `PortModel` cross-references, an embedded `SerializableCommandBuffer`, and a version-stamped `NodeModelInfo` cache. Writing it correctly mean…
• Every edit must be followed by a consistent rebake of three sub-assets (runtime graph, runtime blackboard, debug info) plus `VersionTimestamp` synchronization, or the asset silently desyncs from its baked runtime graph.
• The serialization schema is explicitly versioned (`kLatestSerializationVersion`, currently 3) and has changed within the 1.0.x line. Reflection-driven topology writes would break on a patch release.
• **Preferred** — author the graph in the Behavior editor window (`Window > AI > Behavior`, or double-click the asset), then use this module to inspect and wire it up.
• Duplicate a known-good graph with `asset_duplicate` and rebind it, instead of building topology from nothing.
• For mechanical, repetitive edits to an existing graph, edit the `.asset` YAML directly — load the [yaml-editing](../yaml-editing/SKILL.md) advisory first for the managed-reference and `fileID` rules, and re-verify with `behavior_graph_info…
• `behavior_graph_create` produces an empty graph. Node authoring still requires the editor window.
• Blackboard variables cannot be created, renamed, retyped, or deleted — only existing variables can be assigned. Add variables in the Behavior editor's Blackboard panel.

Skill page

Source