AI Agents and Their Environment

Computer game AI cannot be designed or developed in a vacuum . For a game AI to turn out well, it needs to be developed in close association with the game s gameplay and the environments in which that gameplay is going to take place. The simple fact is that no AI agent is going to be smart enough to prevail in all situations. While an AI may be exceedingly good in wide-open spaces, when it is thrown into a narrow canyon it will encounter problems its programmer never anticipated. If the AI programmer comes up with an AI that can handle the confined spaces, chances are it will not be as successful out in the open . The best one can hope for is that the AI has a fighting chance in a specific type of gameplay situation. If the levels and AI are not developed synchronously, then there is little chance that the opponents the players face will appear very smart at all.

This creates special problems in terms of how to best produce a game. Level design is often one of the last tasks to be carried out on a game, before it goes into final balancing, then testing, and finally ships. Similarly, AI is usually only worked on after the core engine is firmly in place, most of the mechanics for the player s movement are fully functional, and many of the other more critical programming tasks are mostly complete. Now, if the same person who is designing the levels is also creating the enemy AI, it might be simple to integrate the development of the two, but this is rare if not unheard of in modern game development. As a result you have two teams ” the programmers and the level designers ” working in parallel. Unfortunately, the usual case is that each charges forward with their work without fully considering the other. The level designers do not have the AI yet, so they cannot tailor their levels to support it. It is just the opposite on the other side of the equation: the programmer does not have the levels yet, so it is hard for him to make an AI that will function well in those levels. The situation is a catch-22. Once the levels are done in terms of architecture, the AI is finally added to them, and then it turns out that one or the other needs to be radically reworked if the game is going to be any fun. In the worst-case scenario there is no time to rework either the levels or the behaviors, and the gameplay ends up suffering as a result.

Of course, the level designers will protest that the AI should be designed to fit the levels they create. And, similarly, the AI programmers will complain that the levels simply must be reconceived to work with the AI they developed. Since I have worked as both a level designer and an AI programmer, I may be in a special position to arbitrate this dispute. In my opinion, neither party is entirely right, and a little give-and-take is required on each side. I would advocate trying to make a simple, playable AI first. It does not need to be bug free or work perfectly in every situation. If it works fairly well in some situations, level designers can start making levels that facilitate what the AI is known to do well. As the level designers take this direction, the AI programmer can keep working on his AI, getting rid of any bugs while always keeping an eye on what shape the game-world is taking. The AI programmer must communicate to the level designer when he sees a problem emerging in a level, such as a situation the AI is unlikely to handle well. At the same time, the design of the levels may give the AI programmer new ideas about what tricks the AI can pull off. Maybe ledges start showing up in the game-world that would be ideal locations for snipers. Or perhaps the structure of the game-world s architecture is suited to coordinated team movements. If the AI programmer can then add functionality to his algorithms to allow the agents to identify these locations and behave accordingly , the AI will become stronger as a result. Both sides of the designer/programmer equation must be ready to compromise. Often a designer may have to compromise for the good of the project, modifying something he may like as is but which horribly confuses the AI. Similarly, the programmer may need to add some ugly special-case code to accommodate a problem that occurs in a majority of the maps that have been created. The designer and AI programmer must trust each other such that when one of them tells the other something needs to change, they believe the other and make it happen.

Getting the AI agents in Damage Incorporated to work properly required many changes to the levels.

For example, in my game Damage Incorporated , players are responsible for not only controlling their own character, but also for directing four teammates in a 3D environment. When I was working on that game, one of the greatest challenges I encountered was getting the teammate AI working in a way that appeared intelligent to players. Fortunately, I had a rudimentary form of this AI working before any real level design began . This way I realized ahead of time that the teammate AI would not be smart enough to jump or swim to areas. This meant that the levels had to be designed accordingly, or the teammates would not be able to reach the end of a level with the player character. Also, the teammates performed badly in tight, constrained spaces, often running into each other or blocking players progress. The levels had to be made with large, open areas so that the AI agents could have a decent chance of performing well.

But even with foreknowledge of the sophistication of the game s AI, once Damage Incorporated entered testing, endless problems arose with the AI. The teammates constantly seemed to be able to get wedged in tiny little spaces they were not supposed to enter. The end solution turned out to be about 25 percent code fixes and 75 percent reworking parts of the levels to eliminate the little nooks into which the AI agents jammed themselves . There were countless sections of levels that I had wanted to look a certain way but that needed to be scrapped because the AI simply could not function in those areas. I was sad to see those sections go, but not as sad as players would have been when they managed to get a teammate stuck in a crevice. The AI and levels had to work together if the final game was going to be any fun to play.

In The Suffering , I had a much smoother experience getting friendly AI characters to navigate through the game world, though a few snafus arose. It was not originally in the plan to have the human characters be able to climb ladders, open doors, or jump across chasms. As we built the world, we realized that there was no way around getting them to navigate the ladders. We had relatively few scenarios where it was necessary, but there was no way to easily remove them or to script or can the AI agent s ladder movement. Without the ability to open and close doors, the AI agents simply looked too dumb when you slammed doors in their faces, so we ended up adding that as well. We had a few cases where NPCs were going to need to jump across small gaps, but we quickly realized we did not have enough to justify the programming involved in getting the NPCs to jump. Analyzing the situations where jumping was required, we were easily able to rework areas to eliminate a few jumps . The ones we could not remove, we were able to solve with a scripted jumping action for the NPCs that could be performed in those spots only. This required some tedious debugging on the design side, but in the end was much simpler than implementing a general-purpose jump behavior.