[MUD-Dev] Real Life Consequences

[Michael Tresca]

Jon Morrow posted on Monday, February 19, 2001 10:00 PM

> 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.  My friends, it is possible to
> implement nearly bug-less code after putting it through rigorous
> testing.

It probably is.  However, I've witnessed MUDs who "were down for bug
fixing" never recover.  We've made it a policy that RetroMUD stays
open at all times, always, regardless of when there are bugs -- we
just tell the players about the bug and we work on it.  What happens
is that the players switch to the social aspect -- they idly chat
about other parts of the game, talk about each other, and otherwise
NOT play the game but continue their social interaction.

At the end of the day, quality was not the issue -- players played
when we were crashing every two hours and struggling to fix the game.
They joke about it, but they played even then.

This translates to a very disturbing fact: the vast majority of
players are accustomed to imperfect code.  Why?  Because nothing's
bursting into flames.

This goes back to the physical threat of a negative response -- if
every time Windows crashed, the monitor burst into flames, there'd be
a massive recall.  When it's tires, cars get recalled.  When it's
software, a patch is issued instead.  People have problems wrapping
their minds around virtual objects -- it's hard to imagine something
being "damaged" rather than simply "imperfect."  So buggy code isn't
seen as an actual flaw, just an imperfection in the product.

> It may delay the speed of implementation into the main environment,
> but players will appreciate the resulting stability.  If my memory
> serves, correcting a bug before implementation frequently takes 20
> times less time than fixing it afterwards.

The problem is that there are a multitude of variables that nobody can
predict -- in some cases the bug only happens when Character A does
something bizarre like use fishing at tree, and Character B attacks
the tree -- the game crashes.  No testing is going to figure that in,
because nobody would logically test fishing on a tree (or attacking a
tree, if the tree is, well, just a tree).

I've worked on Six Sigma Quality projects before -- supposedly 90% or
so of defects can be caught in creation of software.  Multiplayer
games are not software.  They are virtual worlds.  To assume that they
are merely software with bugs that can be fixed, is to assume that
players will all play by the rules.  Like life, there is no way to
completely account for the human factor.

This is not to say that we shouldn't test -- there's definitely not
enough testing done in light of the more obvious bugs (gee, you mean
the new guard code protects the thieves rather than stops them?
OOPS!).  But it's not merely a quality implementation issue.

The online game market is driven by the ROI, and it's clear that the
gamer populace has a higher tolerance for bugs and a lower tolerance
for time-to-market.  This is likely a historical measure -- over time,
as the gaming populace experiences more bug-free online games, their
tolerance for buggy code should go down...

and the increase in lawsuits will probably go up.

Mike "Talien" Tresca
RetroMUD Administrator
http://www.retromud.org

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