[MUD-Dev] List rituals

Travis Casey efindel at earthlink.net
Wed Jul 4 15:39:57 New Zealand Standard Time 2001

On Tuesday July 03, 2001 22:35, J C Lawrence wrote:
> Travis Casey <efindel at earthlink.net> wrote:

>> Well, it doesn't even apply to all GoP games.  For example,
>> consider a mud where the setup is one group of players
>> vs. another -- it's a GoP mud, with a goal of "defeat the other
>> team", but there's no struggle between players and the game's
>> designers/builders.  Thus, there's no reason to hide your
>> strategic communications from the designers.

> Sure there are, if you suspect that you are taking advantage of
> techniques/capabilities the game designers didn't intend you to
> use.  This is possibly the most basic and common player vs admin
> scenario.

>   "I don't want the admins to know how I am doing this or they
>   might change it."

This doesn't disprove my point, though -- it's still possible for
there to be GoP muds with such a setup where there is no need for
the players to hide info from the designers.  All you're pointing
out is that for *some* muds where the players are not explicitly
against the designers, players may still have something to hide from
designers.  That doesn't mean that has to be true of *all* such
muds, though.

To a large extent, it depends on the "culture" of the game.  Some
cultures may accept the use of bugs and unintended features as being
part of the game, while others do not.

>> In a mud, this kind of trust generally doesn't happen, because
>> the players don't know the GM personally, the way they do in a
>> pencil-and-paper RPG.  Further, the same level of trust isn't
>> necessary, because a mud GM generally *can't* change the
>> capabilities of monsters, the existence of traps, etc. instantly
>> and seamlessly, the way a pencil-and-paper GM can.

> Additionally in a MUD the GM is perforce operating a t a more
> abstract level generally manipulating systems which affect all
> players in some fashion rather than a particular special
> case/scenario for a small set of players for just one lazy
> afternoon.

I wouldn't say "perforce" -- this is generally true, but there's
nothing that *requires* it to be true.  For example, if you consider
NWN to be a mud, then an NWN GM may well be running a scenario for a
small set of players for just one lazy afternoon.

>>>> This is both a blessing and a curse, though -- if the players
>>>> are truly free to come up with creative solutions to obstacles
>>>> they encounter in the game, then the amount of work that the
>>>> game designers and builders have to do goes up exponentially,
>>>> since they have to try to anticipate the creative solutions and
>>>> guard against them in some way, so that they don't become easy
>>>> routes to success.

>>> Quite.  Complexity theory comes to dominate and balance
>>> calculations tend to go out the window.  About the only approach
>>> then is to make balance calculations dynamic based on observed
>>> action.  This tends to unfairly (?) penalise the skillful, as
>>> well as unfairly (?)  advantaging the rummager in out of the way
>>> places and challenges.

>> I'm not sure what sort of balance calculations you're referring
>> to -- do you mean calculations used to establish a "difficulty"
>> for a task, so you can set a reward for the task based on that?

> Both a difficulty and a reward/effort calculation.

For a roleplaying environment, a reward/effort calculation may not
even be needed -- the "reward" is in playing your character, and
having fun doing that.  For example, I ran a D&D campaign centering
around a paladin that went on for about 10 years.  Reward for effort
was not a major consideration there, because the paladin was doing
things not for any material reward, but simply because it was what
he was supposed to do.

       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list