This is behaviour trees. What you’re describing is behaviour trees.
Edit: I see later you say it isn’t a behaviour tree but this is how a lot of BTs are implemented. They don’t always loop from the root. A lot of the time according to state the root is redefined off of a branch and that sub tree is looped until going further down the tree or even into a different tree. Much like the stack you are describing.
Perhaps this explains why Fromsoft npc quests are easily the most inscrutable in all of gaming. Like, okay Hyetta, have another “grape”, aka eyeball, oh now you’ve moved to the bridge in Liurnia, cool. I’ve exhausted your dialogue but you’re stuck. Oh I have to reload the area and exhaust it again to advance your quest. Okay, cool. Now you’re in a random church and you want a “fingerprint grape”. What?
It’s all part of the Fromsoft experience but man, who writes these things?
When I finally started using the internet to figure out what I'm supposed to do next on some of the quests, I couldn't believe how many of the answers were "Talk to the NPC three times in a row to exhaust their dialogue".
Like, are you shitting me? Why? After a while, I would do this to every NPC, every time. But, yeah, it's a bad design.
It's hard and expensive to do branching games. Most games just fake it with a "branch and merge" system (save Carley or Doug, but the one you save is still going to leave the party forever in 20 minutes).
Fromsoft wants to do major seperate quest lines, so they have to cut corners elsewhere. I guess they choose a robust system that is sometimes annoying for the player.
Elden Ring quests are implemented in a totally different set of systems from the one described in TFA, mostly something called EzState (dialogue trees) and EMS (map events). These are basically very primitive bytecode interpreters with unusual execution models and a small API surface to interact with the game world, so I think you're onto something. I can imagine the designers having a hard time implementing nicer interactions without constantly modifying the engine.
According to [1], earlier versions of the EMS editor were built on Microsoft Excel, took 30s to open, and didn't support undo/redo. They rewrote it for Elden Ring, but Dark Souls quest design makes a lot more sense when you realize how hard it was to change anything.
You picked the most filler, unfinished questline to make a point for your argument lol
And yet, that's still way better than having a quest log UI, constant screen notifications, and narration that babysit you all the time, treating you like you have never played a RPG before, acting like you are too stupid to read and listen to npc dialogue and items lore
I'll take the jank over what the western industry is filled with
For their first real open world, it holds pretty well
I try to say "LLM" as much as possible, but I'm aware that it's unlikely to work.
Partly for technical accuracy, partly to manage the average person's expectations when they hear "AI", partly to avoid contributing to a big dumb-money "everything is AI" bubble, etc.
The same thing happened with crypto (cryptography) after Bitcoin blew up, though it was just an abbreviation so it wasn't as bad.
There's no ambiguity when speaking, but when searching Rust-related things I get a lot of Rust game stuff. "Rust crates" or "Rust drops" correspond to in-game things so the fandom wiki will pop up. Occasionally I'll even get rust-removal webpages.
As an ex-game dev, I always found it a little annoying that they used "AI" for what was essentially just hard-coded logic.
It's a hard problem because "AI" has been a term since the 50s but has been used to describe different approaches to making a computer do things over time. The way game developers use "AI" to mean "hardcoded logic for game behavior" is fully inline with what "AI" meant in the 60s when they were using symbolic AI to write the first computer-controlled chess games.
Then AI programmers hit the wall of hard-coded logic, went through an AI winter, and what survived on the other end was logic that was automatically trained from big data sets. We used to call that "machine learning" because "AI" had connotations of snake oil from previous AI winters. But then within the past decade, tech companies with grandiose ambitions decided that "machine learning" was too nerdy so resurrected "AI" to refer to LLMs and their ilk.
Everyday I hope a LLM enthusiast discovers how game "AI" (and games in general) fool/trick people and realizes LLM's don't do anything different. Some of my favorite examples are the Mario kart AI, Amnesia and Deadspace. It's all an extension of the ELIZA effect.
What do you mean by "low-tech AI"? This isn't AI...It's a behavior tree. Calling every decision-making system "AI" is like calling a flowchart a neural network.
What you're describing is a behavior tree: predefined logic, predefined responses, no learning, no inference, no model.
It's called AI because it drives the behavior of the NPCs, hence the name "artificial intelligence". I couldn't think of a better fitting term, especially if you know it is in the context of games. Everyone who actually plays games knows what AI in gaming means and that it doesn't need to involve LLMs or neural networks.
The thing about artificial intelligence is that it doesn't necessarily have to look or behave like biological intelligence. It could very well be a very alien and foreign form of intelligence.
Artificial intelligence is a huge research field and has been for closer to 50 years. It's taught in schools. It has hard theory and praxis. Not everything, but adversarial algorithms are absolutely core AI.
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).
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.
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.
The high level might look simple, but something like "attack" has to involve checking if it's possible/reasonable in a 3D space, animating turning and walking prior to the attack, playing the animations, dealing with player block or parry, etc.
Any good library author is going to try to bury the complexity so that users don't need to deal with it, but there can be a monstrous beast under the hood.
Not really an ai response but I remember the path following and aggro is really smart in Elden Ring and earlier Dark Souls. That is you try to run away after pulling aggro and when you think you're safe you'll run into some other strong enemies, after which, oops, the original enemy followed you down a ladder and stabbed you in the back. Of course they have a bunch of occasions where enemies are in places you don't expect them as well. It isn't really about the mob ai as much as level design and the balance of difficult-to-kill enemies at inconvenient times.
28 comments
[ 2.9 ms ] story [ 34.0 ms ] threadIt’s all part of the Fromsoft experience but man, who writes these things?
Like, are you shitting me? Why? After a while, I would do this to every NPC, every time. But, yeah, it's a bad design.
Fromsoft wants to do major seperate quest lines, so they have to cut corners elsewhere. I guess they choose a robust system that is sometimes annoying for the player.
According to [1], earlier versions of the EMS editor were built on Microsoft Excel, took 30s to open, and didn't support undo/redo. They rewrote it for Elden Ring, but Dark Souls quest design makes a lot more sense when you realize how hard it was to change anything.
[1] https://cedil.cesa.or.jp/cedil_sessions/view/2662
And yet, that's still way better than having a quest log UI, constant screen notifications, and narration that babysit you all the time, treating you like you have never played a RPG before, acting like you are too stupid to read and listen to npc dialogue and items lore
I'll take the jank over what the western industry is filled with
For their first real open world, it holds pretty well
https://www.youtube.com/watch?v=CF0NyeCARf4
Partly for technical accuracy, partly to manage the average person's expectations when they hear "AI", partly to avoid contributing to a big dumb-money "everything is AI" bubble, etc.
There's no ambiguity when speaking, but when searching Rust-related things I get a lot of Rust game stuff. "Rust crates" or "Rust drops" correspond to in-game things so the fandom wiki will pop up. Occasionally I'll even get rust-removal webpages.
It's a hard problem because "AI" has been a term since the 50s but has been used to describe different approaches to making a computer do things over time. The way game developers use "AI" to mean "hardcoded logic for game behavior" is fully inline with what "AI" meant in the 60s when they were using symbolic AI to write the first computer-controlled chess games.
Then AI programmers hit the wall of hard-coded logic, went through an AI winter, and what survived on the other end was logic that was automatically trained from big data sets. We used to call that "machine learning" because "AI" had connotations of snake oil from previous AI winters. But then within the past decade, tech companies with grandiose ambitions decided that "machine learning" was too nerdy so resurrected "AI" to refer to LLMs and their ilk.
The term is just a muddled mess.
https://en.wikipedia.org/wiki/Ai_(given_name)
What you're describing is a behavior tree: predefined logic, predefined responses, no learning, no inference, no model.
Stop calling everything AI, guys.
The thing about artificial intelligence is that it doesn't necessarily have to look or behave like biological intelligence. It could very well be a very alien and foreign form of intelligence.
LLMs are a tiny blip in it.
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).
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)
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.
and of course, lets you have a reasonable amount of control over different bosses
Any good library author is going to try to bury the complexity so that users don't need to deal with it, but there can be a monstrous beast under the hood.
They have accumulated bloat and tech debt since their inception as a studio
https://github.com/ividyon/EldenRingHKS/blob/main/c9997.hks
But it works for them, and that's what creates their flavored games, i hope they'll never change a bit