Skip to main content
Flow Core Documentation
Menu

Build a Working Result

Choose Your Next Path

Select the Flow Core capability that matches the system you need to build.

Audience
All developers
Time
3 minutes
Requires
One completed Flow or equivalent experience
Modules
Flow Core
On this page

After building one visible Flow, choose the next section by ownership problem rather than reading every page in order. The best model is the one that makes responsibility and runtime behavior clear.

Choose by gameplay need

You need to…Continue with…Why
Sequence events, waits, and side effectsNodes, Ports & Execution ChainsNormal Flow makes “what happens next” visible.
Represent a long-lived modeState-Driven Logic with FSMFSM makes active state and transitions explicit.
Re-evaluate prioritized choicesHierarchical Behaviors with Behavior TreesA Behavior Tree owns selection order and repeated decisions.
Cover and later restore a modeComposing Logic with StacksStack provides push, pause, pop, and resume semantics.
Search for actions that reach a goalGoal Planning with GOAPGOAP plans from facts, preconditions, effects, and costs.
Build player or NPC movement and animationCharacter Control with Flow CharacterFlow Character connects movement, States, Gestures, Markers, and graph control.
Author camera composition and changesCamera Authoring with Flow CameraCamera Shots and Channels separate authored shots from selection.
Create object targeting and interaction eventsInteraction Design with Flow InteractionOwner and Target roles keep selection and response separate.
Model attributes, resources, buffs, or debuffsStats and Effects with Flow StatsStats, Resources, and Status Effects have distinct runtime ownership.
Start or extend graphs from codeRunning Graphs from C#Supported process APIs connect existing gameplay code to visual behavior.

Choose the smallest owner

Do not begin with the most advanced module. Begin with the smallest model that owns the behavior cleanly:

  • Use a normal Flow for one event-driven sequence.
  • Add an FSM only when a state persists and controls what may happen.
  • Add a Behavior Tree only when priority must be reconsidered.
  • Use Stack when last-in, first-out restoration is the rule.
  • Use GOAP when the route to a goal should be planned rather than authored directly.
flowchart TD A["What changes at runtime?"] --> B{"A visible sequence?"} B -->|Yes| C["Flow"] B -->|No| D{"One persistent mode?"} D -->|Yes| E["FSM"] D -->|No| F{"Repeated priority choice?"} F -->|Yes| G["Behavior Tree"] F -->|No| H{"Temporary covering layer?"} H -->|Yes| I["Stack"] H -->|No| J["GOAP or a gameplay module"]

Keep these pages nearby