<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Wed, 1 Jul 1998 14:34:22 -0700 -->
<!--X-Message-Id: 199807012132.OAA04539#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00015.html">Previous</a>
| <a href="msg00017.html">Next</a>
]
Thread:
[ <a href="msg00017.html">Previous</a>
| <a href="msg00090.html">Next</a>
]
Index:
[ <A HREF="author.html#00016">Author</A>
| <A HREF="#00016">Date</A>
| <A HREF="thread.html#00016">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Wed, 01 Jul 1998 14:32:58 -0700</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Some of the internal references are utterly fascinating:
URL:<A HREF="http://www.cris.com/%7eswoodcoc/cgdc97notes.html">http://www.cris.com/%7eswoodcoc/cgdc97notes.html</A>
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#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00090" HREF="msg00090.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></strong>
<ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00015.html">[MUD-Dev] Summary: "Influence Mapping"</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00017.html">[MUD-Dev] Summary: Recognizing Strategic Dispositions</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00017.html">[MUD-Dev] Summary: Recognizing Strategic Dispositions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00090.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00016"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00016"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: You think users won't number crunch and statis</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00218" HREF="msg00218.html">[MUD-Dev] Re: You think users won't number crunch and statis</A></strong>,
Katrina McClelan <a href="mailto:kitkat#the486,bradley.edu">kitkat#the486,bradley.edu</a>, Wed 15 Jul 1998, 02:42 GMT
</LI>
</ul>
</ul>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00041" HREF="msg00041.html">[MUD-Dev] Re: You think users won't number crunch and statistise your MUD?</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Fri 03 Jul 1998, 01:54 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00018" HREF="msg00018.html">[MUD-Dev] Re: roleplaying farmers?</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 21:45 GMT
<LI><strong><A NAME="00017" HREF="msg00017.html">[MUD-Dev] Summary: Recognizing Strategic Dispositions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 21:38 GMT
<LI><strong><A NAME="00016" HREF="msg00016.html">[MUD-Dev] 1997 CGDC AI Roundtable Moderator's Report</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 21:34 GMT
<UL>
<LI><strong><A NAME="00090" HREF="msg00090.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 08 Jul 1998, 18:39 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00015" HREF="msg00015.html">[MUD-Dev] Summary: "Influence Mapping"</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 21:25 GMT
<LI><strong><A NAME="00014" HREF="msg00014.html">[MUD-Dev] Elven Language List</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 21:25 GMT
<LI><strong><A NAME="00013" HREF="msg00013.html">[MUD-Dev] Re: Databases: was Re: skill system</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 01 Jul 1998, 20:47 GMT
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>