Behavior Trees in Godot
Unlike Unreal, Godot has no built-in behavior tree system — and unlike Unity’s asset store, you won’t be weighing paid options: the leading Godot solutions are free and open source. The real decision is between two very different philosophies, plus the ever-present option of writing your own. (Still deciding whether behavior trees fit at all? Start with Behavior Trees vs Finite State Machines.)
Option 1: LimboAI (the feature-complete one)
LimboAI is the most complete behavior tree implementation for Godot 4: a dedicated visual tree editor inside the Godot editor, a rich built-in task library, a proper blackboard with scoping, live in-editor debugging of running trees, and custom tasks written in GDScript or C#. It’s distributed as a GDExtension (or compiled-in module), so the core runs as native code rather than interpreted script.
Two design choices stand out:
- Trees are resources, not scene nodes. One
.trestree asset can drive any number of agents, each with its own blackboard — the same stateless-tree model used by behavior3 and most production engines. - It ships a hierarchical state machine too (
LimboHSM), designed to interoperate: states can run behavior trees. That’s the “FSM at the top, BTs inside” hybrid real games use, supported out of the box.
Choose it if you’re building a serious project and want the closest thing Godot has to Unreal’s integrated BT tooling. Watch out for: it’s a bigger dependency with its own editor conventions, and native builds must match your Godot version.
Option 2: Beehave (the Godot-native one)
Beehave takes the opposite approach: behavior trees are built from ordinary Godot
nodes, right in your scene tree. A BeehaveTree node has composite children (sequence,
selector — including memory variants), which have condition/action leaves that are just
GDScript classes overriding a tick() method.
The appeal is that it feels like Godot — you compose trees in the scene dock you already know, no new editor to learn, and the whole library is readable GDScript. The trade-offs follow from the same choice: each agent carries its own copy of the tree as live nodes (heavier at large agent counts), and there’s no equivalent of LimboAI’s dedicated editor, debugger, or blackboard scoping.
Choose it if you want the gentlest learning curve, your agent count is modest, and “just Godot nodes” sounds better than “an embedded AI IDE.”
Option 3: roll your own
A minimal BT core in GDScript is genuinely small — a status enum, a base task with a
tick() method, sequence, selector, and a couple of decorators (the
from-scratch walkthrough covers the exact
shape, and it ports to GDScript almost line for line). Godot’s Resource system even
gives you tree serialization for free.
The trap is the same as everywhere: the core is a weekend, the tooling — visual authoring, live inspection — is months. If you go this route, keep design in an external editor and load a data format rather than hand-building trees in code.
A design-first workflow for all three
The structure of your tree — priorities, guards, fallbacks — is independent of which runtime executes it:
- Sketch the tree in the free online behavior tree editor: get the priority ladder and conditions right while changes cost nothing.
- Walk the design against the common patterns — survival override on top? retries around flaky actions?
- Translate: each condition/action leaf in the sketch becomes a LimboAI task, a Beehave leaf, or a class in your own runtime; each blackboard key in the design becomes a real key.
- Iterate in the sketch first whenever the logic changes — then mirror it in Godot.
▶ Sketch a patrol/chase/attack tree now
Related guides
- Sequence, Selector, and Decorator Nodes Explained
- Behavior Tree Blackboards
- Shipping on other engines too? Unity · Unreal