FlowGraph Fundamentals

🧠

Guide

Read a behavior graph as one gameplay rule: when this timing arrives, execute these actions with these targets and values

The diagram below is the FlowGraph for Poison Arrow, a card from the Demo. From left to right, On Card Played opens the path, Deal Damage applies damage, presentation nodes read the actual result, and Change Status applies Poison.

Behavior is embedded in its host

FlowGraph is embedded directly in the content where the player experiences its result. You do not need to create or assign a separate graph asset.

Owner	Rule expressed by Behavior	Common starting point
Card	What happens when the card is played or reaches another lifecycle timing	On Card Played, another Card Entry, or a Hook
Status	The reactions, persistent rules, and pending value modifications contributed by the status	A Battle or Status Entry, or a Hook
Enemy	How the enemy chooses an Intent and what that Intent actually executes	On Enemy Behavior Start and an Intent Pattern

Logical trigger timing

Every executable path starts with the timing type required by the rule it expresses.

Starting point	Use	Example
Entry	React when a documented battle or content lifecycle point is reached	Apply Poison after a card is played, or trigger a status at turn start
Hook	Modify or cancel a value before GCS commits it	Increase outgoing damage, change the number of cards drawn, or reject a card play
Intent Pattern	Choose and preview the action an enemy will execute	Select a Leaf Intent from a Sequence or Weighted Pattern

warning

Timing belongs to the mechanic itself. A rule that runs "at turn end" must connect to the matching turn-end Entry, not another Entry that happens near the same time.

Entry Nodes and Hook Nodes document the exact availability and timing. Battle Phases and Execution Order places them in the complete battle lifecycle.

Control flow and data flow

Control connections answer "what executes next," while data connections answer "which target or value does this step use."

Connection	Responsibility	Common form
Control flow	Orders the execution of Action, Branch, Loop, Wait, Choice, and Intent paths	Out / In, True / False, Body / Done, or a named Case
Data flow	Supplies units, cards, collections, numbers, booleans, text, and actual results	A Source or Result Output connected to a Consumer Input

Dynamic parameter ports

Some node fields support dynamic parameters and can be switched directly to an Input Port that receives a runtime value.

Connected Input   -> Pull the runtime value
Unconnected Input -> Use the value saved in the field

tip

Use fixed design values for constants such as Amount = 6. Expand a dynamic port only when the value must be calculated from current armor, missing HP, Hook input, or other live state.

FlowGraph Editor explains the Socket toggle, port layout, and connection workflow.

Lazy evaluation

Data does not broadcast or travel across the whole graph ahead of time. Only when an Action node begins execution does it pull the data it currently needs from the connected Producer.

This rule produces four direct authoring results:

• Timing sensitivity: Get nodes read the current battle state, so reading HP after damage returns the reduced value.
• Live calculation: Operators and Selectors calculate from the live inputs present when the Consumer pulls them.
• Stable single evaluation: A Source Result stays stable within one evaluation cycle, while a later Action or Loop iteration can generate a new value.
• Snapshot storage: When several later Actions need the same snapshot, store the value in a Graph or Battle Variable.

The role of runtime context

The same logic nodes can be reused across Cards, Statuses, and Enemies because runtime context injects the current actor, current target, and live battle data when a node executes.

Runtime data need	Value source
Current card	This Card or an Entry Output
Current actor or owner	Self Unit, Active Unit, or an Entry Output
Target unit selected by the player or calculated by logic	Card Selection, Source Dropdown, or a connected Selector
Live attributes such as HP, armor, energy, turn number, piles, and status stacks	Get nodes that read the live battle
Attribute or status changes	Action nodes executed through the Context Controller
Parameters supplied by an event or Hook	Output from the matching Hook or Event Entry

Context gives Self a dynamic identity. In a card, Self is the player who plays it. In a Status, it is the unit carrying that Buff. In enemy behavior, it is the current enemy entity. Target Selection defines the Source rules and the priority of a connected Target Port.

Value transfer and data scopes

Choose a value-transfer method according to how widely a value must be shared and how long it must be retained.

Value surface	When to use it
Direct connection	Only one downstream node needs the current value
Actual resolved result	Later logic or presentation depends on the value that actually took effect after armor reduction, Hook interception, attribute limits, and target validation
Graph Variable	Several paths in the current Graph Run need to share one snapshot
Battle Variable	The value must persist across an Entry, Card, or Turn boundary
Internal Event	Different content owners need to exchange data without a direct asset reference

warning

• UI feedback for damage, healing, and similar results must read the resolved Output first, such as Dealt, Changed, Drawn, or Added.
• Never pull the raw input node directly. Armor reduction, Status Hooks, attribute limits, and target validation can change the value during resolution or prevent the action from taking effect at all.
• Reading the input directly can make presentation such as floating text disagree with the actual health-bar change.

Separate configuration from logic

Keep data configuration separate from connection logic so nodes remain reusable. Use this division:

Keep on the content asset	Put in FlowGraph
Name, description, cost, type, rarity, tags, art, Target, stacking rules, unit attributes, and Encounter Rules	Damage, healing, armor, card movement, status reactions, Hooks, enemy actions, Choice, Wait, Event, and presentation requests

tip

• Separate presentation from assets: Presentation nodes in FlowGraph only issue playback requests. The particles, audio clips, Prefabs, materials, and mixers they reference remain static presentation assets and should not be hard-coded into logic.
• Targeting logic: The Target field on the Card asset defines the interaction used when the player drags and plays the card. Graph Source in FlowGraph defines which units an Action such as damage actually resolves as targets.

Open and connect a Behavior in FlowGraph Editor, use the Node Reference for exact ports and parameters, or start from a verified combination in Card Recipes, Status Recipes, or Enemy Recipes.