by drunken_thor
2 subcomments
- 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?
- As a game dev, the fact "AI" as a keyword became totally unusable is quite annoying.
- 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.
by badsectoracula
1 subcomments
- 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).
- 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.
- Low tech AI? Its sounds like standard game AI. I would really like to hear what the author would deem high tech game AI.
- this gets very clear when you look at the wiki on how different bosses move and how the different boss combos lead from one into another
and of course, lets you have a reasonable amount of control over different bosses
by rambojohnson
8 subcomments
- 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.
Hacker News