[Unity] Game Creator 2 Behavior — FSM, Behavior Tree, GOAP & Utility AI

Thank you for visiting this site.

This article provides a detailed guide to “Behavior”, one of Game Creator 2’s modules — the AI control system.

Behavior is an integrated AI module that handles four industry-standard AI methods — State Machine (FSM) / Behavior Tree / GOAP / Utility AI — on a single Processor component.

Official documentation: Game Creator 2 Documentation

You can find a complete list of all articles in this series here:

Complete Article List — Game Creator 2 Complete Guide Series Indexen.senkohome.com/gamecreator2-series-index/

---

What is Behavior?

The Processor component drives AI by assigning one of four types of Graph assets:

• State Machine: Finite state machine. The simplest
• Behavior Tree: Top-to-bottom, left-to-right priority tree. Flexibility and readability
• GOAP: Goal-Oriented Action Planning. Automatically builds Plans from Requisites and Effects
• Utility AI: Needs-oriented. Selects the task with the highest need score

---

Installation

1. Purchase the Behavior module from the Asset Store
2. Install via Window > Package Manager
3. 4 samples from Game Creator > Install...:
   • State Machine: Patrolling guard (simplest)
   • Behavior Tree: Hide and seek with the player
   • GOAP: NPCs cooperating to gather firewood
   • Utility AI: Dance club — choosing between dancing/drinking/going home by needs
4. Install location: Assets/Plugins/GameCreator/Installs/Behavior.<method>/

---

Processor Component and Graph

Processor

The central component for AI execution. Not limited to Characters — can be attached to any GameObject.

• Graph: Specify one of State Machine / Behavior Tree / Action Plan (GOAP) / Utility Board assets
• Loop: Whether to re-execute when the graph finishes
• Update:
  • Every Frame
  • Manual (via script/Instruction)
  • Custom Interval (seconds specified by dynamic property)
• Blackboard parameters are automatically expanded in the fields below

Common Graph Window Elements

• Top left: Focus / grid display toggle
• Top right: Show/hide various sub-windows
• Bottom: Breadcrumbs for the opened graph (return to parent while editing a sub-graph)

Runtime Constraints

• Blackboard parameters can be changed at runtime
• Graph assets themselves cannot be swapped during Play mode

---

Blackboard (Parameters)

Purpose

A variable space for interfacing “values that differ per agent” to the graph. Used for patrol routes, target enemies, etc.

Creation

Enter a name in the Graph’s Blackboard section → Enter (or + button). Click the type icon to select a type (Game Object / Number / Boolean, etc.).

Synchronization

After adding/editing parameters, you need to refresh and re-sync the Processors using that graph.

Reading and Writing Parameters

Set values in the fields automatically displayed on the Processor. A Behavior section is added to each Property dropdown, allowing parameter value reference/setting.

---

State Machine (FSM)

Concept

Only one State is Active at a time. That State can only transition to other States it’s connected to.

Node Types

Enter (Fixed, 1 per graph)

The root that determines the initial State.

Exit (Optional)

Treats the graph as “finished.” When used as a sub-graph, it means “return to the outer graph.”

State (Main)

• Name: For identification (no effect on execution)
• Conditions: Conditions for entering this State (transition fails if not met)
• Check:
  • Every Cycle: Check transitions after On Update completes (recommended)
  • Every Frame: Check transitions every frame (slight performance cost)
• On Enter: The moment of transitioning in
• On Exit: The moment of transitioning out
• On Update: Instruction sequence executed repeatedly while active (restarts after completion if State continues)

Place initialization in On Enter and cleanup in On Exit. On Update can be interrupted, so there’s no guarantee it will complete.

Conditions (Relay Node)

For consolidating conditions in one place when multiple States converge on the same exit with the same condition.

Sub Graph

Executes any Graph (not limited to State Machine) as a State.

Elbows (For Layout)

Bend nodes for connection lines. No functionality — purely for readability.

Transition Evaluation Order

Selecting a State node shows the transition order in the Inspector. Conditions are tested from top to bottom, transitioning to the first one that succeeds. If all fail, the current State continues.

---

Behavior Tree

Concept

A tree structure rooted at the Entry node. Evaluated top-to-bottom, left-to-right. Three return values:

• Success: Succeeded
• Failure: Failed (not an error — means “this path didn’t work”)
• Running: In progress

There’s also a Ready state (not yet executed). Nodes that have already Succeeded are not re-executed until the entire tree finishes with Success/Failure (state is preserved).

Node Types

Task (Leaf)

• Conditions: Executed on each evaluation. If false during Instructions execution → Failure
• During Instructions execution: Running; on completion: Success

Composite (Branching)

• Selector: Executes left to right; if any child Succeeds, self also Succeeds (OR). All Failure → Failure
• Sequence: Executes left to right; if any child Fails, self also Fails (AND). All Success → Success
• Parallel: Executes all children simultaneously. Success/failure judgment options: “All Successful,” “Any Successful,” etc.
• Random Sequence: Same as Sequence but randomizes order before evaluation
• Random Selector: Same as Selector but randomizes order before evaluation

Decorator (Modifier)

Relay nodes that transform child results:

• Fail: Always Failure
• Success: Always Success
• Running: Always Running
• Invert: Flip Failure ↔ Success; Running is preserved
• Repeat: Execute child up to specified times (Running during, child’s result at the end)
• While Fail: Running while child is Running or Failure; otherwise Failure
• While Success: Running while child is Running or Success; otherwise Failure

Sub Graph

A Task-like node that executes another Behavior Tree / State Machine / GOAP.

Child Order

Numbers (1, 2, …) appear above Composite child nodes. Auto-calculated left-to-right, so drag to rearrange and set priority.

---

GOAP (Goal Oriented Action Planning)

Concept

Agents have “Beliefs” (current worldview), and the AI automatically constructs a “Plan” (sequence of nodes) to reach a “Goal” (desired set of Beliefs).

• Plan: An ordered sequence of nodes
• Beliefs: Current set of Beliefs (a set of booleans)
• Requisites: Prerequisites for node execution (required ON Beliefs)
• Effects: Beliefs rewritten after node execution
• Cost: Node execution cost. The Plan with the minimum total Cost is selected

Example: Set be-in-hotel as the Goal. Node A (Requisite: be-in-restaurant → Effect: be-in-hotel) and Node B (Effect: be-in-restaurant) → Plan becomes B → A.

Thoughts (Initial Beliefs)

You can set initial Beliefs at Plan calculation start via Add Thought in the Action Plan asset. You can link Visual Scripting Conditions to supply boolean values (e.g., can the player be seen?).

Node Types

Task

• Name: For identification
• Cost: Weight for plan selection (lower values are preferred)
• Conditions: Runtime execution feasibility check (separate from Beliefs)
• On Execute: Instructions. After execution, the node is considered complete

Important: Conditions are NOT used during Plan construction. They only serve to abort during execution. Values you want as Plan prerequisites should go in Beliefs (Requisites).

Sub Graph

Like a Task, but delegates to another AI graph (State Machine / Behavior Tree, etc.).

Requisites and Effects Nodes

Connect Requisites to the left side and Effects to the right side of Tasks/Sub Graphs. Specify True/False for each Belief.

• Placing False means “this Belief does not exist” (default)

Goal Management (Runtime)

• Add Goal Instruction to add a Goal: Processor / Action Plan / Name (Belief name) / Weight
• Remove Goal Instruction to remove
• Multiple Goals can be held simultaneously
• Each Goal’s Plan total Cost is multiplied by Weight, and the minimum is selected

Weight Prioritization Example

• Stay-Alive (Cost 5) / Kill-Enemies (Cost 3)
• Without adjustment, Kill would be selected
• Setting Stay-Alive’s Weight = 0.5 makes its total Cost = 2.5, prioritizing Stay-Alive

Execution Flow

1. Construct one Plan (minimum Cost) for each Goal
2. Multiply all Plans by Weight and compare
3. Select the minimum total Cost and begin execution
4. Execute to completion unless aborted by Conditions
5. New Plans are not calculated during Plan execution

---

Utility AI (Needs-Based AI)

Concept

Each “Need” has a Score and Curve, and the Need with the highest Score is selected and executed each time. Suited for The Sims-style games.

Utility Board

• A graph where all nodes are “arranged without connections”
• Each time: Get all nodes’ Values → Apply Curves → Execute the highest Need

Node Types

Task

• Name: For identification
• Score: Value (supplied via dynamic property) + Curve
• Conditions: Feasibility check. Excluded from candidates if not met
• On Execute: On execution start
• On Exit: On end (always called even on interruption. For state reset)

Sub Graph

Same as Task, but delegates to another AI graph.

Curve (Demand Curve)

A function that customizes how Values are handled. Four representative patterns:

• Linear: Value as-is
• Inverse Linear: Inverted (higher value = lower Score)
• Smooth Easing: Gradually accelerating rise
• Belly / Bell: High in the center, low at both ends (for idle behaviors, etc.)

Value Range

Default is 0–1. Extendable via the Utility Board asset’s Minimum/Maximum. Curves are always defined from 0–1 and finally remapped to Min–Max.

Selection and Execution

• Calculate all nodes’ Scores and execute the maximum
• No re-selection until the executing node completes. To prevent getting stuck, include early termination logic in On Execute if needed
• During Play mode, calculation results are displayed on nodes for debugging

---

Choosing the Right Method

Hybrid configurations like Behavior Tree × Utility AI are also possible (delegate each Utility Need to a Behavior Tree sub-graph). GOAP Tasks can also delegate to Behavior Trees, etc.

---

Visual Scripting Reference

Instructions (3)

Behavior (1)

Behavior > Action Plan (2)

Conditions (1)

Events (2)

Behavior is designed to be mostly self-contained within graphs, so the number of Instructions/Conditions/Events is smaller compared to core Visual Scripting nodes. The primary usage pattern is writing Instructions directly in Task/State nodes within the graph.

---

Tips and Notes

• Initialization in On Enter / cleanup in On Exit is the golden rule. On Update can be interrupted
• State’s Every Frame is heavy: Use only where immediate response is truly needed. Every Cycle is sufficient for most cases
• Behavior Tree node states are preserved: Succeeded nodes are not re-evaluated. For looping, use Repeat decorators or maintain Running state
• Difference between GOAP Conditions and Beliefs: Beliefs (Requisites/Effects) are involved in plan construction; Conditions are for runtime interruption only. Don’t confuse them
• Set initial values with Thoughts: They form the basis for Plan calculation. Plans can’t be built with missing Beliefs
• Utility AI doesn’t re-select until completion: Avoid infinite loops or overly long Tasks; keep granularity at a level where Curves can trigger switching
• Graphs cannot be swapped at runtime: Design with sub-graph switching if needed
• Refresh after Blackboard changes: The Processor’s display may operate on stale data
• Excellent synergy with Perception: The standard pattern is to inject Sight/Hearing Awareness into Conditions or Beliefs
• Breakpoint/Disabled display (v2.1.5+): Instructions and conditions in nodes show visual breakpoint and disable indicators

---

Practical Usage — Configuration Guide by Goal

A summary of which method and configuration to use when you want to achieve a specific AI behavior.

Basic patrol → detect player → chase AI (State Machine)

A guard patrols an area, chases the player when spotted, and returns to patrolling when the player is lost.

Give each agent an individual patrol route (Blackboard)

Share the same AI graph among multiple guards while setting patrol routes individually.

AI that evaluates multiple conditions with priority (Behavior Tree)

Select actions with left-to-right priority: “Can attack?” → “Can chase?” → “Patrol”

The leftmost has the highest priority, and the first Task whose conditions are met is executed.

Sequential actions that fail if any step fails (Sequence)

Execute “approach enemy → attack → retreat” in order. If any step fails, the whole sequence fails.

AI that automatically plans actions (GOAP)

An NPC automatically plans the necessary actions (gather wood → find kindling → ignite) to achieve the goal of “building a campfire.”

Needs-based autonomous NPC (Utility AI)

NPCs automatically select the action with the highest score based on “hunger,” “fatigue,” “social need,” etc.

The Need with the maximum score is selected, and no re-selection occurs until completion.

Embed a Behavior Tree inside a State Machine (Sub Graph)

Manage broad state transitions with FSM, but implement complex inner logic of each state with BT.

The reverse — calling State Machine or GOAP as a BT task — is also possible.

Reduce AI update frequency to improve performance

Lighten AI processing in scenes with many NPCs.

For Manual, use the Processor Update instruction to execute at arbitrary timing.

---

Related Modules

• Characters: Control Players/NPCs as targets
• Perception: Incorporate visual, auditory, and olfactory Awareness into Conditions/Beliefs
• Stats: Decisions based on HP, etc. (add Compare Attribute to State Conditions)
• Quests: Activate AI graphs or add Goals on specific Task completion
• Visual Scripting: Node Instructions can use all core Visual Scripting Instructions

---

Official Links

• Game Creator 2 Official Documentation
• Game Creator 2 — Unity Asset Store
• Behavior 2 | Game Creator 2 — Unity Asset Store

---

Summary

This article covered the “Behavior” module for Game Creator 2.

Four AI methods (State Machine, Behavior Tree, GOAP, and Utility AI) can be used within the same framework, and hybrid configurations via Sub Graphs are also possible. The Processor and Blackboard system makes it easy to share a single AI graph among multiple agents while injecting individual parameters.

Visual Scripting provides 3 Instructions, 1 Condition, and 2 Events, but the primary logic is designed to be written directly in nodes within the graph.

Complete Article List — Game Creator 2 Complete Guide Series Indexen.senkohome.com/gamecreator2-series-index/

We hope you’ll continue reading our next article as well.