Skip to content

Behavior Trees and Blackboards for Blueprint Beginners

A Behavior Tree chooses what an AI should try next. A Blackboard stores the facts the tree reads while making that choice.

At a glance

Use this for: patrol/chase/search/attack logic that has outgrown one sensing event and one AI Move To call - Main pieces: AIController, controlled pawn, Behavior Tree, Blackboard, tasks, decorators, services, and perception updates - Beginner rule: perception updates facts; the tree chooses behavior; tasks perform actions - Official docs: Behavior Trees, Behavior Tree Overview, and Behavior Tree Quick Start Guide

The one-minute version

  • A Behavior Tree is an AI decision graph run by an AIController. It is not the enemy's body, mesh, movement component, or animation graph.
  • A Blackboard is the AI's shared memory for the tree: target actor, last known location, can see player, patrol point, attack range, and similar facts.
  • The AIController normally starts the tree and owns perception/decision setup. The pawn/character owns the body: movement component, mesh, health, attacks, animation, and collision.
  • Composites choose flow. A Selector tries child branches by priority. A Sequence runs child nodes in order until one fails.
  • A Task performs work, such as Move To, Wait, set a value, or call a custom pawn function.
  • A Decorator gates whether a branch is allowed to run. A Service updates blackboard facts while a branch is active.
  • Behavior Trees are not just giant Tick graphs. Unreal's Behavior Trees can react to blackboard/event changes and services can run at intervals.

The relationship

flowchart LR
    Sensing[Pawn Sensing or AI Perception] --> Controller[AIController]
    Controller --> Blackboard[Blackboard keys]
    Controller --> Tree[Behavior Tree]
    Tree --> Task[Tasks]
    Task --> Pawn[Controlled Pawn / Character]
    Pawn --> Movement[Movement, attacks, animation, health]

The clean first-enemy split is:

Piece Beginner job
AIController Starts the tree, owns AI perception, sets blackboard keys, issues movement through AI systems.
Blackboard Stores facts the tree can read: target, location, booleans, floats, enums, objects.
Behavior Tree Chooses which branch should run right now.
Task Performs one action and reports success, failure, or running.
Decorator Allows, blocks, or aborts a branch based on a condition.
Service Updates facts while a branch is active, usually on an interval.
Pawn / Character The body that moves, animates, attacks, takes damage, and owns components.

Sensing tells the AI something happened. The Behavior Tree decides what that means.

What the Behavior Tree does

A tree organizes choices.

For a first enemy:

Root
-> Selector
   -> Sequence ChaseAndAttack
      Decorator: TargetActor is set
      -> Move To TargetActor
      -> Task AttackTarget
   -> Sequence Patrol
      -> Task ChooseNextPatrolPoint
      -> Move To PatrolLocation
      -> Wait

The tree answers:

  • Should I chase?
  • Should I attack?
  • Should I search the last known location?
  • Should I patrol?
  • Which action is currently running?

The tree should not be a pile of unrelated gameplay implementation. If a melee attack needs to play an animation, open a damage window, and apply damage, the task can call a pawn function such as TryMeleeAttack. The pawn or combat component can own the attack details.

What the Blackboard does

A Blackboard is key-value memory for AI logic. It is not a database and not a replacement for every variable in the pawn.

Common first-enemy keys:

Key Type Meaning
TargetActor Object, often Actor or Pawn base class The actor this AI currently cares about.
LastKnownLocation Vector Where the target was last seen or heard.
HomeLocation Vector Where this AI started or should return after search.
PatrolLocation Vector The current patrol destination.
HasLineOfSight Bool A recent sensing/perception fact.
AttackRange Float Tunable range for attack checks.
AIState Enum or Name Optional high-level state such as Patrol/Search/Combat.

Perception updates keys:

AI Perception sees player
-> Set Blackboard Value as Object TargetActor = Player
-> Set Blackboard Value as Bool HasLineOfSight = true
-> Set Blackboard Value as Vector LastKnownLocation = Player location

The tree reads keys:

Decorator: TargetActor is set
-> branch is allowed to chase

When the target is lost:

AI Perception loses player
-> Set HasLineOfSight false
-> maybe keep TargetActor for a short search
-> maybe clear TargetActor when search expires

The Blackboard stores facts the AI can reason from. It does not decide the behavior by itself.

Selector, Sequence, branch, and priority

A branch is a subtree under a composite node.

A Selector is a priority choice:

Selector
-> Attack branch
-> Chase branch
-> Search branch
-> Patrol branch

It tries children in order and uses the first one that can run or succeeds, depending on the active child and result. Put more urgent behavior earlier: attack before chase, chase before patrol.

A Sequence is a checklist:

Sequence ChaseTarget
-> Decorator: TargetActor is set
-> Move To TargetActor
-> Face Target
-> Attack

If an earlier required step fails, the sequence fails. That makes it good for "all of these must be true/doable."

Beginner rule:

  • use a Selector when the AI should choose one of several alternatives;
  • use a Sequence when the AI should do several required steps in order.

Tasks

Tasks are leaf nodes that do work.

Built-in examples:

  • Move To;
  • Wait;
  • Run EQS Query;
  • Set Blackboard Value.

Beginner custom examples:

  • choose next patrol point;
  • start attack on the pawn;
  • clear target after search;
  • play alert bark;
  • rotate toward target.

A task must eventually report its result. In Blueprint behavior tree tasks, that means calling Finish Execute with success or failure unless the task is designed to stay running and finish later.

This is a common broken task:

Event Receive Execute AI
-> call something
// never calls Finish Execute

The tree can look stuck because the task never told it what happened.

When a task needs the enemy body:

Event Receive Execute AI
-> Controlled Pawn
-> Cast/Interface to enemy character
-> call TryMeleeAttack
-> Finish Execute with the result

Prefer calling a pawn/component function over reaching into the pawn's mesh, movement, animation, and damage variables from every task.

Decorators

Decorators are branch conditions.

Examples:

TargetActor is set
HasLineOfSight is true
DistanceToTarget <= AttackRange
AmmoCount > 0
HealthPercent <= 0.3

Decorators belong on the branch they guard. That makes the graph readable:

Attack branch
    Decorator: TargetActor is set
    Decorator: InAttackRange is true
    Task: Attack

Decorators can also observe blackboard keys and abort running branches when the condition changes. That is what makes a patrol branch stop quickly when the AI gets a target, or a chase branch stop when the target is cleared.

Do not hide every condition inside custom tasks. If a branch should visibly depend on a key, put that condition where the tree can show and debug it.

Services

Services are update helpers attached to a composite or task branch. They run while that part of the tree is active, usually at an interval.

Good service jobs:

  • update DistanceToTarget;
  • refresh HasLineOfSight;
  • choose whether target is in attack range;
  • update a last known location;
  • sample a nearby patrol/search point.

Poor service jobs:

  • every-frame gameplay implementation that belongs in the pawn;
  • spawning actors repeatedly;
  • saving/loading;
  • direct UI work;
  • expensive world searches without an interval or clear need.

Services are useful because they make "update this fact while chasing" local to the chase branch. They are still logic you pay for. Use intervals and keep them focused.

Why this is not just Tick

A beginner can make an enemy with Tick:

Every Tick
-> if can see player and close enough: attack
-> else if can see player: AI Move To player
-> else patrol

That works for a tiny prototype, but the concrete cost is that every decision, memory rule, move request, and attack gate becomes mixed in one constantly running graph. Adding "search last known location" or "abort patrol when target appears" gets messy fast.

Behavior Trees keep the decision structure visible:

Blackboard changed: TargetActor set
-> decorators reevaluate branches
-> high-priority chase branch can become eligible

Services can update at deliberate intervals. Tasks run when selected. The tree shows which branch is active in the debugger. That is the improvement: not "AI magic," but clearer ownership and debuggable flow.

What still belongs in the AIController

The AIController is the brain object that controls the pawn. Good AIController jobs:

  • start the Behavior Tree;
  • own AIPerceptionComponent;
  • receive perception events;
  • set blackboard keys from perception;
  • issue or support AI movement/path-following;
  • keep controller-level AI references;
  • stop/restart AI logic when possession changes.

Example:

BP_EnemyAIController
-> On Possess
   -> Run Behavior Tree BT_Enemy

-> On Target Perception Updated
   -> if player sensed:
          Set Blackboard TargetActor
          Set Blackboard LastKnownLocation
      else:
          Set HasLineOfSight false

This keeps sensing and blackboard wiring close to the controller that owns the tree.

What still belongs in the pawn

The pawn or character is the body. Good pawn/component jobs:

  • movement component and movement tuning;
  • mesh and animation;
  • health/damage/death;
  • attack functions and hit detection;
  • equipment references;
  • collision setup;
  • actor tags/components that define what the body is.

Example:

BTTask_AttackTarget
-> get Controlled Pawn
-> call TryMeleeAttack(TargetActor)
-> Finish Execute based on returned success

The task asks for an action. The pawn implements the action. That keeps the AI decision graph from becoming the owner of animation montage details, weapon collision, cooldown variables, and health rules.

When Behavior Trees are worth it

Do not use a Behavior Tree just because the enemy exists. Use one when the AI has several competing behaviors and needs a visible decision structure.

Good first uses:

  • patrol until a target is sensed;
  • chase while the target is known;
  • search last known location after losing sight;
  • attack only in range;
  • react differently when low health;
  • share one behavior pattern across several enemy pawns.

For one stationary turret that only fires when overlapped, a component event and a few functions may be enough. The structurally better path is the one that matches the amount of behavior, not the one with the most AI tooling.

When it fails (and what failure does)

Symptom Likely cause
Tree never starts AIController did not run the tree, pawn is not possessed by that controller, or the behavior tree asset is missing.
Blackboard keys are unavailable The tree has no Blackboard asset, the wrong Blackboard is assigned, or the key name/type does not match.
Chase branch never runs TargetActor was never set, was set on the wrong AI instance, or a decorator blocks the branch.
AI never returns to patrol Target key/boolean was never cleared on lost sight or timeout.
Tree gets stuck on one task Custom task never calls Finish Execute, or a running task never receives its completion path.
Patrol keeps running after seeing player Higher-priority branch has no observer abort or the relevant key is not being observed.
Move To task fails immediately No NavMesh, invalid target, pawn off navmesh, no movement component, or no controlled pawn.
Attack logic works in one enemy but not another Task casts to one pawn class instead of calling an interface/shared function, or the second pawn lacks required components.

Behavior Tree failure is usually setup or stale facts. Debug the controller, blackboard key values, active tree branch, controlled pawn, and navmesh before rewriting the whole AI.

What Behavior Trees do not do

  • They do not create an AIController or possess the pawn.
  • They do not create a NavMesh.
  • They do not sense the player by themselves.
  • They do not set Blackboard keys unless your controller, service, or task does it.
  • They do not make attacks, health, animation, or damage rules for you.
  • They do not make custom tasks finish automatically.
  • They do not replace replication authority in multiplayer.

Lookalikes - which one do I want?

Tool Use when Watch out
Behavior Tree AI needs prioritized choices such as patrol, chase, search, attack. Needs AIController/Blackboard setup and task/decorator discipline.
Blackboard Tree/controller/tasks need shared AI facts. Not a replacement for every pawn variable.
AIController Blueprint AI brain owns perception, starts tree, controls pawn. Not the mesh/body where animation and damage usually live.
Pawn / Character Blueprint The body moves, attacks, animates, takes damage. Avoid burying all decision logic here once it grows.
AI Move To node A simple Blueprint event should request movement. A Behavior Tree usually uses a Move To task instead.
StateTree You deliberately choose Unreal's state-machine style AI/gameplay framework. Separate system with different setup; not the classic BT/Blackboard path.
Animation State Machine Choose animation poses and transitions. It is not AI decision logic.
Tick graph Tiny prototype or genuine per-frame pawn behavior. Decision logic grows hard to debug when everything runs every frame.

Rule of thumb: perception sets facts, the blackboard stores facts, the tree chooses a branch, tasks call actions, and the pawn performs body behavior.

Going deeper