[MUD-Dev] Mud governance

Mike Sellers mike at online-alchemy.com
Mon Oct 20 22:45:47 CEST 1997


At 09:55 AM 10/20/97 PST8PDT, Felix A. Croes wrote:
>> Hi guys, I'm looking for documents on mud governance and 
>> administration, and you're the best bunch to ask. Things like the 
>> section of Javelin's PennMUSH document covering tips for mud admins, 
>> or Amberyl's Wizard Ethics document (which I haven't been able to 
>> locate, ftp.tinymush.org never seems to connect). This is for the 
>> purpose of educating new admin staff... I also intend to salt 'em with 
>> a few things like Dibbell's Village Voice article, Bartle's paper, and 
>> the log of the Black Rose incident (as a negative example). Got any 
>> other favorites?
>
>Sorry, can't help you there.  In fact, I am very curious about what
>you might be able to tell us.  How <does> one administrate a mud with
>a thousand of players online?

Well, I have to admit this is a difficult but very important issue... but
unfortunately I find myself unsure of how much I can or should say on this
subject.   Clearly, having seasoned, dedicated admins is a necessary but
not sufficient part of the equation.  In terms of educating your current or
potential admins, I think you're on the right track with the sources you
mention, Raph.  I'd recommend Sherry Turkle's writings too, and probably
some of Howard Rheingold's.  Make sure they read the Habitat papers.  

Beyond that, I'm increasingly of the view that, wherever possible,
governance should be made part of the game, rather than separate from it,
and that admins should interfere with the game and the players as little as
possible.  Incidentally, after my experience as Meridian, and having seen
the first-hand experiences of the individual Guardians on M59, I would take
precisely the opposite approach as "Lord British" in UO; in an online game,
celebrity is both a potent drug and, like so many drugs, inevitably
pathological from a personal and community perspective.  In other words, I
would say that admins should be as anonymous as possible, so as to perturb
the player-community as little as possible.  

>> ObDiscussionTopic: to what extent should mud governance be an issue in 
>> server design? And related to that, what then needs to be implicit in 
>> the server design to support governance by an administrative staff?

Both in-game governance and out-of-game administration are integral to
server design.  For example, admins clearly need to be able to _safely_
access player-data, if for no other reason to forestall spoofing (is that
what you meant?).  I would advocate limited and somewhat transferable
"special powers" for players for in-game governance, so as to handle
player-player disputes and that sort of thing (I've written more fully
about this elsewhere).  These too, and the larger social structures needed
for player-governance, should also be designed into the server early on.  

>If the goal is to reach an ideal mud, there are three factors involved:
>
> 1) that which can be enforced in code
> 2) that which the players can arrange for themselves
> 3) that which the administrators must impose
>
>A good design minimizes the third factor.  The type of mud is determined
>by the balance between these three.  For instance, if player killing is
>considered to be the ultimate form of harassment, it can be eliminated in
>code.  On the other hand, player killing can also be considered a tool
>for a self-governing mud population.

Agreed.  From my experience, I would say that player killing can be a great
tool, if properly handled (and I'm not saying we handled it entirely
correctly).  As much as possible, outside of issues like _real_ and serious
harassment or cheating, I would say that the players should handle as much
of their own regulation as possible.  It not only lowers your admin load,
it actually generates good game play too. 

Mike Sellers                                    Chief Alchemist
mike at online-alchemy.com                         Online Alchemy              

        Combining art & science to create new worlds.



More information about the mud-dev-archive mailing list