[MUD-Dev] Persistent Worlds

John Buehler johnbue at msn.com
Fri Feb 16 12:14:58 CET 2001


Matt Mihaly writes:

> Yes, it's not realistic to have re-popping mobs. Of course, dragons
> and magic are also not realistic, and neither is eating and never
> having to use the bathroom.

Having to eat is generally not entertaining when your senses are
limited to sight and sound.  Having to use the bathroom isn't
entertaining regardless of your senses.  Having dragons and magic is
entertaining.

Is having monsters and other beings spontaneously pop into existence
entertaining?  I would argue that it is not.  Why?  Because it
gratuitously detracts from the sense of reality that the game
experience is attempting to provide.

And because I've provided myself the segue...

Magic and dragons are entertaining.  But they both also detract from
the sense of reality in the game world, just as I've opined that
spontaneous generation does.  Does this add to the 'gameyness' of the
virtual world experience?  Is 'gameyness' an undesireable aspect of
these applications?

Gameyness would tend to suggest to players that none of their activity
is at all related to the real world, so they don't behave in real
ways.  Teleportation, fireballs and the like are constant reminders
that the virtal world is not real, and players will have a tendency to
not bother suspending their disbelief.  They just won't bother with
believing that it's a virtual world and instead just do whatever they
feel like.  In the case of EverQuest, that means exploiting the
software and optimizing gameplay as much as possible.

We refer to these applications as 'games' and to the users as
'players'.  As if it was a card game or a board game.  In card and
board games we sit down, start, play competitively, win or lose,
repeat until our desire for that form of entertainment is sated and
then move on.  In large part, that's what we do with single player
computer games.  But is that pattern at all applicable to what we call
MUDs?

I believe that applying the term 'game' to MUDs (etc) is a fundamental
problem.  This is partly true because it sets the wrong expectations
of the users.  But if not a game, what is a MUD?  I've used the
Disneyworld analogy before and I'll suggest it as a more appropriate
model for referring to MUDs.  Should we be referring to Achaea as a
theme park or as an amusement park or something similar?  Should the
people who spend time there be called visitors and/or guests?

If Achaea was a physical park with little robots running around, and
park guests visited Achaea in southern New Jersey, they might walk up
to a Myst-like device with levers, dials, a display screen and lots of
steam pipes.  Through that device, the park guest would control their
robot.

Is that a more appropriate way to have users approach these programs?
In all documentation for MUDs, they are referred to as games, and the
users are players.  Should the words used by the documentation change?
Should there be a natural separation of character and player?  Should
the documentation say things such as 'the character' instead of 'you':
"When you draw your sword..." would be replaced by "When the character
draws its sword...".  Why bother?  So that your park guests understand
that they don't *own* anything (leading to a recent thread's topic),
and that they think of the whole experience as NOT being just another
single player game in which they can do whatever they like.

The use of the theme park notion is an attempt at legitimizing or
mainstreaming the MUD.  I want park guests to think of themselves as
park guests instead of game players.  Does a park guest typically
bother with trying to figure out how the rides work?  Generally not,
although I'm sure there's a disproportionately high number of people
on this list who might be interested in such things.  Most guests just
ride the rides because they're entertaining.  If a MUD were
sufficiently entertaining, and the theme park paradigm were used in
all ways that the MUD presented itself to its users, I wonder if there
wouldn't be natural tendency for the park guests to behave in a rather
different way.  And it might very well attract a different kind of
customer.  That casual player.

This treatment of the MUD would have to permeat *every* interaction of
a park guest with a representative of the park.  Every employee of the
park, every document, every image that is presented by the park would
have to reinforce the idea that the virtual world is a theme park.
Maybe 'adventure park' is the best term.  It would mean that the
gamemasters (which would be refered to as NPC wranglers) don't hop
into the park and start adventuring for their amusement.  They are
park employees and they treat the park guests with as much respect as
they can muster.  Their job is entertaining the park guests.

The terminology and presentation of MUDs seems to be a bit of a
stumbling block.  Are MUDs (etc) ready to move to the 'adventure park'
level, or do we still have a ways to go before we can attempt the
transition?  Is the transition desireable, or do folks consider
keeping MUDs as 'games' to be 'played'.

After having said all of that, you should realize that I am not
someone who believes in significant immersion in the 'virtual world'.
The 'adventure park' analogy works well for that aspect of things too.
Significant immersion leads to excessive emotions about virtual items
- and people start wanting to buy and sell the darned things.  I have
no problem with folks getting bent about the behavior of real people,
but if the model is one of an adventure park, a somewhat lighter
attitude might be generated about adventuring in the park.  It
wouldn't be an alternate life, it would just be an entertaining
adventure.

Such a model will not appeal overmuch to hardcore gamers who want to
build that alternate life.  But I'm hoping that it will appeal to the
more casual folks who are just trying to kill a couple hours doing
something fun.  Not 10 hours a day trying to build an empire.

JB

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



More information about the mud-dev-archive mailing list