I just finished coding a generic Behavior Tree structure for my games. My question is, when creating behaviors for enemy AI's, do I create one large behavior tree with every possible configuration as a node or do I create many multiple Behavior Trees and simply swap them in and out as I need them?

To better understand my question here are some examples:

One large Behavior Tree might look something like this:

One all encapsulating Behavior Tree

Multiple smaller Behavior Trees might look like this:

enter image description here

In the second tree I would simply swap out different trees depending on when I need them. This is more apparent for things like evading and backing away from obstacles, I feel like that would need to be done alongside many other behaviors like chasing and evading.

I hope that made sense.

  • 3
    \$\begingroup\$ Isn't it the same thing fundamentally? The subtrees are some subset of code/data/however you're representing the tree and whatever logic that would be selecting which path to go down would be the same as whatever your main selector is. \$\endgroup\$
    – Tetrad
    Commented Mar 13, 2013 at 21:30
  • \$\begingroup\$ Yes I realized that after posting the question for some reason, but then regarding the second question would I also include rudimentary behavior like "obstacle avoidance" and such? \$\endgroup\$ Commented Mar 13, 2013 at 22:31
  • \$\begingroup\$ Well ideally "obstacle avoidance" would be a component in your tree you could just plug in. \$\endgroup\$
    – Tetrad
    Commented Mar 13, 2013 at 23:19
  • 1
    \$\begingroup\$ Obstacle avoidance would generally be part of the underlining locomotion system. Unless you need special cases. \$\endgroup\$
    – Feltope
    Commented Mar 24, 2013 at 12:37

2 Answers 2


Generally there would be no need to "swap" out trees.

Build all your behaviors, add in your sequences and selectors to make your tree for your ai agent.

Then for special case stuff you add decorators to stuff where needed.

One big tree, per agent "type" so a soldier type would have a tree with patrol, attack etc etc and a miner would have a different tree. They would use many of the same objects (ie. go to way point) but you just wire up your tree for each agent you needed.

The first picture you have in your post is the way to go.


Not sure if I understand your question correctly. Do you mean during runtime? Or when you design your trees? Certainly when designing your trees, it helps a lot to create lots of small, reusable, modular trees.

You can try creating the concept of "tree link" nodes. Nodes that just let the traversal jump to a different tree (a whole separate tree, stored in a different file, perhaps), and when that tree finally gives a return value, uses that as its return value.

This way you can have a generic main tree that have branches touching on broad subjects: survival, attack, idle, etc. Then you just add your tree links into those empty branches to create variations. You may have an attack subtree that's designed to keep away and just do ranged attacks. You might have another one that's designed to charge head on and do melee attacks instead.

This way its easy to organize your AI types, by just doing a mix-and-match approach. This is not necessarily for convenience in modifying your trees during runtime, but that can be possible too.

Doing this also makes your trees a lot more readable to fellow teammates. It's essentially using the concept of "abstraction" and "information hiding". Two very powerful concepts in software engineering in helping to keep large systems easy to understand and maintain.

  • \$\begingroup\$ This also makes your tree much more dynamic at run-time. Imagine a situation where your AI learn different "skills" when they find and read a scroll or some other AI teaches them. As the game progresses their knowledge can be expanded by their experiences instead of all defined up front. Each sub tree is defined in it's own separate space for that 1 specific skill, but can be linked to an actors BT over time. Pretty cool stuff. \$\endgroup\$
    – user441521
    Commented Jan 9, 2018 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .