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