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. The core is C++, so it runs as native code rather than interpreted script, and it comes two ways: a GDExtension you install from the Asset Library (Godot 4.6+ for the current 1.8 release), or a module compiled into a custom engine build. The module has a slightly better editor experience, and it’s the route to take if you want to write tasks in C# — C# is only confirmed working with the .NET module builds.

Two design choices stand out:

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. It still covers the essentials: a Beehave tab in Godot’s debugger shows each tree’s live node states while the game runs, and every tree gets its own blackboard (shareable between trees, with built-in leaves to set, check, and compare keys).

The trade-offs follow from the scene-node design: each agent carries its own copy of the tree as live nodes (heavier at large agent counts), there’s no dedicated tree editor beyond the scene dock, and the blackboard is simpler than LimboAI’s plans and scope chains.

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:

  1. Sketch the tree in the free online behavior tree editor: get the priority ladder and conditions right while changes cost nothing.
  2. Walk the design against the common patterns — survival override on top? retries around flaky actions?
  3. 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.
  4. Iterate in the sketch first whenever the logic changes — then mirror it in Godot.

▶ Sketch a patrol/chase/attack tree now

Recommended reading

Books that go deeper on the topics in this guide.

As an Amazon Associate, behaviortrees.com earns from qualifying purchases.