Matt Rice, Software Engineer, AI : We originally started off Condemned 2 with a key goal of adding more variety to the combat.  We did this in a few ways - by expanding the players potential attack options, by expanding the sheer number of AI types and by expanding the base AI’s behavior set.  A “behavior” is an atomic action that an AI may make, be it swinging a pipe, recoiling in pain or running to hide.  At Monolith, one of the AI Engineers’ main responsibilities is creating, assigning and managing the many behaviors for each character.  The technology we’ve created has made it a simple process to move behaviors from one character to another.  Want the dog to block melee attacks (we don’t…but if you did), just drag and drop that behavior into his behavior list.

The base AI, which from here out I will refer to as simply the “Thug”, is the typical character the player fought in Condemned: Criminal Origins and is still the bread and butter of Condemned 2. He may have many looks (he may even look female), he may be carrying different weapons, and he may play many different attack and recoil animations, but from the AI Engineers’ point of view they are all the same character. The thug was pretty solid in Condemned: Criminal Origins and we found that engineering didn’t need to do much to him for the sequel. He got an entirely new animation set, new character models, new sounds, but not many new behaviors. What new behaviors he did get came as a direct result of the expanded player options.  The new thug needs to respond correctly to broken limbs, being lit on fire (in numerous and fun ways) and how to throw things at the player.

Creating entirely new AI types is really the fun part of AI Engineering and it is an incredibly collaborative endeavor.  The process typically starts with our Lead Game Designer (Frank Rooke) riffing off a piece of concept art he has received.  He comes up with a few baseline actions he wants the character to make. He then sits down with the Lead Animator (Richard Lico) and me to see what can and can’t be done.  While looking at the concept art for the Burning Rioter, it was pretty obvious what we needed him to do.  The dude is on fire, he isn’t going to make it and he knows it.  The Rioter is simply running after the player and attempting one last grapple attack before his own fiery demise.  At this initial meeting, we agree on a core behavior set and see if we can find any holes in his design.  What happens if the player avoids the attack?  What happens if more than one Burning Rioter attacks the player at the same time?  Can he attack other AI as well?

With plans in place, many departments may begin working on the same character at the same time.  Character Art starts modeling, animation gets someone in a funny suit for motion capture, our FX artist starts looking at burning Tibetan monks for fire reference and the Audio Department will start screaming in combustible pain into the microphone.  I will start out by creating the base framework for the characters behaviors.  As AI Engineer, I start by copying a relatively similar character and trimming behaviors he doesn’t need, like throwing weapons or hiding, and adding behaviors he will need, namely, a single sprint to player that results in either a potential deadly grapple or a painful to watch burning for our friend the Rioter.

This part is fun not only because it is both challenging and rewarding to see such plans come to fruition, but also because…well…it can be quite entertaining.  After my initial implementation, I need to verify as much of the code as I can so that when final assets are delivered from the other departments they will simply drop in with no problem.  So I have to pick the best (or not) of the currently existing assets to use as stand-ins.  At this point, the Rioter looked an awful lot like the thug.  Animation wise, he “ran” towards the player with the limp of a broken leg and if he failed to grab the player he would not so much writhe in pain as much as jump and down as if he was at a hip-hop show…then die.  If he succeeds in grabbing the player, he would invert himself upside down and seemingly try to hug the player to death.  Instead of being on fire, he became a fountain of puke, an effect that we have so many variations of.

Along the way we will continually test the character to make sure he is fun to play against and fits the theme of the game.  When near-complete, the character is given the green light to be placed by the Level Designers in their levels.  What once seemed like a slam-dunk in our test levels may end up playing not so well within the context of a full production level.  More than once we’ve had to re-visit characters that were mostly done and had to re-design, scale back or simply cut them altogether.  This can be painful for all involved, no one likes seeing days or weeks of their work scrapped but characters that are no fun to fight can really bring the player down and generate distaste for the game.

Right now, we are pushing hard towards final Beta and I find myself splitting my time between fixing mundane but import bugs and making exciting last minute revisions to characters before we lock in the code and finalize the game.