[MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report

[J C Lawrence]

Some of the internal references are utterly fascinating:

  URL:http://www.cris.com/%7eswoodcoc/cgdc97notes.html

1997 CGDC AI Roundtable Moderator's Report 

by Steven Woodcock

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 heavier toll 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 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 oft-observed 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 peons 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 in particular.  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, developed 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's 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
     programmers, 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. It was felt that a
     bad AI will garner much negative press, whereas a good AI might
     never really be appreciated in a multi-player game. Then again,
     as one attendee pointed out, C&C has sold over 4 million units,
     possibly demonstrating that good game AI isn't all that
     important.

     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
     being mixtures of rules-based and 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.

Conclusions

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.


Steven Woodcock 

Lockheed-Martin Real3D 

Wyrd Wyrks 

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...