# 1. Graphs versus the Existing FSM Part of [[Unity Behavior]]. Next: [[2. BehaviorGraphAgent and the Blackboard]]. Do not throw away [[Enemy AI State Machine]]. That series is still the right place to learn a hierarchical FSM, transitions you can step in a debugger, and a phase structure you already used for [[Boss Battles with Phases]]. This series adds a **graph asset** when the branching should be visible on a whiteboard, not only in `switch` statements. ## 1.1 What Unity Behavior is Official 6000.5 package description (and the 1.0.17 manuals): Unity Behavior is a graph-based tool for behavior trees. Graphs flow top-to-bottom with plain-language nodes, a library of pre-built nodes, C# integration, reusable subgraphs, Play-mode debugging visualization, and event-driven / observer-abort support. Typical uses listed by the package page: NPC behaviors, quest logic, environmental interactions, and game state management. The runtime piece you put in a scene is a **`BehaviorGraphAgent`** on a GameObject, pointing at a **`BehaviorGraph`** asset, with a **blackboard** of variables you can override per agent. ## 1.2 When the FSM notes are still better - Three or four states you can name in one breath (Idle, Chase, Attack, Return), with transitions you already wrote tests for. - A boss **phase** machine ([[Boss Battles with Phases]]): the phase table is an FSM; do not hide "phase 2 starts at 50% HP" in a graph nobody looks at during a balance pass. - You need to reason about *exactly* which C# method ran. A graph is data; a stack trace through your FSM is still clearer for some bugs. ## 1.3 When a graph earns its keep - A designer (or you, next month) must change "wait, then patrol, then investigate the last sensed point" without a code review of a 200-line `Update`. - Several enemies share one policy with different blackboard numbers (speed, range, wait time). - You want Play-mode visualization of *which node is running* (official package feature). - Sensing already lives in C# ([[Organic Enemy Sensing]]). The graph should **read** those results from the blackboard or an event channel, not reimplement vision cones. ## 1.4 One brain, not two The classic failure is a `GuardStateMachine` *and* a `BehaviorGraphAgent` both moving the same NavMesh agent ([[NavMesh in Unity 6 (AI Navigation 2.x)]]). Pick **one** authority for locomotion and one authority for "what am I doing." A clean split: - C# (existing) writes **facts** onto the blackboard: `Target`, `LastHeardPosition`, `CanSeePlayer`. - The **graph** decides the policy: idle, investigate, chase, give up. - C# **actions** (custom nodes, or methods the graph already calls through official bindings) perform Move / Attack. If the FSM already does all three well, you do not have to port it. This course is additive. ## 1.5 Exercise Open an enemy from the FSM series (or a gray-box capsule). Write a one-page policy: which decisions you would rather *see* on a graph, and which facts stay in C#. Do not add a `BehaviorGraphAgent` yet. ## Sources - Behavior 6000.5: https://docs.unity3d.com/6000.5/Documentation/Manual/com.unity.behavior.html - [[Enemy AI State Machine]]