Step One: Document The Problem

This paper argues that the primary reason that AI problems persist is process-related, not technical and argues that significant progress can be made by documenting common problems, studying examples, using traceability grids, developing task-specific behavior capture tools and adhering to a common information capture format. 1. The Life of an AI Developer Game development is hard work. And my belief is that, out of all the developers, the AI programmer has the toughest job. Not because the problem itself is hard but because the AI developer receives so little support. Until recently, there was no book or journal they could turn to for help. Their peers are discouraged from sharing information, worrying (quite legitimately) that AI is a competitive advantage. Unlike their teammates, they have no quantitative measures such as frames per second, no benchmarks similar to 3DMark, no standards equivalent to OpenGL or BSP and no standard tools such as Maya. AI developers don’t even have a good description of the problem they’re trying to solve. More often than not, each studio is forced to slay the AI problem alone, armed with little more than their personal experience. I believe there’s a better way. 2. We Do Not Understand AI Problems A recurring theme in this paper is that we do not know nearly enough about the problems we are trying to solve. What does good AI look like? What does an AI problem look like? What capabilities should an AI have? What are the most important capabilities? Which areas are being researched? Which areas are being ignored? How many AI problems are in an average game? How much progress has been made? How many problems are unique to a game? What percent of problems are common to a genre? Which problems are the most important? The answer to all of these questions is, we simply don’t know. In life, we learn by experiencing varying situations first and constructing models second. We divide experiences into categories, look for patterns and construct beliefs, but only after we are familiar with the details. When a solution is created independent of the problem, the solution is not grounded in reality. Yet a review of several dozen peerreviewed papers turned up less than a handful that gave a single concrete example. Only three attempted to define general areas of game AI. And only one attempted to analyze real problems. And it was written by a military officer bemoaning the lack of realistic work being done by modeling and simulation students (Marshall et al 2003). Does anyone know what an AI problem looks like? An Internet search turned up one group that does – customers. Their laughs, frustration and disbelief can be found scattered across newsgroups, forums, game reviews, FAQs and strategy guides (see, for example, (Civilization Fanatic Center 2004)). The bad news for researchers is that these comments are hidden across the Internet, making the use and just-in-time collection of this information difficult. In an effort to further my own research, I created a database to store examples of common game AI problems. Over the last year, I have collected several dozen problems which I have divided into 14 basic categories (learning, decision making, etc.) and further subdivided into several subcategories (discrimination learning, relationship learning, learning by observation, etc.). Studying these problems lead to many of the beliefs that follow. 3. AI Problems Are Design Flaws, Not Bugs User forums often debate topics such as “which game has the worst AI?” (e.g., Slashdot 1999). The problems most ridiculed are almost never specific to one game. For example, in many first person shooters, the monsters are in a frozen state until they see the player. If you can see a deactivated monster and it does not see you, you can attack the monster and it will scream, thrash around and eventually die, but it will not attack, hide or run away. Players who noticed this problem in Doom were quick to look for (and find) this exploit in later games such as Heretic, Quake and Half-Life. A similar problem exists in the Baldur’s Gate series of games. Monsters are in a frozen state until they are drawn on the screen. They cannot act, but they can take damage. Many FAQs and strategy guides recommend using the area-effect tactic. The player gets close to the unseen enemy and then, because they cannot target an off-screen character, uses a spell that affects an area rather than a monster (e.g., cloudkill, ice storm, etc.). This is repeated until the enemies die. If the player’s team runs out of spells, they go to sleep, memorize new spells and tries again the next day. It’s not like the monster’s going anywhere. Problems like these are well known, exist in multiple games and affect some very respectable titles. For example, the “enemies don’t react to pain” problem exists in both Half-Life and Baldur’s Gate II: Shadows of Amn, both of which won Game of the Year and both of which were praised for their cutting-edge AI. There are many problems like these and they span games, developers and genres. For example, groups of agents cannot move through doors in Counter-Strike (a first person shooter) and Planescape: Torment (a computer roleplaying game). Agents continue to attack enemies with weapons they know will not work in Baldur’s Gate, Civilization and Total Annihilation. The computer will consistently use a path they it knows is blocked by undefeatable enemies in Ages of Empire, Unreal Tournament, Civilization, Counter-Strike, Warcraft, Hitman and Myth. Running in front of an ally’s line of fire, inability to see through windows, choosing wildly inappropriate spells, picking fights that it knows cannot be won, moving and attacking as individuals rather than as a group and others can be found in most games. 4. AI Problems Are Persistent If there is one thing more frustrating than seeing the same problem over and over, it’s seeing it year after year. It’s almost certainly true that the average developer does not have enough time during development to find and fix all AI issues, but when a game’s known problems are older than its customers, there’s an issue. Consider the pond fish. A pond fish is a navy built in a small body of water, often only one tile in size. Players of Civilization, 1991’s Game of the Year, joked about it, gave it a nickname and created Web sites to share screen shots of it (e.g., (Civilization Fanatic Center 2002)). Despite the problem’s high profile, the pond fish was still there in 2001’s Civilization III and 2002’s award winning Heroes of Might & Magic IV. These problems have stood the test of time. The time span between Baldur’s Gate and Icewind Dale 2, games which allow you to attack enemies without fear of reprisal, is three years. For Doom and Half-Life, which also allow free attacks, it’s five. The span between the first pond fish and the latest is 11 years, making it four years older than my oldest child, this game’s number one fan. And these are conservative numbers. They are based only on incidents I have personally witnessed. If customer reports are to be believed, these problems are actually much older. 5. AI Problems Are Solvable Earlier we said that in many first person shooters, enemies sometimes don’t mind being shot. Because an enemy screams and plays a damage animation when it is shot, we can assume that code already exists to detect pain. The agent’s actions are normally determined by the value of a single state variable. My assumption is that this problem can be solved simply by adding a line to the damageTaken event that sets the enemy’s state to Attacking. Alternately, you could make the agent invulnerable while Disabled. Either solution is simple. So why does this problem still exist? A common argument is that the AI doesn’t get enough processing time. The solution, they argue, is to build an AI coprocessor. Yet the change discussed here takes only a few clock cycles and it’s unclear how an AI coprocessor would make this better. Another common argument is that game developers lack a formal AI education. Yet it is hard to imagine that the above fix requires a PhD. It is often argued that AI developers simply don’t have enough time. True enough. So a developer can be forgiven for missing the problem the first time around. But after five years and a dozen games? A fourth explanation is that an AI developer cannot predict every single event that will happen in a game. That might be true. But how hard is it to predict that a player might attack his enemy? How hard is it to discover a problem that players have been reporting for years? This problem has a simple solution. Perhaps it’s unique. Without a database of problems, it’s hard to know. My personal incident database suggests that it is not. Let’s examine a few more. The area effect tactic described earlier is solved the same way as the problem above. How about when enemies don’t notice that the person next to them has died? Since they already respond to sound, have the victim scream. Agents keep taking the same deadly path? Overlay a grid, track the death count in each cell and use it as a cost for A*. Pond fish? Since these are tile games, you can quickly measure the size of a lake before building a navy. Agents keep using the same ineffective weapon? In the code that plays “My weapon did no damage!”, have them switch weapons. And so on and so on. There are issues that require some thought (e.g., avoiding bottlenecks when groups move through a door), but the majority appear to be fixable, even when development time and processing power are short. 6. A Good Start: Build a Foundation So we know that many AI problems that are easily solved are widespread, exist in top games and are old enough to go to school. What should we do? In my opinion, we start by collecting, documenting and sharing information. A. Build a Database of Examples I believe that the best way to understand a problem is to study examples of it. The examples shou