Dean Tate is a Senior Designer at Harmonix. Immediately previous to his time here at Harmonix Dean worked on Bioshock and Bioshock 2 - specifically working on AI and level design. Seeing an opportunity, I decided to have a Q&A with Dean. The questions here primarily focus on Bioshock's AI and their integration Bioshock's levels - I think this aspect was particularly well done in Bioshock. I hope you enjoy peeling back the curtain a bit to see how it was done and what was learned.
Sylvain: How much of the AI in Bioshock is scripted versus autonomous?
Dean: A great deal of our AI was scripted but we worked really hard to somewhat mask that fact. In a lot of games, it can be really obvious when an AI is scripted versus when an AI is systemic. This is something we really wanted to avoid. In a lot of cases, this just meant exercising some restraint; one thing that can make scripted AIs appear to very obviously be scripted is when they display some whacky behaviour that you never see the systemic AIs use. So for example, Splicer AIs in Bioshock take cover, but they don't use cover animations. So we avoided having situations where the player would enter a room and AIs would be scripted to be laying in wait behind cover and then pop out and attack. We wanted consistent behavior between our systemic and scripted AIs.
We also worked really hard to blur the line between 'scripted' and 'systemic'; our AI scripting system, with enough designer crafting and tweaking, could very gracefully handle having an AI that is scripted become systemic without players noticing the transition. It also allowed players to intervene and affect when that transition occurs. Dealing damage to an AI for example to stop it from continuing down it's scripted path. I think everyone on the level scripting teams took great strides to use this ability to great effect and avoid crafting situations that were very obviously scripted. Scenes that occur behind bullet-proof glass, for example.
Sylvain: What kind of high-level (and low level) systems were used for AI thinking? How did you interact with the system (did you manipulate data or edit script logic or just go into code)?
Dean: I didn't touch the low-level code at all, which was all handled by our AI Programming Lead, John Abercrombie. A lot of our AI system was hard coded; things like how our ecology functioned and how AIs viewed each other, AI abilities and weapons functionality and behaviour, etc. Getting those things right was just a process of heavy collaboration and back and forth iteration. At a level above that, I had access to and could tweak all of the numbers that affected discrete AI behaviors. Things like AI movement parameters, attack parameters (how often an AI attacks, how far from the player it tries to remain, under which conditions it will initiate different attack and movement behaviors or weapons, etc). I did all of this by manipulating data in text files. Very high tech stuff (snort). Experimenting with changes to an AIs behaviors was quite a laborious affair that involved (if I remember right):
-Opening the correct text file
-Finding where I wanted to make a change to the text file data, and then saving the file
-Closing the file
-Running our level editor, and opening up one of my AI testing levels
-Tweaking a set of scripts so that they're spawn the correct AI (the one I had changed) when the level ran
-Baking the level content and data changes to a testkit
-Testing my changes to see if the desired effect had been attained, often while making sure a bunch of debug info was being displayed so I could be sure I was seeing the effects of my changes.
-Rinse, repeat
Each of these steps was important. For example, if I made a change to a parameter in the text file and then forgot to save and then close the text file before testing the change, the change would not take effect (I remember this because I made this mistake all the time!).
Things could and would often go wrong, and I'd need to repeat the entire process. I also sometimes ran into what I called "Placebo Parameters": parameters that were supposed to effect AI behaviors, but that in fact hadn't been hooked up yet in code (or, more often, weren't working because of a newly introduced bug). I'd tweak the value over and over again, checking the effect it had on the AI's behavior, stroking my chin and thinking "that didn't seem to make a difference...", tweaking the value some more, working towards getting the desired effect, before finally realizing "Hey! This isn't actually doing anything!" The lesson learned was that when a programmer gives you a new value to tweak, you should first set it to a minimum or maximum value and test it out; then, you can be sure it is doing what it is supposed to do.
And then, at a level above my base behavior editing and tweaking, level designers had some control over AIs through the use of our scripting system. The ability to initiate or cancel specific behaviors, toggle behaviors on and off, give AIs movement and navigation orders, etc.
Sylvain: Wow that's quite a long process for each change! How did you deal with changing an AI's behavior and making sure that it didn't mess up how they worked in all the other areas of the game?
Dean: It was quite a laborious process. When you're making incremental changes to any system, you want to make one change at a time, test it, make another small adjustment, test it again...making large sets of changes all at once makes it much harder to catalogue the effects of each individual change.
Making sure that changes didn't have unexpected knock-on affects was tough. Whenever large sets of changes were made I needed to make sure that our QA and Design teams were well aware of the changes and kept an eye out for abberent behaviors. Designers would focus on making sure any scripted sequences they had already implemented didn't become broken (thankfully, this didn't happen often) and QA would make sure that interactions between our AIs and other game systems (weapons, plasmids, etc) didn't become broken.
Sylvain: What kind of perceptual model did the AI use? What were the main parameters you had control of?
Dean: Wow, I'm remembering some pretty old stuff here. It's been years since the game was released, so I hope this is all accurate. To the best of my knowledge, it is.
The most interesting fact about our perceptual model is that Big Daddies are essentially deaf and blind. They have very little need for any sort of perceptual model up until the point that they have a target to attack. If that target is the player, than they will employ vision if they lose sight of the player; however, their vision is essentially 360 degrees and very long range, so basically if they lose the player they'll try to get within line of sight and then continue to attack. So if you think it's hard to lose a Big Daddy once it has started attacking, now you know you're not just imagining it.
Sylvain: I'm assuming then that they has a simple timeout after which they stop looking for you?
Dean: That's right. If I remember correctly, once a Big Daddy has chosen a target to attack, it won't return to a neutral state until the target is dead (this includes the player). Splicers are different. They will pursue a target they have lost sight of, and eventually lose interest and return to a neutral state. This happens after a timeout period that kicks in once the AI has lost sight of the target and then traveled to the target's last known location (AIs hold absolute knowledge of a target's location for a few seconds after they lose sight of it)
Our splicers used a perceptual model that is extremely similar in design to that used in other Irrational and Looking Glass games such as System Shock 2 and Thief, only tuned differently. Splicers are much more aware in general than their counterparts in those games, and when it comes to vision, hiding in shadows is much less effective for the player (splicers will have a harder time spotting you than when you're out in the open, but not to the degree that they do in, say, in Theif 2).
To go into a little more detail, splicers rely heavily on vision. They have near and far forward facing vision cones that have quite a narrow arc. If the player falls within these cones, it'll take the splicer some time to notice their presence. The amount of time is based on factors such as lighting, as mentioned, and the amount of the player's body that is obscured. The splicer will notice the player more quickly if the player is within their near vision cone, and longer if the player is standing within the far vision cone.
Splicers also have peripheral vision cones. They have peripheral vision in an almost 180 degree forward facing arc. If a splicer sees the player in their periphery, they will exclaim "Hey what's that!" and turn to face the player, putting the player squarely in their forward facing vision, giving them a chance to actually spot the player and then attack, unless the player reacts quickly enough to duck out of view before this happens. This was a tricky thing to balance; we wanted our AIs to be much more aware than in previous games, but still wanted situations to occur where it didn't feel like they were so absolutely aware of the player's presence at all times that there was no middle ground between "neutral" and "attacking" (for example, it didn't feel good to have a splicer immediately attack a player that it had spotted in its periphery).
Splicers also have backwards facing vision cones. If you sneak up behind a splicer, it won't hear you coming; it'll literally see you coming, because it has eyes in the back of it's head. This is spooky as hell and you will now have trouble sleeping tonight.
The tricky task I had in tuning splicer vision cones was in hitting some numbers that worked well in most situations across our game. All of Bioshock's levels are quite different from each other, and there is much environmental variation; large spaces, cramped spaces. Brightly lit caverns and dimly lit closets.
Finally, sound and hearing played a lesser role in splicer perception. Sounds could be tagged as "investigative" and given a radius. If a splicer hears one of these sounds, and it's source is in LOS, they will turn to face it, at which point they're relying on their vision cones to spot a possible target. If they hear one of these sounds and it's source is out of LOS, they will path to its location while always facing the source, and again, vision becomes key.
Sylvain: How did you handle spawning of enemies that wander around the world?
Dean: Bioshock levels are chopped up into regions, each of which has a desired population level that is split along the ecology lines; protectors (Big Daddies) and aggressors (Splicers). That desired population level is in most cases satisfied with scripted spawns or initial spawns when the player first enters the region; the player will enter the region, and it'll then be filled with AIs that spawn at designer-specified points and then do what they're told; either designers tell them to follow some scripted behavior, or the AI will do something systemic. Splicers will patrol (patrol points and paths are designer crafted), Big Daddies will seek out Little Sister vents, and then escort their Little Sister to dead bodies that hold Adam. We called these bodies "booty". Booty can be designer placed, or be dynamically spawned when a splicer dies.
When a region's population drops below the desired level, our population manager takes over. It'll wait a designer-specified amount of time before spawning in new enemies, and it'll spawn them at points which the level designer has specified. These points hold a bunch of variables that designers can change; enemy archetypes spawned, the chance for each type to spawn, and patrol path assignment. The system is actually quite simple, and very similar again to the spawning manager used in System Shock 2. Designers could tune spawning manager variables for each level, and for each region in a level; so there can be regions that have a high respawn rate, or a low respawn rate, differing population levels, etc. We used this to make some areas feel more dangerous or "busy" than others. Because every level designer could tailor-tune the system for their own specific level, we needed to develop some ground rules and best practices to ensure the system was somewhat consistent game-wide.
Sylvain: Did you have any strategies to avoid enemies killing each other when the player wasn't nearby or was this not an issue?
Dean: I'm a little iffy on the exact details of the LOD system we had in place (LOD stands for Level of Detail). I think it was something quite simple: AIs would deactivate their attack behaviors if they fell outside of a certain range of the player. The design also didn't really allow for random battles to break out amongst AIs unless the player was already close-by; in fact I don't think they can break out randomly. This could happen at some point reeeeeally early in development, and it basically created mayhem and chaos and an ecosystem that was impossible for players to understand. They would always end up coming across either battles in progress between Big Daddies and Splicers, or, much worse, rooms full of dead bodies. The former was bad because it made it very difficult to telegraph to players that Big Daddies only attack when provoked (which had been something quite unheard of in this genre), and the latter was worse because it made encounter pacing an impossible task for designers.
Sylvain: Finally, how did the AI evolve through the project and what lessons did you learn?
Dean: Our AIs evolved massively over the course of the project, though the basic archetypal foundation of each individual AI remained intact almost from day one; the grenadier (Nitro Splicer), assassin (Houdini Splicer), ranged aggressor (SMG Splicer, Pistol Splicer), melee aggressor (Melee Thug), the gatherer (Little Sister), the protectors (Big Daddies); we settled on the behavioral basics of each of these guys very early on, and then over the course of the project iterated on the details of their behaviors massively.
The Big Daddies are a good example of this. Early on, we intended to make these guys hulking, lumbering masses of muscle and power, and we stuck to this goal quite literally for a very long time. Their movements were very slowly, they had delayed reactions, were easily outran, their attacks were hugely damaging but had a long windup period, etc. As the game evolved from a slow-paced stat driven fps/RPG (that's rpg IN ALL CAPS!...fps in low caps...) into Shooter 2.0 I pushed to make our Big Daddies much more agile and reactive once they had become aggressive. I wanted there to be a clear difference between "neutral and mellow" and "angray!". I really enjoyed seeing player reactions to the huge behavioral switch that came when a Big Daddy decided that it needed to defend its Little Sister. "OH GOD, I THOUGHT THEY WERE SLOW!" players would scream, as a Bouncer smashed into their face with the speed of a freight-train, or a Rosie became impossible to outrun.
Another example of design aimed at "sticking to your base and iterating on the details" is the grenadier (AKA the Nitro Splicer); we knew early on that we wanted an AI that threw explosive projectiles. That was the basic design (and totally original, right guys?). As time went on, we layered more interesting behaviors and system interactions on top of this design base to make this AI more interesting; the grenadier gained the ability to throw Molotovs, to drop smoke grenades like chaff when retreating, and let loose a devastating kamikaze attack. Players could also catch their grenades by using the telekinesis plasmid.
Starting with a simple yet strong design base was I think in the end a very smart move (I'm not taking credit either; I very much worked on the details of each AI, but came into the project once they already had a strong base laid out). Though the basic design for each AI archetype wasn't exactly imaginative or completely original, we managed to create something fresh with each archetype by living in the details. This meant little wasted work. In fact, we shipped with almost every AI archetype that was originally conceived and designed, bar one Big Daddy archetype that made it very far into production before being cut; though you may see him re-appear sometime in the future, *wink*.
I'd like to point out one interesting thing that came out of the design process; these days, a lot of good AI design is focused on ensuring that AI states and behavioral intent is fed back to the player clearly, usually through the use of VO. Basically, AIs will scream out to the player what it is they intend to do. "I'm hiding!" or "Here comes a grenade!" or "Take cover!" or "Flank him!" or whatever. Our AI VO writer (and Audio Director) (and fellow Australian) (and my best mate!) Emily Ridgway pushed against this idea from very early on. She made the stylistic and creative choice to use our AI VO to help sell the idea that each splicer is a twisted, ruined husk of a person. A lost mind overtaken by dementia, paranoia and confusion. They're not battle-hardened soldiers employing military tactics against the player; they're lost and scared and want you to go away. And so, when writing lines for our splicers, she made the conscious decision not to have them clearly state their behavioral intentions. This was met with quite a bit of resistance, which I'm glad wasn't successful. I'm quite happy with the idea that in Bioshock, you never quite know what a splicer is thinking or planning...
I feel like I should end my response to this question with one big overarching "lesson-learned".
Let me think...
I know!
If you're going to end your game with a fight against a giant naked bronze man, you better really mean it.
