State-Driven Logic with FSM

Use FSM when one mode remains active over time and controls which behavior may run. The visible result should be an object entering a named state, performing its active behavior, and leaving through an intentional transition.

Mental model

An FsmState owns four phases:

1. Enter establishes the state.
2. Active behavior runs while the state remains selected.
3. Transition checks decide whether another state should take ownership.
4. Exit releases the current state before a direct transition completes.

Examples include Patrol, Alert, Combat, Dialogue, Stunned, and Dead. Use names that express gameplay identity rather than implementation details.

Author a state family

1. Add one FsmState for each persistent mode.
2. Give every state a stable, descriptive title.
3. Put mutually exclusive states in the same FSM Group ID.
4. Configure Enter and Exit behavior before adding complex active logic.
5. Add typed transition Conditions, preferably from clearly owned Blackboard facts.
6. Connect the path that activates the first state.
7. Verify one complete transition in Play Mode.

此处插图应该是包含 Patrol、Alert 和 Combat 三个 FsmState 的 Flow Graph Editor 截图；显示相同 FSM Group ID、Patrol 到 Alert 的转换条件和各状态 Enter/Exit 路径，并标出当前活动状态。

Exclusive and parallel policy

Use Exclusive when entering one state should request cancellation of other active states in the same group. Use different group IDs when independent state families may coexist, such as locomotion and upper-body intent.

Parallel changes entry-time preemption rules; it does not make one direct A-to-B transition overlap. On a direct transition, A’s Exit completes before B continues into Enter.

Keep state and decision responsibilities separate

FSM should answer “which mode is active?” It does not need to own every action inside that mode. A Combat state may activate a Behavior Tree for priority decisions and return to normal Flow for visible effects.

Use Blackboard facts such as EnemyVisible, IsStunned, or DialogueComplete to make transition ownership inspectable. Avoid transitions that depend on hidden side effects inside unrelated nodes.

Verify the behavior

Add temporary logs to Enter and Exit while establishing the lifecycle. Remove noisy diagnostics after visual debugging and the scene result are clear.

Common mistakes

Symptom	Check
Unrelated states cancel each other	Give independent families different FSM Group ID values.
A state never activates	Trace a normal Flow route into its activation boundary.
A transition fires unexpectedly	Inspect the Condition’s Blackboard scope, key, type, and update owner.
Exit work overlaps another independent state	Confirm whether both states were already active in separate parallel families.
The graph is difficult to reason about	Let FSM own mode and move priority choice or long side-effect sequences to their proper model.

Related

• Choosing a Logic Model
• Hierarchical Behaviors with Behavior Trees
• Blackboard & Typed Values
• Debugging Running Graphs