<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Thu, 13 Aug 1998 13:06:19 -0700 -->
<!--X-Message-Id: 199808132005.NAA07462#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] OGR: Ion Storm's Witchboy talks about the functional</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="msg00706.html">Previous</a>
| <a href="msg00708.html">Next</a>
]
Thread:
[ <a href="msg00708.html">Previous</a>
| <a href="msg00709.html">Next</a>
]
Index:
[ <A HREF="author.html#00707">Author</A>
| <A HREF="#00707">Date</A>
| <A HREF="thread.html#00707">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] OGR: Ion Storm's Witchboy talks about the functionality of enemy AI.</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] OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. </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>: Thu, 13 Aug 1998 13:05:56 -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>
<A HREF="http://www.ogr.com/specials/guest_column1_1.shtml">http://www.ogr.com/specials/guest_column1_1.shtml</A>
--<cut>--
Exclusive on Online Gaming Review
Harvey Smith: Guest Column
Ion Storm's Witchboy talks about
the functionality of enemy AI.
DISTINCT FUNCTION IN GAME UNITS Part 1
By Witchboy
As with weapon differentiation, if each enemy has a particular
function in the game world (and it is obvious and/or something the
player can learn over time) then the player can make informed
decisions about how to deal with each enemy (which becomes a game
dynamic). The alternative (in which all enemies do basic variations of
the same thing - race forward and inflict damage) is boring.
Enemy Differentiation and Available Responses
Enemies. Monsters. Sprites. AI's. NPC's. Creatures. Villains. What
are they? More specifically, in computer games what are they? Hurdles
that must be overcome in order to reach the exit to the level?
Simulated opponents that try to kill the player or stop his progress?
Cool renders with interesting attack, fidget and death animations?
Collections of stats?
All of the above, I suppose, but one of my pet peeves is that many
game designers seem to have forgotten (or have never learned) how to
make interesting and distinctly different enemies. Or even what that
really means.
If a game has a line-up of creatures that look awesome but simply
represent an ever-ascending set of numbers in several fields, then
chances are that game will get boring quickly. Or at least it will not
be as exciting as it could have been, had the designer planned out the
creature's role in the game at an abstract level.
Think about Defender (and Stargate), the classic arcade games by
Williams Electronics. Let's choose three of their units, the Lander,
the Mutant and the Bomber.
The Lander flew slowly and occasionally fired a shot at the player. If
given the chance the Lander would descend to the surface below to pick
up one of the humanoids that the player was supposed to be
protecting. When a Lander grabbed a humanoid, it would rise toward the
upper levels of the atmosphere, suddenly firing like mad; when it
reached the top of the screen, the humanoid was destroyed and the
Lander would become a Mutant.
The Mutant was faster than the Lander and *much* more aggressive -
always making a headlong attack when it spotted the player. The Mutant
also had an erratic flight pattern, making it less predictable harder
to evade.
The Bomber was slow and peaceful for the most part, but it left a
trail of bombs that hung in space; if the player contacted one of the
bombs, his ship was destroyed.
Discounting their appearances and fictional identities completely,
think about how different these three units are... Think about the
ways in which they are different within the game's framework of
actions and mechanics. In these three units you have essentially
Movement Rate, Flight Type, Aggression Level and Special Ability. The
special abilities (an arbitrary term) for these units were
respectively: L) consume humanoids then change unit types, M) pursue
the player aggressively and B) leave a trail of explosives. (Note:
The Lander's ability to consume resources - the humanoids - is doubly
brilliant. The game-play is made dynamic because the Lander changes
from a relatively weak enemy to really critical enemy as soon as it
picks up a humanoid. The player must immediately switch gears and deal
with the threat of the Lander becoming a Mutant, or suffer the
consequences.)
In many games (old and new), the enemy design was nowhere near as
interesting and distinct. To use two hypothetical examples: Creature
One can move at a game speed of 50, does 37 points of damage in an
attack and has 100 hit points. Creature Two can move at a game speed
of 75, does 12 points of damage in an attack and has 30 hit
points. And so on. In some games, this is all you get. The problem is
that this sort of design does not cause the player to dynamically
adjust his play. It does not force the player to make any critical
decisions about how to react to a game enemy; the reaction is
generally always the same, since the enemies are fundamentally the
same.
Game designers should want to 1) present players with a series of
distinct and challenging situations, 2) give them enough information
so that they can decide how to react and 3) provide they with a set of
in-game actions that will allow them to execute on their decisions,
with consequences.
To illustrate my points, I'll create an example game enemy. And let's
make an enemy relevant to more modern games than Defender, lest
someone cry, "Games have changed; the old rules do not apply!" For
our example, I will use a crocodile, set in a 3d world-an environment
in which we'll state that the player can run and swim. Fairly standard
stuff, and an area in which designers routinely short-change players
by not making things interesting enough.
Now, for the crocodile we're discussing, you could just make it a big
green lizard with lots of hit points, an appropriate movement speed
and a large set of jaws that do damage to the player. To do so would
not be horrible--after all, this creature would be somewhat different
from the game's other enemies simply because it is capable of chasing
the player through water. (See Tomb Raider for such examples in its
crocodiles, bears, raptors and wolves.) But if this is the extent to
which our example crocodile is unique, it is then essentially the same
as a bear with a few different stats and the ability to swim. We can
do better if we add just a few interesting and unique attributes.
DISTINCT FUNCTION IN GAME UNITS Part 2
By Witchboy
So our crocodile will have three more features.
First, let's assume our player's in-game character can hold his breath
for a specific period. We'll then say that when our crocodile succeeds
in biting the character in the water, the player loses some of his
precious "breath" (and of course when the player reaches zero, he
drowns). Suddenly the player must rethink his strategies related to
how long he can swim underwater, what distances he can reach, whether
he needs to dispatch or distract enemies on land before entering the
water, etc. If the player did much swimming in the game before meeting
his first crocodile (on previous 'levels' or whatever, encountering
other types of water features such as current flows and small fish),
he will now have to adjust the way he plays because the game has
changed. Imparting our crocodile with this one attribute has made the
game a dynamic experience. (Now imagine if we applied this thinking to
every enemy or friendly AI unit in our make-believe game...)
Second, our crocodile, due to its tough leathery skin, is immune to
the tranquilizer dart gun in our game. If we do this, the player
cannot just shoot his way out of the encounter. He must instead, react
to the situation and make a decision (if only to switch weapons when
fighting crocodiles).
And lastly, let's make our crocodile move fast in the water *and* on
dry land (like a real crocodile), but let's give him a really, really
slow turning rate when on the land. This way, he will only be able to
move fast *in a straight line* when chasing after the player on dry
land. So if the player zigzags as he runs, he can easily elude the
crocodile.
So now the crocodile is different from the other enemies in the game
in a number of recognizable ways. It is not just faster, tougher and
more lethal--it also has some special attributes which will make it
more interesting to encounter. The really good game designers have
employed this philosophy for years, completely at odds with the "boss
monster" style enemy progression used in many games. This approach to
design asks the question, "What does each unit represent on an
abstract level?" It makes the game more active. It makes the player
decide and react. It grants the game interesting dynamics, instead of
creating tedious game-play.
It is also important to note that if the player never *knows* about
any of the distinct enemy functions you generate, he will never get
any enjoyment from them. So, as feedback mechanisms for to our example
croc, we could do something like this:
Related to the crocodile's tranquilizer dart immunity, we could play a
different "got hit" sound effect when the dart hits the crocodile;
instead of a nice sticking sound (made when the dart 'works' on a
given creature), we could make the dart "pa-ting!" and ricochet.
Also - to inform the player of the croc's interesting land movement
features before the player actually encounters any crocodiles--we
could drop one or two down on the beach, chasing some small innocuous
game creatures. The creatures that run from the crocodiles in straight
lines always get eaten; the creatures that run in a zigzag pattern
always escape. By studying the crocodiles before encountering them,
the player could learn something about consistent crocodile behavior
as it is within the framework of our game. (Clearly, this sort of
thing does not work if the game is nothing but a series of monster
filled rooms. Showing the next obstacle before the player actually has
to deal with it can produce a number of more interesting game
dynamics; the player has more information with which to act.)
The 'loss of breath' attack that the crocodile has against the player
when fighting in the water is less complicated to communicate: it
could be made obvious by subtracting a breath increment each time the
croc bites and triggering a player gurgling sound.
An equally valid approach to designing game enemies-perhaps more
valid-is to decide what function an enemy will provide within the game
before you decide what the creature actually is. For instance, rather
than saying, "How can we make our crocodile unique and interesting in
terms of game mechanics?" you instead ask, "What do we want Enemy X to
do or represent in the game?" In the latter practice, you would come
up with an idea that you think would be interesting in your game, then
retrofit the type of enemy to that idea. As an example, think about
Quake 2's "medic" enemy; its primary purpose was to heal wounded
monsters. This was not executed particularly well since most players
never had a chance to realize what was going on and the guys at id,
seemingly, did not have the discipline to focus this unit down to its
essence. (Sadly, it comes across in Quake 2 mostly as another big
beast with lots of hit points?) However, as a concept, it is quite
cool. It really works as an example of how you might first decide what
role a unit plays in the game, like "autonomously heal other enemy
units so that they might live to antagonize the player anew," then
come up with an identity and a look for that unit. (Note: I have no
idea which design phase came first in this case, abstract function or
fictional/artistic identity.) When you take this approach, it becomes
obvious as to why so many games are set in "dark-magic land" or
"alien-dimension x." If you are completely free to create the unit's
function first, you end up with some wild behaviors and actions,
usually inappropriate for real-world mundane animals or those that are
recognizable to the player. (Think Q*bert.)
Either way, the end result is that when players encounter the
crocodiles in our example, the function of the enemy unit is obvious,
the game's situation changes somewhat and the player is required to
react to a new form of obstacle that behaves in unique and interesting
ways. And if we account for these enemy design features by
incorporating several potential methods of reacting, the player can,
within the scope of the actions available to him within the game, make
informed and useful decisions in response to the crocodile enemy. And
those decisions will be completely different from the decisions made
when facing a bear...
-- Witchboy
<A HREF="http://www.io.com/~salem">http://www.io.com/~salem</A>
During his hellish early years on the Texas Gulf Coast (surrounded by
evil shrimpers and gloomy chemical plants), Witchboy's sanity was
narrowly preserved through years of non-stop gaming and subcultural
pursuits. Only through this massive assimilation of SF/Fantasy books,
computer/vid games, paper RPG's and mope rock did he manage to evolve
into the fey being he is today. He makes his home in Austin, Texas
because he has a lick of sense. He eats nothing but Tex-Mex and fried
seafood, and he is a 6th generation native Texan.
Projects to date: Deus Ex (Design Team Leader), FireTeam (Lead
Designer), Technosaur (Project Director/Designer), CyberMage
(Associate Producer), Ultima VIII, CD Re-release (Lead
Tester/Designer), System Shock (Lead Tester) and Super Wing Commander
3DO (Tester).
--<cut>--
--
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="00709" HREF="msg00709.html">[MUD-Dev] Re: OGR: Ion Storm's Witchboy talks about the functionalityof enemy AI.</A></strong>
<ul compact><li><em>From:</em> s001gmu#nova,wright.edu</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00706.html">[MUD-Dev] Re: Eye movement.</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00708.html">[MUD-Dev] Re: avoiding ecological wipeout</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00708.html">[MUD-Dev] Re: avoiding ecological wipeout</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00709.html">[MUD-Dev] Re: OGR: Ion Storm's Witchboy talks about the functionalityof enemy AI.</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00707"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00707"><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: Yet another update on threads and signals</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00719" HREF="msg00719.html">[MUD-Dev] Re: Yet another update on threads and signals</A></strong>,
s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Fri 14 Aug 1998, 18:32 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00715" HREF="msg00715.html">[MUD-Dev] Passing file descriptors to other processes</A></strong>,
Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Fri 14 Aug 1998, 03:18 GMT
<LI><strong><A NAME="00711" HREF="msg00711.html">[MUD-Dev] Re: Methods to Reduce Ecological Wipeout (fwd)</A></strong>,
Marc Hernandez <a href="mailto:marc#jb,com">marc#jb,com</a>, Thu 13 Aug 1998, 20:44 GMT
<LI><strong><A NAME="00708" HREF="msg00708.html">[MUD-Dev] Re: avoiding ecological wipeout</A></strong>,
Laurel Fan <a href="mailto:lf25+@andrew.cmu.edu">lf25+@andrew.cmu.edu</a>, Thu 13 Aug 1998, 20:13 GMT
<LI><strong><A NAME="00707" HREF="msg00707.html">[MUD-Dev] OGR: Ion Storm's Witchboy talks about the functionality of enemy AI.</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 13 Aug 1998, 20:06 GMT
<UL>
<LI><strong><A NAME="00709" HREF="msg00709.html">[MUD-Dev] Re: OGR: Ion Storm's Witchboy talks about the functionalityof enemy AI.</A></strong>,
s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Thu 13 Aug 1998, 20:36 GMT
<UL>
<LI><strong><A NAME="00710" HREF="msg00710.html">[MUD-Dev] Re: OGR: Ion Storm's Witchboy talks about the functionality of enemy AI.</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 13 Aug 1998, 20:41 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00702" HREF="msg00702.html">[MUD-Dev] Re: Eye movement.</A></strong>,
quzah <a href="mailto:quzah#geocities,com">quzah#geocities,com</a>, Thu 13 Aug 1998, 13:27 GMT
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00704" HREF="msg00704.html">[MUD-Dev] Re: Eye movement.</A></strong>,
S. Patrick Gallaty <a href="mailto:patrick#gric,com">patrick#gric,com</a>, Thu 13 Aug 1998, 16:33 GMT
</LI>
</UL>
</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>