# What Is Flow Core Level: Beginner ## Summary Flow Core is a visual runtime logic system for Unity projects. It lets you build graph-driven behavior from nodes, typed Blackboard data, Entries, Triggers, Instructions, Conditions, and higher-level modules such as Behavior Trees, FSM-style states, Stack layers, GOAP, Flow Character, and Flow Interaction. The first thing Flow Core should teach you is not an API call. It should teach the shape of the workflow: put data in a Blackboard, bind that Blackboard to a `FlowCoreProcess`, start a chain from a visual event, and observe a result in the scene or Console. ## Why It Exists Many Unity gameplay systems begin as code-only logic and then become hard for designers to inspect, tune, or safely change. Flow Core exists to move the editable parts of runtime behavior into a visual graph while keeping data access explicit and typed. It is meant for behavior that benefits from visibility: interaction flows, tutorial steps, state transitions, timed sequences, character animation events, AI decision branches, UI event reactions, and gameplay logic that designers need to review with programmers. Flow Core does not try to remove code from a project. Programmers still own custom APIs, integrations, data types, generated registries, and performance-sensitive systems. Flow Core gives those systems a visual surface that can start chains, read and write data, and call supported extension points. ## Mental Model Think of Flow Core as four cooperating layers: | Layer | What it owns | Example | | ----------------- | ------------------------- | ---------------------------------------------------------------- | | Graph | Structure and flow | A Trigger connects to an Action. | | Blackboard | Typed data | Local key `Say` stores `Hello Flow Core`. | | Process | Runtime binding | A scene GameObject owns `FlowCoreProcess` and Local Blackboards. | | Extension surface | Project-specific behavior | Custom Instructions, Conditions, types, or runtime calls. | A graph does not run by itself. It becomes runtime behavior when a `FlowCoreProcess` builds the graph with its bound Blackboards. A chain starts from an Entry or Trigger, moves through connected branches, checks Guards, runs node behavior, and resolves values from the active runtime context. After the Hello World tutorial, the important lesson is this: the graph is the visible behavior plan, the Blackboard is the data contract, and the process is the scene instance that makes both of them real at runtime. ## Behavior Contract * A Trigger or Entry starts a chain. * A branch is a graph connection from one output to another node. * A Guard can reject a node before that node executes. * Reject Result controls whether rejection is a hard stop or a quiet invalid result. * Invoke Mode controls what happens when a node is already busy. * Blackboard reads and writes use explicit scope, index, key, and type. * A payload belongs to the triggering event or Entry call; it is not the same as Blackboard data. * Debug Context affects editor previews and visual debugging, not runtime graph data. These rules make behavior inspectable. If a chain does not run, you can ask where it starts. If a value is wrong, you can ask which scope and key were read. If a node is skipped, you can inspect Guard and Invoke semantics instead of guessing. ## Design Implications Use Flow Core when the graph itself is part of the design artifact. Branching quest logic, interaction prompts, animation-timed Markers, tutorial flows, and Behavior Tree decisions all benefit from a visible structure. Keep code when the behavior is a dense algorithm, a platform integration, a networking protocol, or a hot loop that is clearer and faster as C#. Flow Core can still call into those systems through supported Instructions, Conditions, or runtime APIs. Prefer Local Blackboard data for first implementations. It keeps ownership close to the `FlowCoreProcess`, makes Debug Context easier to reason about, and reduces accidental coupling. Move data to Scene or Global scope only when the sharing requirement is real. ## Common Misunderstandings * Flow Core does not replace all C# code. It gives project code a visual behavior layer. * Flow Core does not automatically convert arbitrary values. Data paths stay typed and explicit. * A Trigger is not an Entry. Triggers respond to events; Entries are named start points that can be called. * A payload is not persistent state. Use Blackboard data when later nodes need to read the value again. * Subgraph Triggers do not run globally. They run within the subgraph activation window. * Debug Context does not fix runtime data. It only tells the editor which process to preview. ## Related * [Start Here](/flow-core-docs/documentation/getting-started/start-here.md) * [First 15 Minutes](/flow-core-docs/documentation/tutorials/first-15-minutes.md) * [Concepts Overview](/flow-core-docs/documentation/core-concepts/concepts-overview.md) * [Design Levers](/flow-core-docs/documentation/core-concepts/design-levers.md) * [Terminology](/flow-core-docs/documentation/reference/terminology.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://flow-core.gitbook.io/flow-core-docs/documentation/core-concepts/what-is-flow-core.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.