The article keeps on mentioning about the performance issues of the decision tree that somehow this approach avoids, but it doesn't seem to actually put any real detais about the why here. Especially considering that:

1. Many scripting languages you'd find in games are implemented by evaluating the syntax tree directly (IIRC WitcherScript in Witcher 2 and 3 is implemented like that)

2. A behavior tree can be "compiled" down to a bytecode VM similar to what some scripting languages use

Though if any of these two approaches makes any difference in performance i'm not sure and i'd expect it'd depend heavily on how exactly they're implemented (my kneejerk reaction would be to expect the VM approach to be faster because parsing a bytecode sequence might be more cache friendly than jumping through pointers, but i also suspect that since game AI scripts/behaviors wont do any real computation themselves and instead 99% of the code would be engine/native calls, any potential benefit would be diminished -- but as i haven't tried to implement the same stuff with a realistic setup using both approaches to compare, i cannot say one or the other for certain).

▲

animal531 6 hours ago | parent | next [-]

Roughly speaking FSM + stack based approaches are perfectly fine for 100 entities, but not for 1k.

Once you get to that point you can still make it work but it will take a lot of work to make it as fast as possible, whereas you'd have been better served by more branchless approaches that doesn't parse/jump the FSM.

▲

BigTTYGothGF a day ago | parent | prev | next [-]

How big are these trees that performance starts to matter?

▲

badsectoracula 19 hours ago | parent [-]

Usually one would start with "is there a measurable performance bottleneck here?" :-P.

TBH i haven't played Elden Ring but from what i've seen there are so few "active" NPCs around that i highly doubt there'd be any performance issue coming from this.

	▲	Cthulhu_ 13 hours ago \| parent [-]
		Yeah I doubt it, in terms of scale you get at most dozens of enemies, and I can't imagine their behaviour is at all expensive compared to everything else. Every "mode" (idle, attack 1/2/3, etc) is relatively slow as well.

▲

dotstdy 14 hours ago | parent | prev [-]

Yeah you're totally correct that ultimately the specific implementation details are what matters for performance. You could easily take either system and make it terribly slow, or more than fast enough. That's why I was somewhat deliberately vague about performance claims, it's really just a vibe-based thing.

Basically in my experience when you actually build a behavior tree as a tree, you get a pretty significant node count once you try to do anything remotely complex, just due to the way that behavior trees implement both control flow and actions as a (usually) static tree. In large AAA games this can really quickly turn into a situation where you have tens of thousands of nodes in a single behavior tree, which you then need to deal with somewhat efficiently. This affects not only the runtime, but the editor tooling as well, since these are often authored as visual noodle graphs.

You could totally lower the tree to some kind of bytecode, or optimized representation, but something I like about the approach here is that you kinda just don't need to do that. It's naturally resistant to the kind of node explosion you get with static trees because the decision logic is contained within nodes as Lua script (or C++ code), rather than built into the tree structure itself.

It's not a strongly justified position, I just think these kinds of structural decisions have an oversized impact on the amount and kind of optimization work you need to do down the line.

(Author here, if it wasn't clear)