[MUD-Dev] Player-admins, was wimping/wiping and the big blind spot

Patrick Dughi dughi at imaxx.net
Thu Aug 3 11:32:34 New Zealand Standard Time 2000

 	I was struck by a theme in the previous post between Peter
 <malaprop at malaprop.org> and Adam <adam at treyarch.com> regarding the player
 wiping, etc.  In particular, the segment below:

On Thu, 03 Aug 2000 01:20:33 -0500 Peter wrote:
> Peter: 'I've been trying to think of a nice way to say, "Well, fucking
> duh, go out and play! Get out of your ivory tower! We play games down
> here and you should join us here in the real world!" But so far words
> have failed me.'
> Adam: 'nod, they'll tell you that they are too busy coding to play'
> Adam: 'it's an easy trap to fall into'
> Peter: 'Ugh, how can you code if you don't know what's fun?'
 	I have to raise a complaint against this mindset, as I've
 encountered it many times in the past and found it to be poorly concieved.
 You do not have to play a game in order to know what would be good or bad
 for your game, for in truth this is not that difficult of a thing.  Liken
 this acting; generally you can be a method actor and take the role upon
 yourself, or you can be a technical actor, and present yourself in a way
 that you think the audience will best appreciate.  As a mud programmer,
 you can choose either path, to play and be involved, or to stand off and
 closely observe.  Both have their points;
 	Playing and being a part of the game is useful to gather directly
 the data that you otherwise would depend on others to generate.  You know,
 based on your preconcieved notions, how difficult or easy something ought
 to be.  After all, when you wrote it, subconsciously or not, you kept
 saying to yourself "This should be a hard mob to kill (if someone were to
 level and achieve at the same rate I would)," or "This is a reasonable
 amount of treasure (if I were receiving it)".  Being on the same level as
 the players, you can't help but see these deficiencies.
 	This is also where the problem lies.  As a player, your
 preconcieved notions take on a subtle pro-player cast, often at the
 expense of the entire mud.  That is to say, you loose your objectivity
 which allowed you to generate a well oiled interconnecting series of
 systems (combat, exploration, socializing, etc).  It's replaced with less
 of a game-orientation, and more of a personal, individual orientation.
 	By this, I do not mean player (as in all) orientation, but as in a
 selfish, individual orientation.  This normally makes life easier for
 players - as the admin making the change in focus is now one of them.  
 Let me give you an example:
 	On a specific unnamed circle-based mud, the implementor there had
 a thing for the dark and gothic style of life.  In practice, this
 manifested itself as a penchant for playing evil-seeming but misunderstood
 heart-of-gold type characters, such as thieves, necromancers, and
 vampires.  Over the three or so years I programmed there, I noticed a
 trend in the game focusing on these classes or afflictions.  Thief classes
 were slowly integrating other classes skills, necromancers were adopting
 clerical abilities (ability to heal, etc), vampires well... were being put
 in a position to become the holy grail of the mud.  With level-based
 equipment, the top weapon for each general level division was always a
 dagger (a stabbing-weapon, since only stabbing weapons could be used for
 the thief backstab attack).  Combat was focused on making several
 uninteruptable high-damage attacks and fleeing before you could be struck
 back - of course, only the thief class could perform this efficiently.
 	The implementor boasted having a character (thief of course) which
 had never been beaten by another player killer, yet had gained all eq and
 stats in a 'legal' manner.
 	In the course of debugging, I had noticed (thanks to player cries
 of cheat and unfairness) that the backstab, and other commands which were
 obviously using backstab as a template were written with a delay in them.
 This delay would make it necessary to engage in combat for a certain
 period of time before they had the chance to leave combat (though usually
 by then they'd be locked into it), however it was put in a check which
 would always fail though an odd series of events.
 	After fair discussion and notification, this oversight was fixed,
 which still came as a blow to many players.  It was slowly accepted
 though, and our mainly thief-only PK population started to revitalize with
 new tatics being introduced.  The biggest row though, came from the
 implementor.  No longer was the thief the automatic best choice; "I did
 that on purpose, so the thief would be a better class!", or "How can they
 compete in combat with straight warriors now?"  After logging in their
 characters, and engaging in battles which were probable losses to begin
 with (and loosing) with their most powerful players, I was treated to a
 royal row.
 	After loosing the objectivity needed to think in regards of total
 mud playability, the implementor here was unable to arrive at a rational
 decision.  They were all "Well, my player sucks now!", which was
 generalized as "All thieves suck now, and we'll lose all our players" -
 which wasn't actually even echoed by the playerbase as a whole.  Most
 players wanted it so they could play _their_ class and still be in the PK
 arenas and have a half chance of winning.
 	The claim was that I, as a non-player, did not understand the
 ramifications of the change, and had made a poor decision.  As a
 comprimise, I suggested placing similar abilities for each other class,
 but was derided as the proposed abilites (equal in rate, damage, and
 success) were considered 'way too powerful' to put in the game.  In the
 end, I had to change the success percent of the flee command.
 	Thoughout this all, the constant claim from the implementor was
 simple; "You don't play so you wouldn't know."  My claim was just as
 simple; "You don't have to play to write code."
 	This cycle is not assured though - many admin/etc start out with a
 very objective mindset.  Over time though, their emotional investment
 tends to do it's work.  The admin's players soon become more important
 than the game viability.
 	The problem with generating a game system dynamically that you do
 not experience yourself is of course, one of feedback.  You have to depend
 on others, and you have to put that through your own internal mental
 filters.  Unlike the simple-seeming experience you get from the above
 method, you have to form an opinion based on the actions of many players
 over a period of time, and then use this to affect your initial reaction
 or conception to an event.  This takes time and effort, and is potentially
 error prone, though I have yet to see a circumstance where this has been
 employeed and errors do exist.  Unlike a commercial game, feedback
 response can be near-instant, heading most errors off before they affect
 	Of course, you reap great rewards; with a coding/building/admin
 staff who are not players, you maintain absolute objectivity.  You aren't
 locked into a bubble of "What would I do?", or "What would I want?".
 Instead, you have the freedom to question the players, or yourself - and
 in this manner, your ideas and the players have equal weight, where as a
 player, your ideas tend to override the group.  In one instance, this was
 applied to builders - if you built for a mud you were under certain
 playing restrictions.  You could not enter the areas you created, and
 revealing or using admin/builder knowledge to gain an edge resulted in
 immediate deletion of that character.  This stopped the age-old custom of
 the builder of a zone immediately obtaining the best items from it first,
 completing all the static quests, and generally considered to have 'beaten
 the zone'.   
 	There is one other great problem that I see though, with this
 stance.  Those that do not adhere to it (or at least, acknowledge it),
 instantly cry foul when they see others using it.  Having played RPG's for
 at least 10 years before I even heard of a mud, and then mudded like mad
 for several years afterwards, I feel I have acquired the basics, and so
 too have many others.  Tempering this knowledge with the constant feedback
 a mud generates should be enough.  It seems for some, it is not.

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

More information about the MUD-Dev mailing list