Transition Evaluation and Priority

Use transition settings to control when Conditions are checked and which destination wins when several transitions are valid. Most unexpected loops and skipped states come from evaluation timing or transition order rather than the State itself.

Watch the conditions and transitions tutorial on YouTube.

In the editor

Select a transition to configure its Conditions, Condition Mode, and Evaluation Mode in the Element Inspector.

• Condition Mode: All requires every enabled Condition to be valid.
• Condition Mode: Any allows one valid Condition to permit the transition.
• Continuous evaluates while the source State is active.
• On State Finished evaluates when the State finishes.
• On Iteration Complete evaluates after an Action State completes one Action iteration.

Disabled Condition rows do not contribute. An empty or incorrectly filtered Condition list may therefore make the transition behave differently from its visible label or intended design.

Resolve competing transitions

When several outgoing transitions are eligible in the same evaluation pass, their serialized order determines which is considered first. Put the most specific or urgent route before a broad fallback.

For a Chase state:

1. Put Health Low → Flee before ordinary combat choices when survival must win.
2. Put Target In Range → Attack before Target Lost → Patrol when the target checks could overlap for one frame.
3. Keep a broad timeout or default route last.

Do not encode priority only through graph position. Moving a line for readability does not necessarily change serialized transition order. Inspect and reorder the owning transition list where the editor exposes it, then verify the result in Play Mode.

Choose evaluation timing

Use Continuous for perception, input, health, or another rule that should interrupt an active state. Use On State Finished when the current work must complete before leaving. Use On Iteration Complete when a repeating Action sequence should finish one pass before the decision is reconsidered.

Continuous evaluation is responsive but can expose short-lived values and cause rapid state changes. A finishing evaluation is predictable but may delay urgent reactions. Choose according to gameplay ownership, not as a performance shortcut.

The transition’s Evaluation Mode controls when it is eligible; the State Machine component’s Evaluation Type controls how much evaluation can occur within one tick. A chain such as A → B → C can traverse both transitions in one tick when their Conditions and evaluation timing permit it and the component’s evaluation limit allows it. Entire Graph can continue through multiple states, while Count bounds the work with Max Evaluation Count. See Performance for these limits.

Use Any for shared interrupts

The Any State represents one transition source that can apply while several ordinary States are active.

Use Any for a truly shared interrupt such as death, stun, or low-health flee. Do not use it as a replacement for every duplicated transition: the destination and Conditions must be valid from all States where the interrupt may occur.

Control re-entry and loops

A self-transition always re-enters its State and restarts its Actions and lifecycle. Can Reenter controls a different case: an Any transition whose destination is already active. Disable that option when the Any transition should leave an already-active destination alone. To avoid restarting work through a self-transition, change its Conditions or remove the self-transition; its re-entry cannot be disabled with Can Reenter.

When a graph loops unexpectedly:

1. Pause Play Mode on the first repeated State.
2. Inspect its outgoing transitions and the live Condition values.
3. Check for a continuously true Condition, an Any transition with Can Reenter enabled, or a self-transition, which always re-enters.
4. Add a state change, cooldown, consumed event, or finishing boundary so the Condition becomes false after use.

Verify in Play Mode

Build a State with two outgoing transitions. Make both Conditions valid deliberately, record which destination wins, then reverse their order and test again. Restore the intended priority and make one Condition false. This controlled test proves the order and evaluation mode before the rules depend on live gameplay data.

Troubleshooting

Related pages

• Conditions
• States
• Any
• Timed State Cycle
• Flee at Low Health
• Debugging