[MUD-Dev] Player-admins, was wimping/wiping and the big blind spot
Patrick Dughi
dughi at imaxx.net
Thu Aug 3 11:32:34 CEST 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
playability.
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.
PjD
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list