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?
RE who writes these things: I know you're probably referring to code here but on the actual dialogue side, there was a charming interview recently with the person responsible for translating Miyazaki's vision into English. He apparently did all of the writing (dialogue, item descriptions, UI text) for Dark Souls, and split the work with just one other person for all the later games including Elden Ring.
More topical, I do actually appreciate some of the persistent jankiness like this that hasn't changed since their original games. They experimented with different approaches in DS3, where certain NPCs you encountered would essentially evaporate after you exhausted their dialogue, and they would later materialize back in the hub. I personally hated this -- one element I really enjoyed in the earlier games was this sense that the world doesn't revolve around you. The NPCs feel like rich characters with their own goals and motivations
Having them leave when you're finished talking to them sort of reduced them to utilities, which of course they are ultimately, but the gamefeel suffered a bit from making that more explicit. Don't me wrong though, I love DS3, but I didn't care for that particular change
Anyway, handling NPC progression in this way where the player needs to reload the area is more about navigating a technical limitation than anything else. But like many constraints it conspires with others to produce a certain gamefeel that I enjoy. It would feel a bit less impactful if Hyetta just moved on the instant I exhausted her dialogue -- it's more interesting for me to return and see that she has moved on
Another example of this sort of thing is FromSoft supposedly historically being bad at animating eyes, hence many critical NPCs being blindfolded or with faces hidden by helmets or otherwise obscured. This imagery plays nicely with their other sensibilities around character design and is thematically pretty rich
This post seems to be mostly (although not entirely) concerned with the combat AI. The plot based NPC interactions don’t seem to be very dynamic at all, mostly just a graph with a lot of dead-ends, haha.
thats game design not something engine related. its been like this since before demons souls, i think it started out way back with the first kings field. its just the way fromsoft do things. everyone knows what to expect from them.
Just to underline your point, Sekiro's NPCs behave in a much more obvious and linear way relative to From's other games, so it's clearly a game design decision and not a technical one.
Especially in Elden Ring, it also contributes to the ludonarrative cohesion. Hyetta's quest (no spoilers!) isn't meant to be completed by everyone, her story is a foil to Melina's "default" questline that is mandatory for beating the game. Other characters (eg. Boc, Sellen, Selivus, Thops) also have quests that are easy to start but deliberately obfuscated towards the end.
The JRPG logic is annoying, but From uses it to beg important questions about the game world and the player. Fromsoft characters like Lautrec live in infamy for being so slippery and deliberately misleading.
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).
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.
This is game AI, games called this sort of thing "AI" for a long time. Behavior trees is (among others) one of the most common things someone with the role of game AI programmer will implement.
This has been the case since at least the 90s, it is not a new thing.
There are paradigms of AI that are not deep learning. If you took an AI course in the 90s or earlier, implementations like this are much closer to what you would learn about -- symbolics/GOFAI. It remains basic to some fields where stakes and complexity are high (air traffic control and military systems) but determinism is a strict requirement, not to mention others like gamedev that have lots of performance constraints -- and usually don't actually need or want anything non-deterministic or overly smart.
Deep Blue, the first chess engine to defeat a world champion, was a GOFAI system
There was an article recently about a system used in production at a pasty chain in Japan to classify pastries at checkout that didn't use DL for most of its existence. Now it seems to be a hybrid system that uses symbolics and DL for certain functions
Is a book like that still pretty useful? Or is Ai in games abstracted away in game engines pretty much? I've been meaning to play with unreals Ai features a bit.
It's not pedantry at all, there are simply different paradigms of AI. The dominant one today is DL, symbolics/GOFAI were dominant decades ago. These methods are still used today in some fields, not merely gamedev
The logic used to implement game NPCs has been called "AI" since well before the current AI boom. And many of the techniques come from the previous AI boom of the 1970s-1980s.
I know that we're all experiencing AI fatigue, but this comment is an example of the "once an AI technology finds a niche and becomes accepted technique within that niche, it ceases to be AI" meme.
I know very little about AI and game mechanics, but knowing how early Fromsoft games were (e.g., Kingsfield), a basic AI in Elden Ring is very unsurprising. That's not necessarily a bad thing!
My vote for "high tech game AI" would probably be this old mod for Fallout 4:
>PANPC (Pack Attack NPC Edition) is a unique scripted AI management system for Fallout 4. Rather than treating each enemy as an individual proximity-based reaction agent (basically, a mine with a gun), this system generates social feedback between NPCs belonging to the same or allied factions.
>Enemies factor the overhaul health and success of their “team” into their tactical decisions, adjusting their strategies based on their social and threat awareness. As a result, they will switch between ranged, melee, defensive, and offensive tactics based on their perceptions of team advantage and individual risk.
F.E.A.R 2 was released on the PS3 and Xbox 360, both of which have laughably low specs by modern standards. When you have to create dynamic experiences out of a potato you are forced to get creative and that involves squeezing a lot of juice out of basic techniques.
Transformer based AI had to wait until the world's compute capacity reached a certain level to become feasible.
My favorite high tech AI was Crysis. Might have been an update after it was originally released. The enemies will aggressively attack but then get quiet after you've taken cover. Eventually you'll realize some of them are flanking you while others keep suppressing fire on you to stop you from moving. You can hear them yelling to one another. Very cool touches.
That reminds me of First Encounter Assault Recon, where the AI had fairly simple rules, which worked well with the level design to make the enemies seem intelligent, especially as Monolith added chatter to make them seem even smarter. And then one of the expansions had a bunch of open areas and the AI didn't handle those well so the trick didn't work.
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.
The article has been updated in response to this post.
(See the end)
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?
RE who writes these things: I know you're probably referring to code here but on the actual dialogue side, there was a charming interview recently with the person responsible for translating Miyazaki's vision into English. He apparently did all of the writing (dialogue, item descriptions, UI text) for Dark Souls, and split the work with just one other person for all the later games including Elden Ring.
https://youtu.be/vIbKALhzHVc?si=WRAQs77WG2QwVkt5
More topical, I do actually appreciate some of the persistent jankiness like this that hasn't changed since their original games. They experimented with different approaches in DS3, where certain NPCs you encountered would essentially evaporate after you exhausted their dialogue, and they would later materialize back in the hub. I personally hated this -- one element I really enjoyed in the earlier games was this sense that the world doesn't revolve around you. The NPCs feel like rich characters with their own goals and motivations
Having them leave when you're finished talking to them sort of reduced them to utilities, which of course they are ultimately, but the gamefeel suffered a bit from making that more explicit. Don't me wrong though, I love DS3, but I didn't care for that particular change
Anyway, handling NPC progression in this way where the player needs to reload the area is more about navigating a technical limitation than anything else. But like many constraints it conspires with others to produce a certain gamefeel that I enjoy. It would feel a bit less impactful if Hyetta just moved on the instant I exhausted her dialogue -- it's more interesting for me to return and see that she has moved on
Another example of this sort of thing is FromSoft supposedly historically being bad at animating eyes, hence many critical NPCs being blindfolded or with faces hidden by helmets or otherwise obscured. This imagery plays nicely with their other sensibilities around character design and is thematically pretty rich
This post seems to be mostly (although not entirely) concerned with the combat AI. The plot based NPC interactions don’t seem to be very dynamic at all, mostly just a graph with a lot of dead-ends, haha.
thats game design not something engine related. its been like this since before demons souls, i think it started out way back with the first kings field. its just the way fromsoft do things. everyone knows what to expect from them.
Just to underline your point, Sekiro's NPCs behave in a much more obvious and linear way relative to From's other games, so it's clearly a game design decision and not a technical one.
Yeah, I’ve been playing these games since DS1 (currently on my umpteenth DS3 run as I recover from surgery). The quests never fail to make me laugh.
Especially in Elden Ring, it also contributes to the ludonarrative cohesion. Hyetta's quest (no spoilers!) isn't meant to be completed by everyone, her story is a foil to Melina's "default" questline that is mandatory for beating the game. Other characters (eg. Boc, Sellen, Selivus, Thops) also have quests that are easy to start but deliberately obfuscated towards the end.
The JRPG logic is annoying, but From uses it to beg important questions about the game world and the player. Fromsoft characters like Lautrec live in infamy for being so slippery and deliberately misleading.
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).
As a game dev, the fact "AI" as a keyword became totally unusable is quite annoying.
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.
Stop calling everything AI, guys.
This is game AI, games called this sort of thing "AI" for a long time. Behavior trees is (among others) one of the most common things someone with the role of game AI programmer will implement.
This has been the case since at least the 90s, it is not a new thing.
There are paradigms of AI that are not deep learning. If you took an AI course in the 90s or earlier, implementations like this are much closer to what you would learn about -- symbolics/GOFAI. It remains basic to some fields where stakes and complexity are high (air traffic control and military systems) but determinism is a strict requirement, not to mention others like gamedev that have lots of performance constraints -- and usually don't actually need or want anything non-deterministic or overly smart.
Deep Blue, the first chess engine to defeat a world champion, was a GOFAI system
There was an article recently about a system used in production at a pasty chain in Japan to classify pastries at checkout that didn't use DL for most of its existence. Now it seems to be a hybrid system that uses symbolics and DL for certain functions
https://www.newyorker.com/tech/annals-of-technology/the-past...
FYI, one of the most well-known books about writing game entity behavior is literally called "Programming Game AI by Example." (published in 2004)
https://www.amazon.com/Programming-Example-Wordware-Develope...
Is a book like that still pretty useful? Or is Ai in games abstracted away in game engines pretty much? I've been meaning to play with unreals Ai features a bit.
That was called AI before the current LLM-AI era. Your comment reads like someone complaining that cryptography is called crypto
> What you're describing is a behavior tree: predefined logic, predefined responses, no learning, no inference, no model.
Stop calling everything AI, guys.
Depends on how pedantic you want to get, one could argue that regular expressions are AI too.
https://www.rand.org/content/dam/rand/pubs/research_memorand...
Regexes were invented for much higher order tasks (modeling neural networks) than just making find-and-replace easier.
It's not pedantry at all, there are simply different paradigms of AI. The dominant one today is DL, symbolics/GOFAI were dominant decades ago. These methods are still used today in some fields, not merely gamedev
The logic used to implement game NPCs has been called "AI" since well before the current AI boom. And many of the techniques come from the previous AI boom of the 1970s-1980s.
I know that we're all experiencing AI fatigue, but this comment is an example of the "once an AI technology finds a niche and becomes accepted technique within that niche, it ceases to be AI" meme.
Low tech AI? Its sounds like standard game AI. I would really like to hear what the author would deem high tech game AI.
I know very little about AI and game mechanics, but knowing how early Fromsoft games were (e.g., Kingsfield), a basic AI in Elden Ring is very unsurprising. That's not necessarily a bad thing!
My vote for "high tech game AI" would probably be this old mod for Fallout 4:
>PANPC (Pack Attack NPC Edition) is a unique scripted AI management system for Fallout 4. Rather than treating each enemy as an individual proximity-based reaction agent (basically, a mine with a gun), this system generates social feedback between NPCs belonging to the same or allied factions.
>Enemies factor the overhaul health and success of their “team” into their tactical decisions, adjusting their strategies based on their social and threat awareness. As a result, they will switch between ranged, melee, defensive, and offensive tactics based on their perceptions of team advantage and individual risk.
https://fallout.wiki/wiki/Mod:PANPC_(Pack_Attack:_NPC_Editio...
F.E.A.R. 2 has the best AI that I can think of. Wonder if it counts as high tech or they just squeezed a lot of juice out of basic techniques
You’re in luck, they made a great paper on this!
https://www.gamedevs.org/uploads/three-states-plan-ai-of-fea...
F.E.A.R 2 was released on the PS3 and Xbox 360, both of which have laughably low specs by modern standards. When you have to create dynamic experiences out of a potato you are forced to get creative and that involves squeezing a lot of juice out of basic techniques.
Transformer based AI had to wait until the world's compute capacity reached a certain level to become feasible.
> Transformer based AI had to wait until the world's compute capacity reached a certain level to become feasible.
It's OK, they'll just keep subsidizing it until it's eventually feasable...
My favorite high tech AI was Crysis. Might have been an update after it was originally released. The enemies will aggressively attack but then get quiet after you've taken cover. Eventually you'll realize some of them are flanking you while others keep suppressing fire on you to stop you from moving. You can hear them yelling to one another. Very cool touches.
That reminds me of First Encounter Assault Recon, where the AI had fairly simple rules, which worked well with the level design to make the enemies seem intelligent, especially as Monolith added chatter to make them seem even smarter. And then one of the expansions had a bunch of open areas and the AI didn't handle those well so the trick didn't work.