[MUD-Dev] Re: what's fun?

J C Lawrence claw at under.engr.sgi.com
Fri Jun 26 14:21:52 CEST 1998


On Tue, 16 Jun 1998 10:53:23 -0700 
Mike Sellers<mike at bignetwork.com> wrote:

> Here's a point that was raised recently in another discussion, and
> that I thought might interest people here: Part one is, what is your
> succinct yet broadly-applicable answer to the question "why do
> people play on your mud?"  

To be able to create an effect, preferably lasting, on others and on
an enjoyable shared fantasy.

or alternatively "what sorts of play are
> you trying to reward on your mud?"  

> Part the second is, "what do you do to maintain/enforce this?"

I rather like the idea of an administrative prime directive with an
associated manrta.  Perhaps:

  "Only make administrative decisions that apply to the entire user
   base."

With the converse:

  "Never make an administrative decision which is targeted at or only
effective on a subset of the player base.

> What is it that we consider "player fun" after all?  

Mot of it really boils down to the achievement of goals.  The
achievement of, and progress towards the achievement of goals is
"fun".  Not achieving goals, and failing to progress towards them (or
even regressing), is not "fun".

> Does it all come back to Bartle's suits?  

Anhh, that merely attempts to classify goals.

> And how do we react when two players' otherwise valid forms of "fun"
> collide?  

We either do nothing, or we impose an arbitrary in selecting one over
the other.  The important bit is to recognise it as an arbitrary.

> This is the essential player-management task of any
> admin/wizard/customer-service-type person.  I'd be interested in how
> people address this in their games.

Way back in the dawns of time databases were kept in card files.  It
actually was a very clever system.  In each card's upper edge was a
row of square holes.  Some holes had been punched out, forming divots
in the card's upper edges, and some were still closed.  

  +-------------------------+ +----------------+
  |     +-+                 | |                |
  |     | |                 | |                |
  |     +-+                 +-+                |
  |      \                   \                 |
  |       closed hole         open hole        |
  |                                            |
  |  This is a data card                       |
  |                                            |
  .                                            .

A card would have many such open or closed holes along its top edge,
Sometimes twenty or thirty, tho most I recall having a dozen or less.

This formed a simple yet flexible indexing scheme.  Each hole position
represented an index key.  You could a big long tray/drawer of such
cards, and run a long thin rod down one of the hole "lines" in the
card deck.  Lift the rod and only those cards with closed holes in
that postion would rise.  The open hole cards would stay still.
Voila!  A simple SQL select statment!  Run two rods thru different
hols, lift them together, and select only the cards that were on both
rods for an AND on two fields (or do successive selections).

Actually the cards were typically metal and were address plates, but
that is a different matter.

The story done, I tend to look at game design and administrative
character in the same way as I think of those rods piercing the card
decks making their selections.  The rods were blind, and infallible.
The rods made no moral or otherwise soft decisions, and they applied
themselves blindly to every card in the deck.

I look at game design features the same way.  I make changes, perhaps
altering a game feature, adding a new one, or perhaps a twist, and its
like running a new coloured rod thru the deck, possibly punching a new
index line in the deck.  It opens new possibilities, and it doesn't
care who it applies them to.  It adds a new line of bleeding colour to
the deck that slowly fades out into the rest of the multi-coloured
system.

There's a pithy quote I'd love to remember so I could insert it in
here having to do achieving governance of individuals by only
governing the group (I think by a British Empire colonial).

If you feel you have to pervert or special case the system to handle
one particular player (or a small group of smallers), then you've
already lost the war.  Moving back to the meandering streams wending
across the valley floor, you're attempting to damn a stream by
dropping a rock in its way.  Its not going to work -- the water will
instead undercut, undermine, damn and overflow, and work around that
stone as an obstacle to its rightful course in life.  Its not going to 
nod politely and go do something else.  Gravity doesn't work that way.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list