1998Q3/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD&#45;Dev] Re: WIRED: Kilers have more fun -->
<!--X-From-R13: "Re. Qng" <pngNotn.pbz> -->
<!--X-Date: Tue, 21 Jul 1998 18:56:08 &#45;0700 -->
<!--X-Message-Id: 199807212337.SAA13607#zoom,bga.com -->
<!--X-Content-Type: text -->
<!--X-Reference: 199807211800.LAA07181#under,engr.sgi.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: WIRED: Kilers have more fun</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cat#bga,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>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00298.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00300.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00281.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00037.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00299">Author</A>
&nbsp;|&nbsp;<A HREF="#00299">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00299">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: WIRED: Kilers have more fun</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] Re: WIRED: Kilers have more fun</LI>
<LI><em>From</em>: "Dr. Cat" &lt;<A HREF="mailto:cat#bga,com">cat#bga,com</A>&gt;</LI>
<LI><em>Date</em>: Tue, 21 Jul 1998 18:37:07 -0500 (CDT)</LI>
<LI><em>Cc</em>: <A HREF="mailto:pixel#bga,com">pixel#bga,com</A></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>
Koster, Raph&lt;rkoster#origin,ea.com&gt; wrote:
&gt; In fact, a question I'd ask is whether the increased freedoms that
&gt; have come over time in certain mud designs have increased the
&gt; dissatisfaction... in other words, seeing a line of evolution from
&gt; MUDI to Aber to Diku to M59 and UO, all gaming-oriented environments
&gt; in many ways, we do see an increased freedom in the feature set,
&gt; more ability for players to act freely. Does the fact that they have
&gt; more freedom make players more sensitive when a particular freedom
&gt; turns out not to be supported by the code base?

In a nutshell, "yes".  I've been observing this tendency my whole career, 
and shaking my head at how much in the industry fails to figure out even 
what I would consider the basics of game design.

Consider PacMan.  Player input is limited to the ability to move in four 
directions.  Not even a button to go with the joystick.  There's a fairly 
small number of objects with fairly clear behaviors that are easy to 
learn in a short time, and only one way to interact with any of them - by 
moving into it.  Nobody got upset with the game because "you can't use 
your sword to pry the door open" or whatever, they were given clear 
expectations and those expectations were fulfilled.  Most videogames of 
the late 70s and early 80s were like this, and most of the early home 
computer games were the same way too.  To some extent, this was because 
they didn't really have the system resources in those days to make a game 
complex enough to provide for dissapointed expectations.  With the 
possible exception of text-adventures, which did manage to get exactly 
that sort of result with some frequency.

But the tight limitations on what you could do forced designers to learn 
to focus very tightly on just what would make the game FUN, and not waste 
scarce resources on things that would add little or no "fun per byte".  
Some game designers developed some excellent skills in that era as a result.

One of my first big signs of the move into the "kitchen sink" school of 
design came when I worked on Ultima 6, and experienced the table forks 
(and knives and spoons) that were included in that game.  Kind of 
appropriate to find silverware in the kitchen sink, I guess!

Richard had written Ultima 1 through 5 in a fairly constant environment 
of an Apple II+.  At some point he moved from requiring 48K to 64K, and 
he increased the number of disk-sides it took up.  On 5, he finally had 
large amounts of programming done by other people rather than doing 
almost all of it himself.  But many aspects of the hardware platform 
remained pretty constant - 1 MhZ 6502, 280*192 display with 6 colors, 64K 
of RAM, 143K floppy disk drive, etc.

On Ultima 6, the era of ever-increasing hardware capabilities arrived, 
and changed everything.  After a year of working on an Apple II version, 
all the existing work was junked, and it was started from scratch on this 
"IBM PC" thing that was starting to catch on as the new game platform.
All of a sudden, there was a hard drive.  256 colors, and any color could 
be placed next to any other color with no positioning limits!  Instead of 
64K of RAM, there was 640K, ten times as much!

The game ended up costing $250,000 - the most expensive game Origin had 
ever made!  Of course that budget is too small to even do a game for them 
these days - showing that the budgets inflate just like the system 
requirements.  (Wing Commander 4 cost around $12 million to produce.)
A lot of things about the game were fun, and I'm still pleased to have 
worked on it and happy with the things that I contributed to the project.

But I'll never get over those damned forks.

They're not the only object I have a problem with, just the example that 
sticks out most in my mind.  I remember the way you could use a very, 
very few of the many, many objects in that game, and how pleased and 
proud Richard was about that.  You could take milk to a churn, use the 
churn on it, and get a stick of butter.  There were merchants that would 
buy things like butter, too.  I think using an empty bucket with a well 
turned it into the bucket full of water graphic, and so forth.

I just took one look at that, and I said "players are going to try to use 
EVERY object after they find one that does something, and 95% of the time 
they're going to be dissapointed to find out that the use command does 
nothing, and finally they'll give up on using things".  If you're going 
to build player expectations, you have to set yourself up to satisfy 
those player expectations, not to dissapoint them repeatedly with a few 
times mixed in where you actually satisfy them.  I understand that Ultima 
Online is better in this regard - with a budget an order of magnitude 
higher, I've heard that most of the objects actually do stuff, not just a 
minority.

The thing about the graphics drivers in Ultima 6 was that you could have 
more than one shape in the same square, and it would overlay all the 
object shapes, with transparency.  This was a big step up from clunky 
Ultima objects in 5 and earlier.  So one of the things Richard liked was 
that instead of a complete place setting on a table, there was a plate 
object, a fork object, a knife object, and a spoon object.  And you could 
move them around individually, set the table, or set part of a setting, 
etc. etc.

When I look at the act of designing elements like this into a game, I 
have to figure why is it there?  "Because we can."  It comes from the 
"because we can" school of game design.  Contrast this with Pac Man, or 
an Apple II game, where if you wanted to squeeze in all this silverware 
simulation you'd have to pull out some important game feature that 
probably added a lot of the fun.

Unlike the swords, crossbows, quest items, etc. which had a clearly 
defined role in the game, or even the butter churns which at least did 
something, I only know of one instance that was ever reported to me of 
someone having fun with a fork.  Every object had an "owned" bit to 
indicate whether you were free to grab it at will (like stuff in the 
dungeons, or anything in Lord British's castle that he said you could 
take to help you in your quest), or something that would cause people to 
yell "Stop, thief!" and get the guards after you.

Well, the "get" command checked the owned bit.  But the "move" command 
didn't.  You could push someone else's furniture around all day.  So one 
of the company playtesters got an odd thought, and had to try it out.  He 
pushed a fork off a table.  He pushed it along the floor, out the door.  
And, one square at a time, he kept pushing it over the dirt and grass, to 
the edge of town, and out into the forest.  He pushed that fork miles 
into the wildnerness, until he was nowhere near any signs of civilization.

And then he picked it up.

Of course instantly a voice from who-knows-where cried out "Stop, thief!"
Luckily for him, there were no guards anywhere nearby.  But the next time 
he went back to town, boy were they pissed at him for stealing that fork!

Well it's a fun story, but I don't think it was worth putting the forks 
in the game just for that.  We started out with a school of game design 
where people had to KNOW what would be fun about the game, and why.  
"Pac Man will be fun because you have to dodge the ghosts to stay alive, 
but you have to get to every part of the maze eventually to get all the 
stuff so you have to be clever, plus the ghosts use these different 
movement algorithms to make them more interesting to dodge and so they 
won't all bunch up in the same place.  Plus four times per level we let 
you turn the tables and chase them and people will enjoy that!"

Now we have this alternative school of game design that says "If we put 
enough complexity and richness and realism into the game mechanics, the 
sophisticated interactions between player actions, the game environment 
and objects, and the the game physics will lead to fun situations arising 
naturally".

My experience shows that betting on this to be true is something of a 
longshot.  Even in the more complex, deeper games possible today, with 
the larger numbers of elements interacting, if you use old-school design 
skills and put in some things that you damn well KNOW will be fun, and 
you know EXACTLY how and why they'll be fun, I think you're way ahead of 
most of the competition.  But this is still a very new field, and there's 
a very limited number of people on the earth so far that really do have a 
deep understanding of what makes "fun" happen in a game.  The technology 
is still changing at a rapid enough pace to make almost everything in 
this industry a moving target, too, though that will eventually settle down.

We are seeing some decent new talents emerge here and there though.  
We're finally at a point now where we can have people coming into the 
industry who were literally exposed to videogames and computer games 
since birth.  (Well, maybe their parents waited until they got them home 
from the hospital, at least!)  I just read an article by a young designer 
I know who shows a lot of promise, and has relevance to some of the kinds 
of MUD design goals discussed on this list, even.  It's about designing 
monster capabilities and behaviors in such a way as to make games more fun.
Check it out at:

    <A  HREF="http://www.ogr.com/specials/guest_column1_1.shtml">http://www.ogr.com/specials/guest_column1_1.shtml</A>

Maybe there's hope for us yet.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  <A  HREF="http://www.bga.com/furcadia">http://www.bga.com/furcadia</A>
  Furcadia - a new graphic mud for PCs!     ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*


</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00278" HREF="msg00278.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence &lt;claw#under,engr.sgi.com&gt;</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00298.html">[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00300.html">[MUD-Dev] Re: [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00281.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00037.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00299"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00299"><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: WIRED: Kilers have more fun</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00553" HREF="msg00553.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Sat 08 Aug 1998, 05:22 GMT
</LI>
</ul>
</ul>
</ul>
</ul>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00035" HREF="msg00035.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 02 Jul 1998, 19:46 GMT
<UL>
<LI><strong><A NAME="00278" HREF="msg00278.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 21 Jul 1998, 18:02 GMT
<UL>
<LI><strong><A NAME="00281" HREF="msg00281.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Tue 21 Jul 1998, 18:50 GMT
</LI>
<LI><strong><A NAME="00299" HREF="msg00299.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Wed 22 Jul 1998, 01:56 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00037" HREF="msg00037.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 02 Jul 1998, 20:30 GMT
<UL>
<LI><strong><A NAME="00074" HREF="msg00074.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 08 Jul 1998, 05:46 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00039" HREF="msg00039.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 02 Jul 1998, 20:43 GMT
</LI>
<LI><strong><A NAME="00054" HREF="msg00054.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></strong>, 
Matt Chatterley <a href="mailto:matt#mpc,dyn.ml.org">matt#mpc,dyn.ml.org</a>, Tue 07 Jul 1998, 02:24 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>