Branching, Guards & Execution

Flow Core separates route selection, pre-execution checks, and busy-node behavior. Keeping those decisions distinct makes failures and repeated events easier to explain.

Branching chooses a route

Use a branching node when the graph should visibly select between outputs. If/Else, Switch, Gate, selectors, and module-specific result ports make different decisions, but each exposes the route in graph topology.

Name or arrange the downstream paths so their results are obvious. A branch should lead to an observable responsibility, not disappear into unrelated work.

Guards decide whether a node may execute

A Guard is a Condition group evaluated before the node performs its behavior. Conditions answer pass or fail; they should not perform gameplay side effects.

When a Guard rejects execution, Reject Result controls how the chain interprets that rejection. Use the configured Invalid or Abort behavior deliberately:

• Invalid is useful when rejection is an expected non-result that surrounding logic can handle.
• Abort is useful when the rejection should terminate the active route visibly.

此处插图应该是带 Guard 的 Action 节点及其前后路径截图；展开 Guard Conditions 与 Reject Result，并用标注展示 Guard 通过和拒绝时的两种运行结果。

Invoke Mode handles repeated execution

A node may receive another chain while it is already running. Invoke Mode defines what happens in that busy state, such as queuing required work, bypassing a repeat, or returning a terminating result.

Choose based on gameplay ownership:

Requirement	Typical intent
Every request must execute in order	Queue the work and monitor backlog.
Only the latest or first visible response matters	Bypass or reject repeated work.
New work should cancel the previous route	Use the supported abort behavior at the correct boundary.

Exact options depend on the node kind. Confirm behavior in Play Mode rather than assuming every node handles busy execution identically.

Pass Enabled and control inputs

Nodes with supported control inputs can maintain a Pass Enabled gate. Disabling pass prevents normal incoming execution without rewriting the node’s authored Enabled flag. Control behavior is part of the node contract, not a substitute for arbitrary graph mutation.

Design implications

• Use a branch when the route itself should be readable.
• Use a Guard when the same node behavior has a clear precondition.
• Use an Instruction-level check only when the decision belongs inside that ordered operation list.
• Select Invoke Mode according to event frequency and whether requests may be dropped.
• Test Guard rejection and repeated events, not only the success path.

Common misunderstandings

• Guard rejection and busy-node invocation are different decisions.
• Disable control does not necessarily cancel work already running.
• Queue can create delayed bursts when a high-frequency Trigger reaches slow work.
• A Condition should report a decision, not mutate gameplay state to make itself pass.

Related

• Nodes, Ports & Execution Chains
• Debugging Running Graphs
• Hierarchical Behaviors with Behavior Trees