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.
The video is actually describing the exact same thing as the blog post. The approach of FROMSOFT to NPC AI hasn't really changed much at all between Dark Souls and Elden Ring. (One of the most impressive things about their studio imo is the way they don't change much between titles, and yet all the games have a quite unique feel)
What the video refers to as a "Combat Wheel" is, in my opinion, much more easily explained as a weighted random selection. It really just takes a list of functions and randomly chooses one to call with dynamic weights. (But I appreciate that I differ significantly from AI academia on this point, because I also think the term "utility ai" is a really silly term for... dynamically weighting options before selection)
Likewise the start of that video talks a lot about the "Goals", in reference to complex planners like GOAP (which is the approach famously used in FEAR) and HTNs, but there is no planner here. It's just a basic pushdown automata.
Anyway, the reason I wrote this post in the first place is mostly because I watched that video and it felt a bit off, and investigated the code myself.
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)