[MUD-Dev] Re: WIRED: Kilers have more fun
Dr. Cat
cat at bga.com
Tue Jul 21 18:37:07 CEST 1998
Koster, Raph<rkoster at origin.ea.com> wrote:
> In fact, a question I'd ask is whether the increased freedoms that
> have come over time in certain mud designs have increased the
> dissatisfaction... in other words, seeing a line of evolution from
> MUDI to Aber to Diku to M59 and UO, all gaming-oriented environments
> in many ways, we do see an increased freedom in the feature set,
> more ability for players to act freely. Does the fact that they have
> more freedom make players more sensitive when a particular freedom
> 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:
http://www.ogr.com/specials/guest_column1_1.shtml
Maybe there's hope for us yet.
*-------------------------------------------**-----------------------------*
Dr. Cat / Dragon's Eye Productions || Free alpha test:
*-------------------------------------------** http://www.bga.com/furcadia
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
More information about the mud-dev-archive
mailing list