[MUD-Dev] players who "take away from the game"

Adam Wiggins adam at angel.com
Wed Nov 10 18:46:01 CET 1999


On Thu, 11 Nov 1999, Ola Fosheim [iso-8859-1] Gr=F8stad wrote:
> How will players know that it is a bug?  The assumption that players will
> think of an advantage as a bug assumes a rather homogenous imitating worl=
d
> and a knowledgeable player base?

No, but after playing a mud for a little while you start to learn what
the general world mechanics are, and when there's something that seems
to break those mechanics in a gross way, then it is probably a bug.

> Example: If I get one million gold for selling my first mushroom to a tro=
ll
> in the mountains, does that make it a bug?  I would call it a fortunate
> incident.

If you were a newbie then I would hardly expect you to report it; I certain=
ly
avoid making bug reports (or any sort of commentary at all, except perhaps
on the availibility of documentation) when I'm new to a mud.

If you've been playing long enough to know that a) trolls shouldn't ever
have that much money and b) trolls don't like mushrooms, then you should
probably bug it.  That doesn't mean that it *is* a bug, mind you: just
that you should report it.

> I think it is rather naive to expect the average user to report such thin=
gs.

*shrug*  I spend thousands of hours creating a game that I allow you to
play free of charge, and you think it is too much to ask that you take
fifteen seconds to type in a bug report?  Obviously this is a choice each
user makes.  But I have found that the muds I have tried to contribute most
to have, in the end, given the most back to me.  As an admin I try to
reward players who give frequent, useful bug or typo reports - usually
without their knowing (bumping up their stats a tad, for example).

> (Of course, there may be people that report your features as bugs too!).

Yes, this happens all the time.  The more unusual your mud is in a certain
department, the more you'll get reports of "bugs" that are supposed to
be features.

However, keep in mind that these reports are useful too.  If a given featur=
e
in your world is jarring and/or confusing enough to make more than one
person note it as a bug, then it's probably time to modify it to make
more sense to people other than you, or at the very least write up some
documentation that better explains the feature.  (The later is usually my
solution.)

> I wonder if admins kick people out because they exploit things, or becaus=
e
> the exploitations make the admins' possibly lacking design/coding abiliti=
es
> very visible! :^)

I rarely take any action as an admin against players, even though there are
plenty that I dislike.  If I'm playing a mortal and someone starts to bug
me, then I will behave just as I would on any mud: make use of my character=
's
abilities to get them out of my way.  (This could, of course, be anything
from casting 'silence' on them to killing them outright.)

Honestly, I don't *want* to scare away the types that find and exploit bugs=
=2E
Those people tend to be the "bug magnets" that find exploitable problems
in your game again and again.  Much like a sysadmin is glad that the
script kiddies are around to keep him on his toes, I want the people that
find and exploit bugs.  If those sorts of people are around and
still aren't finding any bugs, then I know that my system is pretty tight.

> Note 1: I'd rather not use a MUD where I have to learn all the tiny bugs =
in
> order to avoid stepping on them. That leaves little room for user innovat=
ion
> and immersion.

I never meant to imply this.  If a bug is tiny then probably the only
person who will notice it is the creator.  That's why I play mortals
very frequently; I find more bugs myself than anyone else, but that's only
because I know how the system is *supposed* to work. :)

Very simply, a bug is nothing more than a glitch in the game universe that
somehow disrupts the flow of the game, thereby reducing the (long-term)
enjoyment of the playerbase as a whole.  In some cases there are "bugs"
that turn out to be pretty neat; once identified, I generally declare them
a feature and change the code to enhance them rather than remove them.

> Note 2: I rarely submit bug reports in general because it is troublesome,
> unless the MUD has a snappy bug command.

Surely most modern muds have either a simple "bug" command or some sort
of direct line to the admin that you can type a ten word description of the
problem?

Certainly I'm way too lazy to bring up a seperate window to send email
or whatever...

> Besides, other people are likely to have done it already.

True, but different perspectives on the same problem make it easier to
track down.

> I don't like to do wasted work in my spare time.

*shrug*  If you're going to invest several dozen (or more) hours into
playing a game like this, surely a few ten-second bug reports are hardly
a waste?

> Note 3: Some designers are inclined to call design flaws "bugs".

They are.  So are errors in the terrain (for example, a description of
a door which claims to have a large lock on it, but trying to lock or
unlock the door reports that the door has no lock), or anything else
which breaks the consistency and enjoyment of your game world.

Adam W.





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



More information about the mud-dev-archive mailing list