Hello folks,

I've lately played quite a bit Behavior Trees for AI Decision Making in my game, and noticed there are 2 main literatures surrounding this concept.

But first let's discuss what an AI requires:

• Sensors
• Decision Making
• Actuation (Animations, Sound, Commands, etc)

I've always thought of BT as a tool that could serve both Decision Making and Actuation, but lately I'm not so sure about it, here is an article which goes into detail why BT are best served as Actuation tool ONLY: https://takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf.

TL;DR:

When using Behavior Trees in both Decision Making and Actuation, the tree constantly grows and and variations of the same tree might look completely different - this of course counters the Separation of Concerns, which is also clear as the tree grows and it's harder to introduce new features.

That being said, there is no denying that BT are very comfortable tools, they describe flows and data in the simplest form we humans can conceive, as such I'm wondering if anyone had managed to balance the two responsibilities into a scalable design, which still retains some simplicity.

Since I work with ECS, most of the actual logic is done by those systems,, and I mostly view the Actuation as trigger entities, which do not perform any other logic.

What are your thoughts?

Behavior trees are a very limited form of scripting. You can think of them as a scripting language that only provides two operations: || and &&, in C notation. In some development environments limiting the ability of game designers to mess things up is extremely valuable, and BTs can then be a good choice.

@alvaro I agree that BTs can serve a fine replacement to conditional statements.

The issue I raise is that, those trees who combine decision making, and in the same time actualize those could leader to messy trees and reduce productivity.

In smaller games I think that it is something you can iverlook, but in RPGs for instance this could be the right tool for the wrong job.

I think that behavior trees are a good conceptual framework for writing C++ code, an OK conceptual framework for writing scripts in a scripting language, and terrible when treated as a visual scripting language in and of themselves. Draw pretty diagrams if it helps you conceptualize complex behaviors, but translate them into real code.

Good behavior tree:

enum result { running, success, failure};
result select(std::vector<std::function<result()> > const &child_nodes) {
  for (auto const &fn : child_nodes) {
    result r = fn();
    if (r != result::failure) {
      return r;
    }
  }
  return result::failure;
}
result chase_player() { ... }
result patrol() { ... }
result ai_for_enemy() {
  return select(chase_player, patrol);
}

Interesting pov, for what reasons do you think they are terrible for visual programming?

I usually find it easy to understand complex behaviors when the data flow is presented before me.

I think visual scripting is just a terrible idea in general. It's less readable for all but the most trivial cases, it's much slower to write and to edit, it requires a huge pile of work up front writing the editor and the interpreter, it continually requires extra work to provide additional primitives, and unless it somehow compiles to native code the performance is going to be crap. And for AI code in particular, you want the freedom to try ideas that don't neatly fit into the behavior tree paradigm. Rapid prototyping is critical for AI code, and rapid prototyping is only possible in visual scripting languages if you already have high-level primitives that do most of the work for you, which is never going to be the case.

a light breeze said:
I think visual scripting is just a terrible idea in general. It's less readable for all but the most trivial cases, it's much slower to write and to edit, it requires a huge pile of work up front writing the editor and the interpreter, it continually requires extra work to provide additional primitives, and unless it somehow compiles to native code the performance is going to be crap. And for AI code in particular, you want the freedom to try ideas that don't neatly fit into the behavior tree paradigm. Rapid prototyping is critical for AI code, and rapid prototyping is only possible in visual scripting languages if you already have high-level primitives that do most of the work for you, which is never going to be the case.

100% disagree. I don't want this thread to divulge into a full opinion-based argument about visual scripting, but I just want to put the opposite opinion out there. I think visual scripting has many benefits that are useful when writing gameplay. It does require some amount of effort to get right, and pretty much needs to be tightly integrated into the engine (like in UE4), but when thats the case, I take it over something like C# in Unity every day.

One thing that I found especially useful for behaviour-trees (which I used in Unreal and pretty much copied their inteface) is the ability to see exactly what the tree is doing in real-time. Sure, you can always debug your scripts, but having the ability to just see what state the tree is in, what paths were taking previously, which conditions failed etc… (while also being able to select which instance to inspect without having to use conditional-breakpoints or put if (name == XXX) into your code) is greatly useful!

The concept of behavior trees is a great tool for many games. It is a poor choice for other games.

Even if the concept fits the design, the implementation encodes decisions which may be great for the game, or bad for the game. Implementation details about the concepts matter tremendously. A good match can make the game a joy to implement.

Both the concepts and the techniques are useful to know. They are a great tool to have in your toolbox.

I ended up with using Behavior Trees as actualization process only, I calculate the AI's decisions using Utility-esque process.

I agree with @frob statements of the Behavior Tree not being a swiss knife, the reference I've posted sums it up pretty well - it's a good tool but many times used wrongly/un-neededly.