[LONG] Theories in Gaming

From: Michael Gesner (dabion@WPI.EDU)
Date: 03/14/01


I suppose I should preface this e-mail with a bit of background.  I am the
President of the WPI Game Development Club.  I founded the club with two
other (now graduates) in order to push the development of games on campus.
We have a pretty decent following.  I spend quite a bit of time lecturing,
and presenting to members, and as things have panned out, I have begun to
form my own conceptions of what makes a good game.

In light of this, I wanted to throw this to the list, specifically detailed
to what makes a good MUD.  I figured if anything, it might generate some
discussion.


In order for a MUD to function, and more importantly, capture an audience
of dedicated players and staff, it must be unique, enjoyable, and simple.
This combination of factors is at times, very difficult to master.
However, by implementing a MUD in the following fashion, an inexperienced
Implementor can come up with a rather unique and enjoyable game.  Moreover,
experienced Implementors can develop their ideas to truly capture the
target audience they seek.

I.  Background
    "Your codebase depends on your history"

    Before you sit down to hammer out code, consider the fact that no
matter how original the code may be, if you have the default zones and
story, your MUD is still a stock MUD.  In every sense of the word, the
original zones cause a MUD to look more like a stock MUD.  In a more
refined sense, the primary source of originality will come from the
history/setting of your MUD.  Its not so much the time period that will
make the MUD original as the representation.

    This requires you, as the implementor to do some creative research.
The primary reason to this is to give your setting/situation depth.  For
instance:

        If I declare that Society A is in a period of nuclear fallout, and
simply continue with that idea, but have no lead to what caused the
fallout, or what places are experiencing the fallout, your staff will not
always have similar ideas as to the direction of the game.  Some builders
may believe that the cause of the nuclear fallout was in china, while
others believe it was in america.  This will be both a conflict of
interest, and in the sense of the game, conflict of logic (unless that's
what you're looking for)

        Whereas, if I declare that Society A is in a period of nuclear
fallout due to a massive worldwide struggle for power, where the Americans
fired first... and destroyed all of civilization other than the remnants of
washington DC... then my staff has a clear starting ground.  Everyone can
relate to the background of the story, and can more closely tie their
zones/areas together.

    The basic point, is that every good MUD must have some semblance of a
background.  Whether it be a simple text which reads, the duties of your
character are to do the following, or if it reads like a story, the players
and staff alike must have some semblance of direction in the game in order
for a MUD to be successful (considering the bounds of the currently
implemented AI systems)

II Depth

    Any Implementor can flood a zone full of unique NPC's and let players
hack and slash their way through to the end.  A truly entertaining MUD will
incorporate more intuitive features into the game in order to keep players
coming back to play.  Moreover, the Implementor will require some level of
thinking on the human player's part, even if the puzzle is directly related
to combat itself.

    Consider the case of a MUD that has one command.  The command is kill.
If I kill an NPC, I gain experience.  If I gain enough experience, I gain a
level, and I'm harder to kill, and I kill things easier.  Considering this
idea, if I ran through a zone full of monsters I could kill continuously...
I could theoretically gain the number of levels I needed to take on any
creature in the game.  This style of gameplay on its own requires no real
problem-solving.  More importantly, this style of gaming requires no real
thought from the player whatsoever.

    With this in mind, killing should not be the ONLY task that is
important in a MUD.  A MUD requires depth to be interesting.  Although the
FOCUS may be killing, this doesn't necessarily mean that the game itself
only requires one command for advancement.  Large zones, varying terrain,
varying NPC's, quests, games, and intellectually challenging activities
will draw players to continue to play.  In the largest sense of the idea,
the more you give a player the ability to do, the longer you will keep them
happy.  Whether or not they actually use those abilities.

    The balance comes in actually facilitating the player's needs without
overdoing the system.  By becoming TOO deep, a system can become confusing
and will cause quite a bit of overhead.

    In easy terms:
        Consider the following:

            A MUD with 10 commands
                Easy to learn
                Not much to do
            A MUD with 6000 commands
                Hard to learn
                Tons to do
            A MUD with 100 commands
                Easy to learn
                A little to do

The balance of a MUD's depth is commonly found in the target audience.  If
you are creating a game for a highly technical audience, chances are that
they have the capability to handle some of the more complex command sets
and zone descriptions, where if you were designing a game for small
children, this would not be the case at all...

III. Standards

    One of the issues addressed earlier on this list was the issue of
distributing ZipMUD's.  In the context of the Standards issue, ZipMUD's
help facilitate the distribution of a MUD'ing standard.  CircleMUD is a
common format for MUD's these days.  Most of your playerbase will commonly
be familiar with other MUD's of the same genre or type.  Whether they be
circleMUD or some form of MUSH, the interface must be simple enough for
players to grasp quickly, but unique enough to draw their attention.

    Standards in the finest sense of the word, are primarily a part of
MUD's for the ease of the player.  One of the most important things that
newbies miss... is the level of standards within the currently distributed
ZipMUD's.  These MUD's are well designed, and well written.  They are
written for easy navigation, and simple understanding in mind.  The reason
that they are not popular isn't for their level of standards, but for the
fact that they are so widely distributed.

    One common mistake, is that standards often are associated with the
term "stock".  This is a rather invalid term.  Standards are accepted
across the board within the community.  Some stock installations may comply
with these... others may not.  For instance, the world files across the
board in circle are standard... but the ascii pfiles system is not...

    To recap, standards are designed to allow players to easily understand
how to OPERATE the game, more than to make users believe that you are
running a stock install.

    With this in mind, you must balace your level of standards with your
level of creativity in order to allow players to understand how to navigate
the world easily.  This is a delicate balance which requires the
observation of your mortal characters in order to more fully understand.

***SUMMARY

    A good MUD is not simply a mess of well written code... Along with MANY
other elements than I have listed here... a well written MUD is constructed
of a series of components which may take months or years to develop.  The
best MUD's will continue to develop these in order to more fully facilitate
its audience.

    I hope that for some of you newbies out there... that this helps... and
I would appreciate comments... (it is 3 in the morning... so I know some of
this sounds like drawl...

Michael Gesner
Lodaren of Rhu-Dina'ar
rhudin.newvisiongames.net 7777

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/04/01 PST