Skip to main content
Flow Core Documentation
Menu

Overview

Gameplay Module Architecture

Combine Flow Core gameplay modules without giving several systems ownership of the same decision.

Audience
System designers and developers
Time
10 minutes
Requires
Flow Core in Five Concepts
Modules
Flow Core Gameplay
On this page

Flow Core gameplay modules provide focused runtime surfaces for common game systems. Use normal Flow to orchestrate them, typed data to communicate, and one module to own each gameplay responsibility.

Module map

ModuleOwnsDoes not decide for you
Flow CharacterMovement, facing, animation States, Gestures, Markers, and configured IKCombat rules, inventory, dialogue, or networking
Flow CameraCamera Shots, Channels, priority selection, transitions, and lens controlCinematic timeline, rendering pipeline, or input policy
Flow InteractionCandidate scanning, focus, blur, and interaction routingInventory result, quest result, dialogue content, or input binding
Flow StatsStat calculation, Resource values, Status Effect lifecycle, and Stats eventsCharacter control or general Blackboard ownership

Each module can expose Instructions, Conditions, Triggers, event graphs, or runtime APIs. That does not mean every behavior belongs inside the module. Keep project-specific consequences in the graph or system that owns them.

Compose through explicit handoffs

An interactable healing shrine can use four owners:

  1. Flow Interaction decides which shrine is focused and raises Interact.
  2. Normal Flow sequences prompt feedback, character Gesture, and timing.
  3. A Marker identifies the hand-contact moment.
  4. Flow Stats changes the Health Resource or applies a Status Effect.
  5. Flow Camera briefly activates a feedback Shot.
flowchart LR I["Flow Interaction"] --> F["Flow sequence"] C["Flow Character Marker"] --> F F --> S["Flow Stats"] F --> K["Flow Camera"] B["Blackboard facts"] --> F

No module needs to know every detail. Interaction owns target intent, Character owns animation timing, Stats owns numeric state, Camera owns shot selection, and Flow owns the visible sequence.

Video · 2:02Flow Character and Flow InteractionSee character behavior and interaction routing cooperate in one observable slice.

Open video in a new tab

Data boundaries

Use the narrowest channel that preserves ownership:

  • Pass event-specific objects through payload.
  • Use TempPayload for intermediate results in the current chain.
  • Store shared or persistent facts in typed Blackboards.
  • Use a module’s own runtime state for values it natively owns.
  • Use supported Instructions or runtime APIs rather than rewriting module internals.

Flow Stats is intentionally able to operate as a standalone component. Do not add FlowCoreProcess or Blackboard only because a Stats owner exists; add them when an authored graph path actually requires them.

Build one observable slice

When introducing a module, validate one end-to-end result before combining modules. For Camera, switch between two Shots. For Interaction, focus and use one Target. For Character, enter one State and play one Gesture. For Stats, change one Resource and observe the Debug view.