[MUD-Dev] Real Life Consequences

[Jeff Freeman]

From: "Jon Morrow" <Jon at Morrow.net>

> Don't give players a chance to abuse a bug. Someone touched on
> developers taking responsibility for the integrity of their work.

Battle-cry of the ethically challenged.

Ultimately, the developers do not suffer from bug-exploitation, but
rather, the other players do.  In a commercial environment, this means
you have a bunch of dollars telling you to stop some smaller amount of
dollars from ruining the game.

> Forgive me for not citing the paragraph, but I agree wholeheartedly.
> I don't believe developers lack pride in their work.  But many MUD
> hobbyists also enter the commercial gaming world without any formal
> education on quality-control.

Not to be flippant, but so what?  Fewer bugs don't mean that there
won't be ANY bugs.  The question is what to do about the bugs (and
exploits) that do arise.  Not how to prevent ANY bugs from occurring
in the first place.

It's an admirable goal to shoot for: Don't have any bugs.  But it's
unrealistic to expect that you won't actually have any bugs for people
to exploit.  If your best game plan when someone discovers a bug and
exploits it is to say, "Wow, I didn't think we'd have any bugs in THIS
product!" then you'll just be unprepared.

> My friends, it is possible to implement nearly bug-less code after
> putting it through rigorous testing.

"Nearly" isn't good enough.  "Nearly" means that occassionally you'll
have a bug, and someone will exploit it, and then they'll tell 100,000
other people how to exploit it.

> It may delay the speed of implementation into the main environment,
> but players will appreciate the resulting stability.

No they won't.

What player's want is for Star Wars and UO2 and Shadowbane and Dark
Age of Camelot and EQ2 and D&D-Online and everything else they've ever
so much as heard a rumor of, to be released *today*.

Failing that, they just want these games to be released *someday*.

Considering that "delay the speed of implementation" equates to "no
longer profitable to produce, so cancel it", the players don't
appreciate that at all.

> If my memory serves, correcting a bug before implementation
> frequently takes 20 times less time than fixing it afterwards.
> Steve McConnell discusses this issue extensively in his enlightening
> books.

There are bugs you won't even know need to be fixed until several
hundred thousand players start picking apart the product.  Nice QA
department there...

> In my experience, successful, smaller games also respond more
> creatively to the desires of players, generating an atmosphere of
> goodwill.

Ah, another candidate for Laws of Online World Design: "Goodwill"
doesn't scale.

> Such an atmosphere makes the old saying, "don't bite the hand that
> feeds you" much more appealing.  Instead of attempting to control my
> players, I'd like to try eliminating the need to control them.  I've
> long been an advocate of self-correcting communities, where
> troublemakers are quickly punished by empowered and trusted
> citizens.  They might even reduce corporate legal constraints.

Personally, I *love* that approach, but it mandates a massive number
of low-user servers (relative to the current and upcoming crop),
versus fewer servers with more people on them.

> I realize that this entire post is quite utopian.  Just thought I'd
> through out a bit of controversial philosophy to keep the thread
> going

Apart from all the above cynicism, I like the idea of smaller,
user-controlled servers vs. large nanny-state servers.  But I don't
think "eliminate all the bugs prior to release" is a realistic
solution to the problem of bug-exploiters.

You *can't* eliminate all the bugs, and if you have thousands upon
thousands of users then you'll have one cubic crapload of
bug-exploiters regardless.



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