[MUD-Dev] Bay Area Press re: UO, the good the bad and the Ugly.

[adam at treyarch.com]

On Mon, 5 Jun 2000, Charles Hughes wrote:
> On Monday, June 05, 2000 11:18 AM, Dave Rickey wrote:
> > Consider leaving out your time-wasting mechanics completely.  I see no
> > purpose in designing a game that is flat-rated, but designed to make the
> > player spend 3/4+ of his time doing *absolutely nothing*.
> 
> Absolutely. :)

Which begs the question of what is a time waster.  Many (most?) people
would consider muds as a whole to be time-wasters.

On a smaller scale, we can probably define a time-waster as something
that is not "fun" because it is overly simple and repetitious.  The definition
of "overly" varies wildly from person to person, and from situation to
situation.  Deathmatch Quake is quite simple and repetitious, yet most
gameplayers (including myself, on a few rare occassions) are able to
amuse themselves with it for hours on end.  Ditto for solitaire, checkers,
or most other "popular" games you can think of.

In many cases the time-wasters are most easily identified within the
larger context of the game.  For example, in a game about negotiating
a maze, maze navigation is not a time-waster because it is, quite simply,
the point of the game.  In an adventure game, however, where the point is
to explore new areas and solve puzzles, a maze is frequently seen as
a time-waster, something the designers insert partway through to slow the
player down and keep them from winning the game too quickly.

On a talker, the point is to socialize.  Mechanics such as the lack of
global communications channels or aggressive NPCs (or, for that matter,
combat at all) interfere with the players reaching the primary goal,
and are therefore time-wasters.

On a GoP mud, where the goal is to build your character in a manner you see
fit, and then join a group to go explore exciting and dangerous new areas
of the game, time-wasters are usually identified as repetitious actions
required to build the skills, stats, or spells that the player desires for
their character, and that will allow them to go adventuring in those
"tough" areas.  If these actions are overly repetitious and overly simple,
then they instantly lend themselves to scripting.  (The exact properties that
make an action unfun to do are the things that make it easy to script.)

> > Nothing he
> > really cares about, anyway.  My opinion on macroing in games is simply
> > this: If a major portion of your gameplay is so repetitive it can be
> > performed by simply looping the same mouse-clicks over and over, you
> > already screwed up.
> 
> Anything macro-able and worthwhile (to the player) is going to be macroed.

Yes, I very much agree.  However: coming up with character-building
actions which are fun, challenging, and fairly non-repetitious - yet
reasnoable to impllement - is really, really difficult.  Hence you see
such things fairly rarely.

In my experience, the "easiest" design that can achieve this revolves
around simple actions that are done infrequently and in far-away places.
As an example: on Arctic MUD, picking a lock is really quite similar to
every other diku ever written.  However, the game keeps track of which locks
you have picked.  You can only learn on a given lock a couple of times,
and once you have learned once, you won't be able to learn there again
for quite some time (many RL hours).

As a result, a thief who wants to become a good lockpick (and it is a highly
sought-after skill, especially at high levels) must travel around the mud,
looking for new locks to pick.  After a certain point they will find themselves
needing to sneak past aggressive NPCs (sometimes very powerful ones) to
reach new locks to pick.

The "fun" is not in picking the lock itself.  It's in getting there.
Most of the other skills and spells are similar; the mechanic itself is
not complex or unscriptable.  It's the traveling around that is fun,
challenging, and virtually impossible to automate.

This relies on high-quality and -quantity zone content, as you can imagine.
Arctic has around 25,000 rooms, all high quality and made exclusively for
them, so it works well.

If you're using a randomly generated world ala Nethack, then this design
won't work as well.

> > At least combat, although repetitive, is fun.  Churning out thousands of
> > worthless items, or holding your place in line for your chance to get the
> > Sword of Lambada, is *not* fun.

Alright, let's get concrete.  (I know, it's rare on this list.)

Let's name off some good gameplay mechanics which are neither scriptable
nor boring, yet reasonable to implement.  Draw from your favorite existing
game, or (better yet) make up your own.

It's harder than it looks.  But I definitely agree that it is an extremely
worthwhile goal.

> Actually, that's a personal call.  I make bannocks (food) on MUME,
> something that takes considerable time, can be automated, and is *not*
> fun to many people.  I happen to like it.  I also happen to like
> exploring, and on the rare occasion when some evil thing crosses
> my path, I like to kill it. (Or, more often, be killed by it. :)

<nod>

You can't tell someone what's fun for them, as we've discussed before.
I have a bard guild that I threw in primarily for socializers.  There is
a very simple mechanic for them to sing songs using an instrument.  The
programming was quite simple; the prose I wrote for the songs themselves
is horrible.  (Yes, it's possible to use your own lyrics, if you prefer.)
A few of the songs have minor effects on their environment, such as making
people sleepy (usually causing yawns, but ocasionally they will fall asleep).

People *loved* it.  After the mud opened, I got more compliments from that
than anything else.  And it wasn't just socializers; one fellow OOC'd,
"woah, who prorgammed bards?  THIS K1CK5 A55, DUD3!!"  At first I thought
he was being flippant, but upon further investigation it turned out he
was perfectly serious.

You never know what players will enjoy.

Adam





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev