CGDC '97 Roundtable Report

Approach

When Neil, Eric, and myself first came up with the idea for expanding on the AI roundtables from the 1996 CGDC, we did it in part out of a sense of frustration over the crowded sessions prevalent at the 1996 CGDC. We felt that the large number of sessions we proposed, spread out over the course of the convention, would greatly increase active participation and overall satisfaction on the part of the roundtable attendees. As the 1997 CGDC grew closer, we realized that we could also use these sessions to "take the pulse" of gaming AI in general by asking two questions at each session:

What percentage of the CPU overall do you the AI programmer typically get for your processing?
Who many programmers are typically allocated on a full-time basis to build the AI?

Sunday Session, 4/27/97

There were roughly 29 people attending my first AI roundtable, with two people leaving halfway through the discussion while two others came in a few moments later. A wide variety of topics were discussed; I broke the ice with the above two questions:

CPU Percentage - Answers here varied from 1% - 5%, with the agreed-upon average being roughly 3% and the agreed-upon "ideal" being 10%. The general consensus was that more and more resources are being devoted to AI than in the past.
Dedicated AI Programmers - Of the 29 attendees there were some 10 ongoing projects; of those 10 projects, 4 had full-time dedicated AI folks. One of those had 2 dedicated AI programmers. The general consensus was again that more and more resources are being devoted to AI than in the past.
Real-time vs. Turn-based - The first big topic was the discussion of real-time games vs. Turn-based games and the impact this had on AI processing. Most attendees agree that real-time games took a heavy tool on AI, since the user was far more likely to be tolerant of waiting for a computer AI to finish its turn than to see a real-time game AI act stupidly. Command & Conquer (of which almost all attendees were fans) was often used as an example of a game desperately seeking a better AI, and was often used as the example across several of the AI techniques discussed. The topic of the impact of real-time games on game AI design was a hot one that continued through all three sessions which I moderated.
Planning, Goal Setting, and Cooperative AIs - There was some brief discussion on building intelligent, cooperative AIs that could both plan and set goals to be achieved. We briefly touched on a technology for cooperative AIs called blackboards, and at least one developer in the group was using blackboards for an upcoming sports game. We discussed the intended use of blackboards by Atomic in their Close Combat game as well as why they elected not to use them. General consensus was that goal-setting and planning will lend a more "realistic" flavor to AIs, while cooperative AIs were generally only needed in RPGs where several NPCs might be interacting with each other as well as the player.
How Much AI Makes a Difference & Cheating - Another topic that spurred excellent discussion was "when is enough" in game AI, which led in part to a discussion on when to have an AI cheat. Nearly every developer had built AIs that cheated for one reason or another, mostly to deliver a better gaming experience to the player. We agreed that this was perhaps the only reason for allowing cheating, though everyone also agreed (being engineers) that a non-cheating AI was to be preferred wherever possible. Using Warcraft II as an example, it was pointed out that the problem of "peon traffic jams" could be easily solved—and enhance the player’s gaming experience—if the AI cheated a bit when it detected a traffic jam. The AI could easily detect such a jam; if the player could see the jam, then presumably he would do something, but if the player is looking elsewhere, there’s no reason why the AI couldn’t simply "teleport" some of the peons to their destinations, thus freeing up the jam. The player likely would never know the jam occurred, and would not feel the frustration of being deeply involved in battle only to discover he had no resources with which to build reinforcements due to his peon being stuck.
Cyberlife &Artificial Life - There was some brief discussion on both artificial life in general and the Cyberlife technology used in the game Creatures in particular. As I had had some regular e-mail exchanges with Toby Simpson, one of the Creatures developers, I was asked to share some insight on the internal technology. (Several of those present are frequent visitors to my game AI web page, and so were aware of my admiration for the technology in Creatures.) We discussed the possibilities of using artificial life techniques in various games, particularly RPGs, but as nobody present was using them we quickly moved on.
Scalability & Adaptability - Some discussion occurred on the topic of building AIs which could adapt or "scale" themselves to the player as the player’s ability at the game improved. Nearly everybody present built their AI from the basis of creating the Expert AI first, then altering it as necessary to provide Beginner and Intermediate opponents. It was generally agreed that the best way to accomplish this was to develop the AI in an object-oriented fashion as much as possible, so that (for example) a more capable pathfinding algorithm might be substituted as the AI difficulty was ramped up. Most agreed that "soft" AI technologies, such as neural networks and genetic algorithms, offered the most potential for building AIs which could truly adapt to the player, though this in turn spawned a side discussion regarding whether such a thing was truly what the player wanted. The example posed along these lines was that of a typical game of Quake: does the player really want the enemies in Quake to play smarter and faster, so that he always faces the possibility of losing, or does he want to gradually get better than those enemies so that he can always vanquish them? Which is ultimately more satisfying for the gamer?

Monday Session, 4/28/97

The Monday session was the lightest of the three I moderated, with only 20 people attending. It stands out as the only session across the nine with one primary focus throughout, that being artificial life (A-life) technology in general and the Cyberlife technology used in Creatures. This was due both to my desire to revisit the topic after its brief discussion in the first session and the participation of Toby Simpson, one of the developers of the Cyberlife technology:

CPU Percentage - Answers on Monday were somewhat higher than the previous session, ranging from 5% - 10%. The Creatures game used roughly 50% of the CPU for pure AI; this was reasonable given its intent as a showcase of the Cyberlife technology. The general consensus as before was that more and more resources are being devoted to developing solid game AI.
Dedicated AI Programmers - Half of the attendees were dedicated AI developers for the various projects they were working on.
Cyberlife & Artificial Life - This was far and away the main topic of conversation of this session, by popular demand. My listing of the topic on the board brought up several immediate comments, which led to discussion, and we never (frankly) had the need to move on to any other topics.

Toby Simpson was a gracious participant and clearly understood his topic well. After the group briefly discussed the overall possibilities of using A-life for RPGs and strategy games, Toby was asked to discuss the Cyberlife technology used in the Creatures game. Toby described it as a mixture of neural nets, genetic algorithms, and fuzzy state machines, built up over the course of several years by a number of British researchers before being adapted into the Creatures game as a practical demonstration of its capabilities. The AI is self-modifying and can adapt itself over time as it interacts with the players, passing down various traits and behaviors genetically to offspring from generation to generation.

Toby described in detail several surprising developments that have occurred with the Creatures AI engine as customers have reported them. Three stand out as evidence of the power of this technology and were the subject of much note-taking by participants:

During the development of the game one programmer came back from lunch to discover over 30 Creatures running around in the game where there had been only one. Wondering how this could happen, he then saw a Creature come into the "hatchery" with an egg (which are randomly distributed about the environment) and place it into the incubator until it hatched. This Creature had learned by accident that eggs dropped in the incubator made more Creatures, and Creatures like having friends.

· After the game was shipped developers witnessed what could only be described as a suicide. Two Creatures that were best friends often wandered around the environment together, and eventually one of them "died" of old age (they have a life-span of roughly 50 hours). Its friend refused to leave the body, despite increasing biological needs for sleep and food, until it too died of starvation.

By design, the Creatures’ brain consists of roughly nine "lobes", with each lobe dedicated to a specific aspect of the Creatures’ personality (emotions, learning, etc.). A player of the game sent the developers a Creature which had evolved two additional lobes. Examination and testing showed that this "mutant" was slightly better than a "normal" Creature—it learned faster and seemed somewhat more intelligent.

After much discussion of A-life we moved to quick discussion of cheating and the stability of rules-based systems vs. A-life systems. It was generally agreed (though perhaps not by Toby) that rules-based AIs were probably sufficient, if well designed, to provide the player with a fun gaming experience. Rules-based systems have the general advantage of making it easier for the developer to cheat if necessary, whereas A-life systems, being something of "black boxes", could be harder to constrain.

Tuesday Session, 4/29/97

The final session touched on a number of topics that Neil and Eric’s roundtables had discussed but which hadn’t been brought up in any of my sessions. After hitting the 30 attendees up for their CPU and dedicated programmer numbers, we then moved on to a topic obviously inspired by the Adding Extensible Custom Languages to Game Engines session the previous day:

CPU Percentage - Most developers felt that they used roughly 5% of the CPU for real-time games and 10% for turn-based games. The AI developer for the upcoming X-Com 3 reported an astounding 25% CPU utilization, easily the highest reported in any of my sessions (barring Creatures, which is something of an exception).
Dedicated AI Programmers - Roughly half of the attendees were dedicated AI developers for the various projects they were working on. Two developers reported two dedicated AI developers, with three others reporting one full-time and one half-time developers.
Extensible AIs - I began by listing a number of topics on the board which had not yet been discussed in any of my roundtables, and the topic of extensible AIs (that is, AIs which are modular and easily modifiable by either the developer of the player) was quickly seized upon by a number of participants. Several of us had attended the Adding Extensible Custom Languages to Game Engines session the previous day and it had obvious applications for game AI. Quake offers a method for player-built AIs to be created and inserted into the game via their Quake-C interface, and was often referred to throughout the course of the discussion. Several developers revealed that they used various forms of scripting to build and/or control their game AIs, which one revealed that he was implementing the AI for his game (a racing game) as a Windows .DLL file which would be accessible to the user for modification. A lively debate ensued when several attendees opined that an extensible AI was a sign of poor game design, indicative of developers focusing more on graphics than on gameplay. No consensus was reached, though several excellent examples both pro and con were kicked around.

We also briefly visited the concept of marketability…how much does an extensible AI add to the selling power of a game? It was generally agreed that it made add-ons and upgrades far easier, and that it wouldn’t hurt sales and might increase them somewhat as people otherwise not interested in the game bought it as an AI testbed. This in turn led to a discussion of what kind of resources building an extensible AI required in terms of manpower and game schedules. The industry-wide pressure to "ship it now!" often makes building a "non-stupid" AI difficult, much less an extensible one.

Avoiding Artificial Stupidity - An awful lot of developers were less concerned with building a smart AI as simply building one that didn’t act like a moron. The AI in Command & Conquer was often cited as an example of the latter, particularly the harvester bug (wherein your harvester will cheerfully blunder into an enemy camp looking for Tiberium and get destroyed). With very little effort (it was felt) this could have been avoided through a number of methods ranging from influence mapping to a simple "if you’re shot at run away!" rule. A bad AI will garner much negative press, whereas a good AI might never really be appreciated in a multi-player game.
Testing AI - Attendees agreed that this was a difficult proposition, and many were looking for answers at the roundtable. Most developers of rules-based systems used a "tournament" approach, building several AI variations and pitting them against each other and playtesters to see which fared best. Nearly everybody used extensive debugging and runtime information files to dump the AI’s "thinking" process for later examination for obvious errors. Games using A-life and other soft AI techniques (there were four developers present building games using A-life, neural networks, or genetic algorithms) faced a somewhat tougher testing problem, since the behavior of the AI in these cases was often emergent rather than programmed. All agreed that the only real way to test was playtesting, playtesting, playtesting.
RPGs - One topic which garnered somewhat more interest in the last session than in others was the use of good AI for role playing games. In light of the upcoming large online RPGs, some developers wondered how to build believable non-player characters (NPCs) which could interact with the players intelligently. A variety of approaches were discussed, most combinations of rules-based on A-life. Ultima Online was brought up as an interesting example of a quasi A-life approach backed up by careful overview of Game Moderators to prevent things from getting too wildly out of hand.

Conclusion

By our count the total attendance at the AI roundtables this year was 201 people. We achieved our goals of increasing the number of seats available while simultaneously increasing overall participation; the average session size of 25 people in each of my sessions was just about perfect in my opinion. I strongly urge and recommend that we use this format again for next years’ CGDC, and I know I can speak for both Neil and Eric that we would be happy to do this again.