[MUD-Dev] Trouble Makers or Regular Citizens

[Zak Jarvis]

> From: J C Lawrence [claw at cp.net]
> Sent: Monday, April 24, 2000 3:02 PM

> On Mon, 10 Apr 2000 02:16:58 -0700
> Zak Jarvis <zak at voidmonster.com> wrote:
>
> > Very often, MUDs (and I use that in the broadest, most general
> > sense) play host to vicarious entertainment. There is a
> > fundamental crisis of structure, cohesion and social harmony
> > because the environment is *virtual*.
>
> Im GoP games (I'm not as clear on how this applies to non-GoP games)
> there is an inherent sense of allegiance and affinity among players
> due to the simple fact that all players (other than the game
> designers et al) are injected from the outside world into the game
> world and are thus all aliens holding their alieness and desire to
> survive/succeed in this strange world in common.  It is easy to
> create a sense of shared assault by the players on the game/world

My experience tells me that much the same phenomenon happens with socially or
role-playing oriented games as well. It's very common for players who are new to
the game to invent stories behind their characters which specifically give them
license to not understand or know the history and social structure of the world
they are in. Usually, once they learn the ropes a bit, they start creating
characters who are more fully integrated. Some players refuse to do this and
cart around the same character from world to world, but that's another topic
entirely. If the back story of the world doesn't to some extent take this
displacement into effect, (IMHO) the player culture can end up fragmented and
cliquish.

Ola's recent post about attracting players summed up many of these issues very,
very nicely.  As an aside, I've got to say I was extremely pleased that we've
already done a lot of the things in his checklist, in the game we're designing.
:)

> Teams, clans, guilds, etc can all tbe viewed as meta-forms of the
> basic cooperative wish to figure out survival within the game world.

Agreed.  However, there's a caveat to them. They can also bring long-standing
rivalries and interpersonal issues into your game that have been going on long
enough and bitterly enough that you as an admin stand no real hope of dealing
with them. Mind you, there isn't really a solution to that, exactly. It's just
one of those situational issues that has to be dealt in what seems like the most
appropriate manner (Banning, segregating, good long talking to, working with,
etc).

> > My sense is that trying ever harder to impose order is going to
> > push the designer more and more towards the role of despot.

> Dictatorial force NEVER works in any useful fashion unless it aligns
> with the basic needs and wants of the ordered, and even then it
> works badly and often unpredictably.  Try forcing a cat to eat now

I make an important semantic difference between dictator and despot. It's kind
of the erotica/porn argument. Porn is erotica you don't like. Likewise, a despot
is a dictator you don't agree with. It's a very fine semantic point largely
because not many people view the dictator in any positive light. However, my
theory is that the need for dictatorial administrative control is inversely
proportional to the size of your audience. Small audience: tight control, large
audience: loose control. However, your point about the dictatorial force needing
to be in-line with the wants of the players is the key element here.
Essentially, the more players you have, the less consensus there is on what is
wanted.

Of course, my views here are heavily colored by Machiavelli, who I consider to
be a great model for management -- if you use his own advice: Surround yourself
with the best advisors in the land, listen carefully to their arguments and
advice, and then do what *you* think is right.

> and not ten minutes from now (or to wash behind its ears).  Try
> forcing a kid to go to sleep (you can force them to lie down, sure,
> but sleep is a different matter).  Phyrric victories.  You might win
> the battles, but you will lose the wars (and quite a bit of skin in
> the case of the cat).

Well, from the dictator's perspective, that's what drugs are for. No arguments
about the cats though! I grew up with lots of outdoor cats. At the apex of their
quantity, we had to give them relatively regular antibiotic injections. I got to
do a lot of that fun myself, and I think I've still got the scars to prove it.
;)

> Leadership.  It doesn't have to be obvious.  It doesn't have to be
> overt.  It doesn't even have to be explicit.  You can finagle behind
> or in front of the scenes; agitate, foment, and curry all the
> changes you want, but none of it is going to happen until somebody
> else agrees and NOBODY ever agreed with you because you told them
> they HAD to agree with you, not even your kid sister/brother.

You haven't seen my methods of persuasion. ;) Seriously though, it's quite true.
However a good rule that either me or a friend of mine came up with. (I think it
was him, so I'll call it Beal's Second Law):

Never mandate what you can't code.

In other words, if you can direct the society through the actual code of the
game, the players will usually be more willing to accept it. If you can build a
game mechanic around it, they'll be even more willing to. (I'll be posting about
this in more depth within a few days).

> You can't usefully order somebody to be your friend.  But you can
> create that friendship and then use that friendship to help create
> other different things.  This doesn't have to be a conniving
> manipulative thing.  It can be a thing of simple friendship and the
> assistance one gives one friends (as a game designer you don't want
> your players occupying the position of "enemy").

As I said, this is something I want to write about at length. It's a pet area of
mine: abstracting social interactions, personal interactions, emotional states
and story into playable game mechanics.

-Zak Jarvis
 http://www.voidmonster.com





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