Graph Authoring
Nodes, Ports & Execution Chains
Read authored topology separately from runtime execution.
- Audience
- All developers
- Time
- 8 minutes
- Requires
- A Flow Graph open in the editor
- Modules
- Flow Core
On this page
Read a Flow Graph as authored routes that runtime chains can travel. Nodes define behavior, ports define compatible flow boundaries, branches define topology, and chains describe what is executing now.
Node responsibilities
A node is a visible graph unit with flow ports, settings, behavior, and optional Guard logic. Different node kinds own different responsibilities:
- Trigger and Enter nodes start chains.
- Action nodes run ordered Instruction lists.
- If/Else, Switch, Gate, and similar nodes choose routes.
- Wait, Delay, Retry, Loop, and timer nodes control timing or repetition.
- Module nodes provide FSM, Behavior Tree, Stack, or GOAP behavior.
An Instruction is not a graph node. It is an executable operation inside an Action-style list or another supported host.
Ports and branches
An input port receives execution. An output port continues execution. Connecting an output to an input creates a branch in the graph’s static topology.
Use branch for the authored route: “The Success branch connects to the reward Action.” Do not call the running execution a branch.
Execution chains
A Trigger or Entry starts a chain. The chain moves through connected nodes until it completes, aborts, becomes invalid, waits, or starts another supported execution boundary.
Several chains can exist in one process. Busy-node behavior and module semantics decide whether repeated execution queues, bypasses, cancels, or proceeds independently.
此处插图应该是 Flow Graph Editor 中一条包含 Trigger、If Else、两个 Action 和 Wait 的示例路径截图；静态连接标注为 Branch，运行高亮路径标注为 Chain，并用不同颜色区分。
Read a route
For any visible behavior, answer these questions:
- Which Trigger or Entry starts the chain?
- Which output port does it use?
- Which node receives that output?
- Can a Guard reject that node?
- Which result or output continues the chain?
- Where is the observable result?
Design implications
- Give a node one readable purpose.
- Prefer visible handoffs between systems over hidden side effects.
- Put ordered operations in one Action only while they form one coherent step.
- Name important Entries, roots, states, and comments by responsibility.
- Add a visible verification result before adding more branches.
Common misunderstandings
| Misunderstanding | Correction |
|---|---|
| Every line is currently running | Connections exist at authoring time; runtime visualization shows active chains. |
| Every operation needs a node | An Action can execute a focused sequence of Instructions. |
| An unconnected node runs automatically | A runtime path must reach it through its supported start or control boundary. |
| Visual left-to-right placement alone controls behavior | Connections, child order, and node settings control behavior. |