Brief overview re-situating behavior trees in the context of the standard agent model and the APE (apperception, planning, execution) architecture. Applicable to Game AI and Robotics.

1. T.E.A de Souza - October 2022
Effective Game AI
Behavior trees through the APE architecture

2. Apperception
Planning
Execution
Apperception
Extract roles and statuses
Variable 0.1~60Hz
Planning
- input/output (blackbox)
- Do not retain state between iterations
- Can test in isolation (fast)
- Can test and validate new design features
before full integration.
Variable frame rate 0.1~10Hz
Execution
- Animation, sound
- Tied to refresh rate (60-120Hz) or physics rate

3. Apperception
Planning
Execution
Blueprints does not hinder good
separation, but also does not actively
encourage it.
Historically BT has been used as an end-all
game scripting platform (break architectural
integrity); this leads to edBT (event driven
behavior trees, breaks responsiveness)
edBTs are not good for planning [Anguelov
2020)
Advances in BT [Colledanchise 2017] have
clarified BT’s benefits. The results do not
apply to edBTs.

4. INPUT
threat: role
ally: role
hungry: status
in-combo: status
….
Planner
(BT, GOAP, …)
Well formed planners do no
hold state.
Call the planner if you need a
“next action”
Same input => Same output
OUTPUT
Take cover
Look around,
Pick up an object,
Shoot
Reload
(Cheer, smile?)
Planner in APE
Replace the planner
seamlessly:
bystander, patrol, on
alert, engaged,
in-combo
Hidden variables make
testing harder:
- FSM
- edBT
- Event frameworks

5. INPUT
A: foe
B: wounded
(other parameters
don’t care)
OUTPUT
Evade
AI Test case
Incremental Design
INPUT
A: foe
B: don’t care?
C: well-armed
(other parameters
don’t care)
OUTPUT
Attack
Well decoupled planning allows testing via
simple i/o test cases (no C++ required)
Design ideas translate into new mappings,
which can be automatically or manually
added to the BT. Depending on the
insertion point, pre-existing tests will
break… or not.
In the suggested example, a new mapping
generates contradiction, which may break
a test, or can be made to fail at runtime.
(threat + wounded + well armed)
=> attack?
=> evade?
(ambiguity)

6. DSL
Framework
Visual Programming
Interpreter Transpiler
Runtime (C++/C##/OpenCL/Cuda)
Building Effective Workflows
Often the correct data presentation differs
depending on who’s looking, and why.
Visual programming may allow (technical)
designers to start things they can’t finish.
A humanly comprehensible BT graph may
not be the most efficient runtime
representation.
BT can integrate with GPLs (C/C++/C#/…)
[de Souza 2020] however an interpreter
can help working with BTs in realtime, and
bridge the AI framework with visual, graph
oriented representations.

7. Standard BT: memory, performance,
optimizations
Via APE, variable 0.25-20Hz
Easily swap the solver (Bystander vs Patrol
vs High alert vs Combat or In-Combo)
Frequency analysis can detect and
optimize “deep stacks” (including just in
time). In a trivial (but common) case,
subsequent iterations of input X will of
course lead same output Y.
No storage requirement (stateless)

8. Past and current work
Active Logic (since 2019) - reformulate BT
as a calculus; applications from realtime
programming to AI
Senior AI engineer at Ultimerse 2021-2022:
combat AIs through C# BTs (Unity)
Currently working on BT-lang (DSL for BTs)
and a framework for technical designers to
easily build performant apperception
components