The AI of Dark Souls
The inner workings of one of the most influential games of all time.
AI and Games is made possible thanks to crowdfunding on Patreon as well as right here with paid subscriptions on Substack.
Support the show to have your name in video credits, contribute to future episode topics, watch content in early access and receive exclusive supporters-only content
If you'd like to work with us on your own games projects, please check out our consulting services provided at AI and Games.
Dark Souls is a third-person action role-playing game steeped in dark, medieval fantasy and first released in 2011. Players fight against numerous demonic and supernatural creatures all in a quest to gather souls, the currency of progression and reward of the franchise. Combat is often ruthless and deadly, with a high degree of difficulty. Players only respite comes from bonfires that appear across the realms of Lordran. While resting at each bonfire, players can replenish their resources and spend souls for upgrades, but upon departure you will discover that the vast majority of enemies have since respawned to fight once more.
Developed by Japanese studio FromSoftware under the codename 'Project Dark' as the spiritual successor to 2009's Demon’s Souls, Dark Souls is often considered one of the greatest video games of all time. While its predecessor established many of the core ideas of souls, bonfires, and intense difficulty, plus the ability to lose your accrued souls at the point of death, it is Dark Souls that refined these ideas into a game that has since garnered much critical acclaim, as well as ongoing debate surrounding its impact on the industry. It defined an entirely new genre within the industry, the ‘Soulslike’, with many a title inspired by this philosophy such as Team Ninja's Nioh and Deck13 Interactive's The Surge from 2017, Gunfire Game's Remnant from the Ashes, and Respawn's Star Wars Jedi Fallen Order in 2019. Meanwhile From Software's own games became their own subgenre: with Demon’s Souls, the trilogy of Dark Souls titles, Bloodborne, Sekiro: Shadows Die Twice, and Elden Ring, commonly referred to as ‘Soulsbornes’.
What is of interest to us here on AI and Games is that at the core of all of these games are ruthless and relentless enemy non-player characters (NPCs). What at first may seem rather rigid and merely aggressive becomes more complex and interesting upon further analysis. Enemy NPCs in Dark Souls can prove to be highly versatile: they change weapons based on in-game conditions, heal themselves when possible, embrace the use of magic and other special abilities, and react to the player to capitalise on your mistakes by blocking your attacks or even parrying them. A player's game can be invaded not just by other players, but also NPC phantoms who are often more ruthless and challenging than the average enemy. Meanwhile, boss battles can feel overwhelmingly difficult to the uninitiated, as you need to learn the right time to block, to dodge, to strike, and to flee. Learning the behavioural patterns of many of the more ruthless enemies of the game is one that takes time, and even then there is a significant amount of randomness involved. No boss battles plays out the same way twice, and often you can bring in an ally NPC to help you turn the tide in even the most challenging of skirmishes.
And so with that in mind, it's time to dig in further. Let's start by getting to grips with the underlying architecture, and critically, how I began to piece all of this together.
Dark Souls Engine
Dark Souls was developed using FromSoftware's in-house proprietary game engine. While their engine utilises middleware such as Havok for physics, FMOD for audio and Bink for video, its core is developed by the studio using the C++ programming language. But on top of this, a lot of additional components are scripted using Lua. This is a rather common practice in AAA given the relative ease of use and efficacy of Lua as an embedded scripting platform. In fact, we discussed it briefly back in my overview of the multiplayer bots work in Halo Infinite. Programmers can quickly integrate Lua scripts in a way that is flexible and allows for features to be easily added, or removed, where necessary.
These publicly shared decompilations, alongside some of my own research into the engines operations - not to mention trying to translate it all from Japanese to English - have helped me build an understanding of just what exactly it is that Dark Souls is doing. So let me stress that what follows is my interpretation of how this game works. I didn't receive any support or assistance from anyone involved in the development of the game to help me reach this conclusion.
Perhaps the most exciting aspect of all this, is that I'm only just scratching the surface of this codebase: given FromSoftware have continued to improve and update this engine as the Soulsborne genre has grown in popularity. The same core engine tech was later used for Dark Souls 3, Bloodborne, Sekiro: Shadows Die Twice and most recently in the 2022 release Elden Ring, though it has naturally seen significant improvements to a myriad of its core functions.
The one outlier here is Dark Souls II, and it's reimagining 'Dark Souls II: Scholar of the First Sin', which was built using a separate engine that is assumed to have started as a branch of the original Dark Souls engine. However, further examination of its core by modders suggests it has been heavily modified and rewritten, to a point that many core features such as scripting, map editing, character control systems and more are fundamentally different. Meaning that while much of what is explained in this video could still be relevant to future games - and judging from what I've seen already from the fan community's work in decompiling Elden Ring, there is a significant chance this could be that case - it is most certainly not applicable to Dark Souls 2.
So to get started, I want to talk a little bit about the core AI engine and how any and all AI characters in Dark Souls are designed to operate.
Goals for Souls
All characters in Dark Souls, at any point in time, be they fodder, allies, merchants, enemies or bosses are built to recognise, establish and satisfy goals. A goal can vary in its purpose and gameplay complexity. Many of the simplest of goals, are ones that players will recognise throughout their time fighting non-player characters in Dark Souls: walking around their local environment awaiting the player, turning to face you, chasing you, and entering combat once in range, applying a variety of combat moves, only to then retreat and returning to the area on the map you first found them if you run far enough away. These are all goals. Even staying in position and standing idle is technically a goal. There are over 300 goals in the base game, plus another 30 introduced for the ‘Artorias of the Abyss’ DLC, though around 25 of those in the base game appear to be cut content or unused variants of specific NPCs - a point I will return to later.
Any Dark Souls character can, at any time, be assigned a new 'top' goal, which becomes their current priority, and it is then their job to resolve them. An NPC can decide whether to continue executing the current goal, or acknowledge success or failure in attempting to complete it and move on. This is a useful feature, given a goal may no longer be relevant to gameplay and should be swapped out. Like if a character has a specific attack goal to complete, but the player managed to get a hit on them - and in doing so interrupts them. Some goals are denoted as common, and are used by a variety of NPCs - often with their own interpretations of it - while many listed in the codebase are unique to a given character.
This process implies the use of a planning system, a topic we've explored many times over the years here on AI and Games. In fact our very first episode was all about the AI of F.E.A.R., which used a technique known as Goal Oriented Action Planning that searches for a sequence of actions to satisfy a goal. Each action carries preconditions, which are rules on whether it can be selected based on the state of the game. Once a plan of actions is built, it then translates the execution of those actions to a Finite State Machine. But Dark Souls is doing something quite different, rather it's operating more akin to a hierarchical planner. A hierarchical planner is built around the idea of a high-level abstract goal, which can be achieved by breaking the problem down into steps that will satisfy some or all of the original goals intentions, and then those steps can also be broken down further if necessary.
We've seen this in previous episodes of AI and Games through use of an HTN or Hierarchical Task Network Planner, notably my analysis of Transformers: Fall of Cybertron and Horizon Zero Dawn. HTN planners solve goals by using one of two types of activities known as tasks: a primitive 'task' that is simply one specific action in the game with its own preconditions, or a compound task which is multiple primitive or compound tasks put together - sort of like a macro of good actions in sequence. This is useful in that it allows designers the ability to craft sequences of actions that make sense to glue together, and declare them as a compound task. So during planning, the system will often start by using compound tasks that would be applicable in the game state, but they're still rather abstract, and then over time it is grounded into something much more thorough and practical ensuring it's safe to execute at runtime.
But Dark Souls AI isn't exactly an HTN planner, given it isn't deconstructing compound tasks into primitive actions, it's finding one actions to execute while also adding or removing new goals. As mentioned earlier, a character can be assigned a 'top' goal, but it can also have several subgoals running at the same time. The reason for this is that the top goal for NPCs are often incredibly vague. For example, the Ceaseless Discharge boss only has one unique goal: 'GOAL_Tadare525000_Battle'. In fact most top goals for a given character roughly says 'NPC type 'X' goes into combat', but the subgoals become increasingly specific. So each planning task doesn't just execute actions in the game, it also adds new subgoals that it must solve after executing the current task. It will do so by finding a new task it can execute that will address the subgoal.
So for example, an NPC in Dark Souls is in combat, and decides it will execute a dodge or a roll, but also adds a subgoal to block, and another subgoal to attack the player. It will then seek to complete the first subgoal once the dodge is completed, and then pursue the second subgoal. This allows NPCs to play more strategically when necessary. This also allows for combos of attacks and strategic movements, where each attack adds a new subgoal to continue the combo, but in execution the combo might behave slightly differently depending on what's happening in the current state of the game - a point I'll return to later.
And so interestingly, Dark Souls AI appears to adopt ideas from what is known as Hierarchical Goal Network (HGN) planning - a technique that rather than decomposing abstract tasks into concrete actions, it decomposes goals into subgoals and finds the correct actions to apply along the way. It's very similar, but Dark Souls doesn't decompose goals into subgoals, it just keeps adding or removing new goals based on the game state and the NPCs performance.
HGN planning is, to my knowledge, seldom used in games. In fact the only other game I know of that uses it is Ara: History Untold, a 4X game that is being released later this year in 2024 - though if anyone else knows of examples of this, do let me know in the comments. From my perspective, what is perhaps the most interesting aspect of this is that Dark Souls was released in 2011, and while HTN have existed since around 1995, the earliest published academic research in HGN planners dates back to around 2012 or just prior.
So in practice, for an NPC to resolve any and all goals provided, it will look for an action contained within its script files that can resolve it. All the while monitoring progress on its goals in context of the game state. An NPC may remove a subgoal, or even the top goal, given it may no longer be valid - so referring back to my dodging enemy, it might block, and then abandon the subgoal for the follow up attack because the player ran away and the attack isn't worth attempting. Alternatively, something in the game world may interrupt the goal. When this occurs, it will then assign itself a new goal. All of this is happening very quickly, with goals being added and removed frequently throughout play, and we'll dig a little more into some specific examples in a moment. But the key thing to appreciate, is that at all times, all enemies have a goal to satisfy, and for most the only way to truly achieve it, is to kill you.
Combat Wheels
So while each NPC is constantly adding, removing and resolving subgoals, there's one other aspect of this process that we need to discuss, given it's the one part of this codebase that makes Dark Souls AI so demanding to fight against.
Thus far, it all sounds rather straightforward: it adds new goals, it finds actions that can satisfy those goals and continues in a loop. Sure, that's more or less it in a nutshell, but if that were the case surely their behaviour would become increasingly predictable? Even if you provided dozens of different actions, if all it is doing is simply finding a task that satisfies the current goal, and then applying one more actions (and in turn new subgoals), then over time it would all become really obvious as to what it is doing.
But this isn't reflective of how Dark Souls plays. While many of them are quite predictable, others take much more time to understand. Despite most enemies, even bosses, only having a handful of attacks, it can often be difficult to learn attack patterns, given there is little consistency. An enemy may approach and start combat using one attack in one instance, and then a different one the next time. When players are in a stand-off waiting for an opportunity, it can still prove rather difficult to predict even with hours of experience playing the game. So what's going on here?
Each NPC has multiple behaviours it can execute in the codebase. Some are common functions for types of attack, while others are more complex, and both tell the system which actions to execute and possibly add or remove goals. But in many of these behavioural functions, the AI does three really interesting things:
Most actions and subgoals are highly sensitive to the current state of the game and so it will run very specific behaviours in certain contexts.
Many actions and subgoals are reliant on probabilities achieved using random number generator. So for example a combo attack might use different variations between steps, or end prematurely, purely because of a roll of the dice.
When multiple actions are valid in a given state and it doesn't know what to do, the game builds them into a probability distribution and then selects one of them randomly.
This is Dark Souls real secret: when it has several valid options to pick from, it selects one action at random. But the randomness is finely tuned by designers. To understand this better, let's look at an example.
Let's take a look at what is perhaps my favourite boss battle of Dark Souls: Great Grey Wolf Sif, who guards the gravestone of their former master, Knight Artorias the Abysswalker. Sif has five main attacks:
A horizontal swing of the sword.
A 360 sword spin.
An overhead swing where she gets on her back paws.
A backflip to gain some distance
And a charge attack which is not used all that often during combat.
If we take these 5 actions that Sif has available, we could just pick one of these actions at random (assuming they all satisfied the same goal, which for the sake of this example, we'll assume they all do). If we pick randomly, this would give each action a 20% chance to activate, totalling up to 100%.
Let's visualise this in what I will now call our combat wheel (above): each action has an equal chance of executing, given then they have an equal-sized chunk of the wheel. We then spin the wheel, and select the action the arrow rests on. This is a simple version of random selection, where each action has an equal share of the probability distribution.
But Dark Souls doesn’t split the wheel such that each action has an equal chance of success, the probability distribution is crafted so that some actions have more chance than others of being selected. So for example, if the player is within a certain attack range, it picks a probability distribution where:
Action1 now has a 45% chance of being activated
Action2 has a 40% chance
And the rest only have 5% chance each.
It still totals up to 100%, but the weighting on actions is now rather different. As you can see in the diagram, the first two actions take up a much larger proportion of the wheel than the remaining three, given they only have 15% of the space in total. The game the spins the wheel, and wherever the arrow lands, that's the action it selects.
But the reason this works so well in practice, is that the probability distributions are constantly changing. Every time an NPC makes a decision on what action to take, it builds a new probability distribution based on what's happening in the game. This includes things like how far away the player is, whether they're in range of a specific type of attack, if an item was recently used by the player, whether the odds of breaking the players guard has increased, the current phase of the combat, and much much more. So the roulette wheel is constantly changing as actions get a bigger, or smaller, slice of the pie, or sometimes they are removed entirely because in the current moment they're no longer relevant. It means that an NPC can technically run the same behaviour three times in a row, but given the randomness of the combat wheel, it plays out differently each time.
All of these probability distributions have been manually tuned by the games designers. This means two things in practice: first that they have worked out how and when certain actions are valid while ensuring they're not repetitive. But more importantly for players, it means you can implicitly learn the behaviours of these characters. They're not purely random, instead they're randomness is carefully structured. This is evident not just in how the community have successfully documented the behaviours of these characters, but how the very best Dark Souls players don't struggle against these bosses, given they trained themselves to learn these probability distributions implicitly.
This is perhaps most evident when we see players then force the AI to behave in a specific way almost every time, effectively cheesing a boss battle in a way that suits their playstyle. Given how complex a lot of these combat definitions are for each of the bosses, this is actually pretty hard to pull off, but a good example of this is the aforementioned Ceaseless Discharge boss in the Demon Ruins.
The Ceaseless Discharge has four main attacks, an overhead melee attack, a surge of attacks using his spider-like limbs, a sideways slash with his arms, and lastly a fire ability that is devastating if caught in its wake. Plus of course, it has a lot of other basic actions such as movement, approaching the player, turning around and simply waiting.
Now the key part is that the boss's combat wheel selection only really factors whether the player is within certain target regions of the map, and the overall distance of the player to the enemy. But it doesn't factor in the elevation of the player, and whether they are higher or lower than they were before. This is what allows for what is know as the 'stair melee' method, where players refrain from going all the way into the combat area, and instead kite the boss around the stairs so that it will try to attack them at the top, and then they run to the bottom before it can connect, making it much easier to dodge.
This wheel concept does have some overlap with the notion of Utility AI, which we've explored over on my AI 101 series. Utility AI is great for determining the value of an action or goal in the current context. So in Dark Souls, it's worth thinking of it as a utility calculation that gives the probability of that action being selected for the next spin of the roulette wheel.
Know Your Role
Okay, with the big technical part concluded, let's explore a little more of the underlying design of the game, and how enemies and other NPCs are built to exploit the framework I've now described.
Every single NPC that spawns into the map in Dark Souls has some kind of behaviour script and goals attached to it. This goes far beyond just the bosses and regular enemies, but the phantoms that players can spawn in, as well as the shop vendors like Domnhall of Zena in the Depths and other allies such as Solaire of Astora in the Undead Parish or Seigmeyer of Catarina who you meet outside Sen's Fortress.
The vast majority of NPCs will spawn in with the intent to eventually enter combat. Unless it's a boss battle or similar confrontation, NPCs always spawn with their top goal being to simply wait around for the player. They do this either by patrolling an area, standing idle, or run some sort of base animation. They're constantly trying to identify new threats, and will react to their presence by engaging their combat goal. They will then fight the player - using the mechanisms I've already described - and also know when - if at all - to back out of a fight. This also applies to the more friendly NPCs, who will transition into a combat mode if given reason - in fact all of them have their own combat scripts in the codebase, I found dozens of them.
But there are also two other modes in which an NPC will spawn. The first is what is largely considered as a 'spectator' or 'audience', they spawn into the map but are not built to participate in combat or be involved in core gameplay. Their goal is to simply run a simple animation or behaviour. These are NPCs that are typically set dressing within the game. A good example of these are the hollows you find near the broken altar to the Sunlight Covenant in the Undead Parish and also on the outskirts of New Londo. These characters can be killed, but don't react to the player in any meaningful way.
The final NPC category I discovered is what is known as an entourage type, these are NPCs that spawn alongside others, and are often subservient to them, and will defer to their leader when they wish to attack the player. That said, I can't speak with confidence in how this is applied in specific contexts.
It's worth stressing that the Dark Souls community have noted there are small but notable differences in the AI between the original Dark Souls, and the remastered edition from 2018. Pathfinding is improved, particular in key areas where enemies were more prone to fall to their deaths given they blindly follow the pathing provided, notably in the likes of the Tomb of the Giants. Meanwhile attack timings for certain enemies, aggro distances, and coordination has improved as well. Most of this is no doubt a result of modifying the parameters of behavours that were already established. Plus it appears that FromSoftware made changes to address obvious flaws and exploits, all while maintaining the mystery for players as they revisit Lordran all over again.
A Home for the Soul
It's also worth mentioning how NPC zoning works. Every non-player character is aware of their local vicinity, or more critically their 'home' location - the point where they spawn in according to the level data. The home location is useful both for ensuring a character spawns in the right place, but also that it knows where to return to in the event it is led astray by the player only to then leave combat. This home location is required to ensure that every enemy spawns where it should, not just for your first visit, but every subsequent visit to the area after you rest at a bonfire. Visiting bonfires resets all regions of the map so that enemies will spawn in fresh at their home location. The one exception to this is when you leave an area, and then revisit it without going to a bonfire.
The game only holds in memory the information needed for the active area of the map that players are exploring - and this is often broken down into sub-areas too. This is evident if you look across to a distant area only to notice there are no enemies or items spawned in. So when the player visits a given location, it loads all of the enemies, NPCs and items back into memory again. This makes sense, given we want to only maintain information relevant to the players current activity. Keeping NPCs in memory from over in Anor Londo while you're wandering around Blighttown is a tremendous waste of resources and would ultimately affect performance - an issue that Blightown already suffered from heavily in the original release of the game.
This process of loading in enemies on the map is actually the root of a quirky behaviour in NPCs that seasoned players will have spotted. As stated, if you've visited a bonfire prior to your visit to a map region, enemies spawn at their home location. However, if you left the area and returned to it without going to a bonfire, all dead enemies will appear in the position that you killed them. But when a character is spawned in 'dead', it does so standing up in its idle position, and then the ragdoll physics kicks in. As such you may have spotted that as you turn a corner and spot a dead enemy it flops in position, and that's because it effectively 'died' all over again.
Of course not all enemies respawn after death - mini-bosses, such as the Butcher in the Depths or the Black Knights in the Undead Burg and Undead Parish, have a Disable Respawn flag set in their parameters to prevent them from ever re-appearing in your current playthrough. This means that after death they never get reset to their home location, regardless of how many times the player visits a bonfire. However, unlike regular NPCs those enemies disappear entirely on death and their bodies never respawn. So while you don't see them, know that you're walking through these characters every time you wander past the point where you actually killed them.
Introducing NPC Variants
One last thing to dig into, is that while you will find many a character type throughout the world of Dark Souls, they're often broken down into much more specific classes or variants in the actual codebase. Each that maintain a whole range of different parameters for attack ranges, whether they respond to visual or audio cues, how far they will leave their home location, and much more.
If we consider the Undead Burg - one of the first areas of Lordran players should visit after completing the tutorial in the Undead Asylum - it is home to numerous hollow soldiers. But they're not all the same design, there are numerous variants of that wield axes, throw firebombs, crossbows, or carry both spears and shields. Plus there is a single black knight, and it ends with you facing the second boss battle of the game: the Taurus Demon. So let's walk through this area, and in doing I'm going to share more of the AI design in Dark Souls as we go.
We enter the Undead Burg by reaching the top of the stairwell to find two hollow soldiers immediately in front of us. One is wielding a sword and shield, the other an axe. Now while these are all more or less the same kind of character - they're all hollow soldiers - they're technically distinct and separate AI characters. Each variant has its own behaviour script, handling how that character should perform, and it's largely based on the weapons they have equipped. So while these are the first enemies look virtually identical, it's important to acknowledge that these variants and many others we're about to meet are technically unique AI behaviours in the back end.
Both are rather simple in behaviour and attack based largely on proximity and whether they have seen the player. Further ahead are two more enemies, the third NPC is across the short wooden bridge and throws firebombs at a distance - again another variant. This one however may react to any noise or commotion it hears. Some enemies are flagged to respond to nearby noises within a certain range, regardless of whether they see you. Enabling them to appear and catch you off guard - an idea we saw as far back as 1993 in my episode on the AI of DOOM. Meanwhile the fourth enemy is off to the left of the bridge, and is the same variant as the first, but will only react once it achieves visual confirmation. So already in the opening moments of the area, we have 3 variants that each behave slightly differently in attack patterns and how they react to the players presence.
Moving up the bonfire, we have more variants. Notably the crossbow wielding hollow who reacts to your presence first, and continues to shoot from a distance, never leaving their perch. Meanwhile three of the sword and shield variants appear between you and the crossbow enemy. Note that the sword and shield enemies move towards you when spotted, even the one in hiding, and can attack either with light or strong attacks, as well as combos. As mentioned previously, combos are actions that immediately have a subgoal added that say to continue the combo, with the final subgoal of attacking using a combo-closing attack like as shown here.
Meanwhile to the right is a new variant that wields spears and shields. These play more conservatively: they are not aggro'd lest approached, and prefer to wait long periods to attack and often try to maintain distance from the player where possible.
After passing the bonfire, there is only one new variant that is introduced: a hollow wielding a sword and even larger shield, which can alternate between short two-attack combos, or larger attacks. The rest of the Undead Burg in the build-up to the Taurus Demon utilises each of these enemies to its benefit, with the firebomb wielders attacking as you cross the short bridge, but only coming to fight you later if they're provoked. Meanwhile another crossbow wielder hides in the tower to catch you off guard, and more shielded enemies towards the end challenge your ability to break their guard.
The enemies faced in the Undead Burg are rather simple, which is to be expected given it's one of the games first areas. They seldom exploit the ability to block or parry, or many of them can't heal themselves either. But this combination alone is often enough to make a first-time visitor of Lordran be more wary of how to approach combat in future.
Speed Round
And so as I begin to bring this episode to a close, there's one final thing to do, and that's a quick speed round of all the other little facts that I just couldn't figure out where to put into the script. Let's go!
In the codebase, the weapon slots are encoded based on the PlayStation control scheme (L1, R1, L2, R2). Whether this is a relic from developing Demon Souls as a PlayStation 3 exclusive or simply it being the primary platform during development is open to debate.
In fact, enemies use items as attacks. They treat the usage of an item as a common attack, albeit without target or distance requirements. So yeah, be on the lookout for enemies that 'attack' you, by drinking from their estus flasks. In fact using items are non-interruptable goals, which is why attacking an enemy while they drink as Estus Flask or cast a heal miracle is super handy.
Even the Crystal Lizards, you know those wee critters that drop Titanite when you kill them, are tied into the AI system. When its 'battle' script is activated, it has one goal - LeaveTarget. So they just keep trying to run away from you until they've succeeded. Reminds of the rats in F.E.A.R. now that I think about it.
The cut goals from the original game suggest that the Black Iron Tarkus, an NPC white phantom you can summon at Sen's Fortress, may have originally appeared later in the game as a Red Phantom in either Anor Londo or Lost Izalith. This deviates from the established lore, where his body and armour can be found in Anor Londo, mere feet away from the entrance to the Painted World of Ariamis.
Reading through the logic, it suggests multiple Black Knights were also cut from the game. Which is... maybe a good thing? Those guys are nasty sometimes.
The Combat Wheel system I described doesn't just influence the selection of attacks. Sometimes the wheel is used for different ways to run the same type of attack, only changing its parameters. I found looking through the AI scripts of the Mimics, that they can run the same attack in 5 different ways, with different values for attack distance, approach distance, dash distance and the odds of their poise being broken.
As mentioned earlier there are separate logic scripts for the different hollow variants in the Undead Parish. I found numerous versions of this same pattern appear elsewhere, notably for the Balder Knights in Sen's Fortress, and the White Knights in Anor Londo.
But also, this practice is used to allow for different buffs and even different behaviours depending on location. So for example, the snow rats in the Painted World of Ariamis have a separate configuration from the small rats you encounter in the Undead Parish and the Depths - even though their behaviour is identical. This separate config allows the snow rats to deliver toxic build-up instead of poison. Meanwhile the large and giant undead rats in the depths have unique behaviour configurations. The one exception to this rule, based on my understanding of the logic, are the Titanite demons, which all behave the same way when they appear in Darkroot Garden, Sen's Fortress, Anor Londo, The Catacombs and Lost Izalith.
And lastly, named NPCs have different configurations based on where they appear in the game and how you interact with them. So for example Solaire of Astora has two different sets of behaviour logic: one for if you attack him while he's chilling out in the open world, and another for when he's called in as a supporting phantom. I found similar logic for Knight Lautrec as well. Plus virtually every passive NPC that you can attack in the game has its own corresponding combat logic, be it Oswald of Carim, Griggs of Vinheim, Havel the Rock and even Rhea of Thorolund and Quelana of Izalith.
Closing
The AI of Dark Souls is a curious beast: what may seem simple, bordering on random in its composition from the outside, hides something with mercurial complexity. It's safe to say that I have only scratched the surface of this, and I could spend hours digging into the minutiae of each boss, but I felt that this piece should provide an accessible, high-level overview to what is really happening inside the Soulsborne AI architecture.
Long-time viewers will know that Dark Souls has held my interest for many years prior to now, and was the subject of not one but two episodes of my Design Dive series looking at how the design of the game promotes a particular philosophy towards player engagement and education. Links to the episodes on Dark Souls, and Dark Souls II: Scholar of the First Sin are provided, with the next entry of this analysis focussed on Bloodborne coming soon.
Super useful and interesting analysis. I wonder if there is some ressources to see how designers implement the "percentage" of each attack based on condition. I have some difficulty to visualize how it can be achieved from a data point of view (without being a nightmare)! Thanks!
This article not only showcases the technical details of Dark Souls as a classic game but also delves into the operational principles and design concepts of its AI system, making it suitable for readers interested in game development and AI.