Stolen Designer Diary #4
Blue52 AI programmer Alex May talks about the trials and tribulations of working with Stolen's security guards.
We'll begin emailing you updates about %gameName%.
When we previewed the stealth action game Stolen earlier this month, we noted that the security guards we were up against in our role of a thief were believable and worthy adversaries. In our latest designer diary for the game, artificial-intelligence programmer Alex May explains the goals that he and his team had for Stolen and the different ways that they've gone about achieving them.
By Alex May
AI Programmer, Blue52
I work on general artificial intelligence (AI) code along with two colleagues. I rejoined the Stolen AI team sometime last year to help nurse the guards in the game through some of their more formative years. By this time, much like the troubled teenager, the guards had more or less everything necessary to be fun adversaries, but it appeared as though they weren't quite sure how to conduct themselves. Since then, like three dads, we've tolerated the tantrums, passed the difficult moments, and dealt with the embarrassing discoveries in the Stolen AI to raise what appears to be a fully grown, functioning member of the game.
I'll be honest with you: The acronym AI isn't really applicable, even though I'm going to keep using it because it makes me sound all cool and that. What we've done with Stolen's guards, while it is certainly artificial, isn't intelligence. We haven't used neural networks or machine learning to emulate the adaptive brain processes of security personnel. That might suggest that the code is pretty simple, which isn't true. What we've done is take many standard methods and mesh them together to make behaviour that, while it can sometimes be very convincing, conforms to the game design and isn't unpredictable and above all makes the game fun.
One of the main problems with developing game AI is dealing with the increasingly complex systems that have been created. Debugging AI code can be a nightmare, which isn't made much easier by the difficulty presented by reproducing the circumstances of some bugs. It also isn't made any easier by the many systems we've put in place all interacting and vying for control. Such things are sent to test us and can only be expected in a game that's been in development for as long as Stolen has. One of the things that keeps me going, as I imagine myself crawling underneath barbed wire with shards of twisted code flying past my face, is what the testers must be thinking when they find one of these bugs. When we get bug reports from the publisher, they're often very usefully accompanied with a video capture of the event. These usually end with a guard doing something totally crazy like bending at right angles from the waist while trying to run round in circles near some stairs, and Anya standing there watching them in a disparaging fashion for perhaps five or 10 seconds, as if to say, "Why would you hire people like this to protect your prison?"
Coming back to the earlier point about predictability, it's important that the AI reacts to the player in predictable ways so that the player knows how to interact with them. Had we made the AI too realistic, we'd more than likely be faced now with either AI that was impossible to beat or AI that was too unpredictable to be fun, or perhaps even both. The design department has been instrumental in this process, having been given the ability to alter certain things about the guards through a property system we provide for them. This enables them to tweak how far the guards can see in different light levels, for example, so that the game is still fun. The coders would probably have gone, "Oh, well, in full light, we can see all the way to that wall there. So why shouldn't the guards be able to do that? I'll just set this visibility distance to...500 meters." So we let the designers decide what's fun, seeing as that's their job, and we enable them to do that, seeing as that's our job.
Feedback to the player is important. As I mentioned earlier, if the player can learn what the AI will do or is doing in different situations, they'll know in the future how to deal with that, which is probably more fun than trying to fathom why the guards are eating their own torches and pointing at stuff. That's also useful for debugging purposes, so we used to have icons above the heads of the guards. You can still find screenshots with these in them, because they were so good at helping the player decide what to do that we were going to keep them in when we released the game. In the end we took them out, partly because they looked out of place and didn't really fit in with the game's ethos, and partly because we found that we could use speech to convey this information much more effectively. In Stolen the guards will converse with each other, directing each other to search in different places or just having a chat on their patrols. When your AI units begin talking to each other, you suddenly find yourself wondering how you managed to get this far. It's really atmospheric.
A few weeks ago we got an e-mail from one of the designers, who'd been holed up in a vent and was teasing a guard by whistling. "What was that?" said the guard as he looked around. A second whistle prompted "I heard it again!" and a search where the guard thought the sound had come from. By the time the third whistle was issued, the guard had already stored two noise events and was becoming suspicious. Reaching for his radio, he called in to his controller: "I'm still hearing noises down here!" One last time was too much for him. He radioed in for backup, and the guards searched the room thoroughly. Of course, we all knew the guard would do this; the designers specified it and we coded it. But the best thing was that even though we knew that, it was still cool to see it happen from a player's perspective. And you can't really ask much more than that.