[MUD-Dev] Remote client connection

J C Lawrence claw at kanga.nu
Thu Jun 22 23:25:07 CEST 2000


On Tue, 20 Jun 2000 14:33:03 -0400 
Phillip Lenhardt <philen at monkey.org> wrote:

> A multiple choice mud interface could be just the thing you need
> to help direct players to the meaningful choices presented by a
> situation instead of implicitly allowing them to do meaningless
> things.

What is the definition of "meaningful" in this context?  Who defines
both the context and the definition?  Is it the game designer, the
implementor, the player, or some other party?

Every player playing your game is playing a different game from
every other player playing your game.  This is true for single
players games, and more particularly true of multiplayer games.
Heck, Raph has even collected a law on this point.  As a game
designer or implementor you have absolutely no idea game your
players are actually playing.  One thing you do know, with almost
perfect certainty, is that if they have been playing for long enough
to be more than comfortably familiar with your game is that they are
not playing the game as you designed it, but are playing a meta-game 
which they devised.

Of late I've taken the habit of playing Quake CTF during long
software builds.  Thing is, tho I'm playing on a CTF map (I only
play town2) with (presumably) CTF players, I don't play that game.
The game I'm playing is one of two:

  -- As a sniper, how many single shot kills can I make in a row of
other players I am unable to actually see from my current position
(ie they are hidden by shadows or intevening objects).  If any one
of my shots misses or doesn't kill, or if I kill a player I can see,
I lose my game and quit.

  -- What is the minimum length of time required for me to get
either 3 or 10 frags wihout being killed myself.

I used to play the arcade game Tron a fair bit (now I play it under
Mame).  I didn't play the intended game of knocking my opponent off
his platform.  Instead I played the game of how long I could
possibly make a level last by shooting the opponent's frisbees
without knocking him off his platform.  IIRC I once spent a very
enjoyable (and low scoring) hour getting up to level 3.

The mechanics of both Tron and Quake are extremely constrained so
there is little opportunity to create much in the way of meta games, 
yet in both cases I no longer play the intended game in any way.

No consider a more flexibly mechaniced (if that's a word) world,
where the range of designed-for possible activities and purposes for
a player are much larger.  Concomitantly, the range, ease, and I'd
argue probability of that player playing a meta game are much
larger.

One of the early problems or successes (depending on how you looked
at it) was players going and finding monsters, trapping them,
herding them back to their houses and the renting them out to other
players for sparring partners.  That certainly was not an intended
player game.  This was not a designed for game.  It was not a
designed for mechanic.  It was not a designed for activity, and its
effect on the game balance and the world's logical pattern were
unsubtle.  

Conversely, it was an excellent demonstration of player ingenuity
and of the flexibility in UO's world implementation.  It could be
considered a prime example of a manner in which players had proven
that the game world was really real in important fashions, and had
thus given them a means to invest themselves in the game world and
thus create anew it in their own fashion (ala nest building but on a
less homey scale).

Could any of this above really be accomplished on a multiple choice
system?  Should it?

At an extreme, multiple choice systems define the game designer as
the prime viewpoint and the player as almost a passive theatre goer
who merely goes along for the scripted ride provided by the game
designer.  Its a Disney-style amusement park where you sit safely
belted in your coach and watch the sets scroll past you.  Why?
Because the game designer is the only one who has both the
opportunity and the means in multiple choice systems to define what
has meaning, and what is important to the player and his character.
The player has no ability to intervene, and say lead the
conversation with an NPC in another direction, or go do something
utterly irreverent that the game designer never bothered to think
of.

I argue that one of the prime values in a MUD, and this is the thing
which elevats it in various essential fashions, is that the player
is continually confronted with the question, "What shall I do now?"
and there is nothing and nobody to tell him that answer but him.

The player is the one who creates the game for himself.  Not you,
not other players, not the game designer, not the implementors, not
the mass media, advertising agencies, or any other third party --
only the player.  He may be influenced by all the aforementioned,
but in the end, its just him creating something that has meaning to
himself.

Consider the problem of the Stamp Collector (see the Laws and then
the List Archives).  Such a player is very definitely playing a
game.  He's just not necessarily playing the same game as anyone
else, or even a game that particularly relates (well) to any other
player's game (which doesn't necessarily reduce the significance of
his effect on other players), or any of the games which the game
designer had in mind for the system.

In the end the only important things are what go on inside your
player's heads, and then what they do because of that.  More
importantly, it is your players, your arbitrary, capricious,
ingenious, sabotauging, crotchety, uncomprehending, annoying players 
who define what actually is "meaningful".  

After all, who cares if something is meaningful to you the game
designer if the players don't agree?

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


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



More information about the mud-dev-archive mailing list