[MUD-Dev] Real Life Consequences

[John Buehler]

Jeff Freeman writes:

> 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.

Tell that to Microsoft and the legions that are upset with their buggy
code.  High bug rates do impact end user perceptions about a company's
future software offerings.  Of course, if everyone is producing crap,
you can continue to get away with it.  Until somebody decides to build
quality product.  Then you're hosed, and you find yourself scrambling
to come up with a way to produce low-bug products.  Which ain't easy,
especially if you've been hacking your products into existence.

Right now, the economics of software favor crappy software.  With
growing dependence on software in our society, software reliability
must improve.  Consumers will demand it.  Probably through litigation.

>> 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.

Jeff, both issues are practical. If my bug rate is 1 per KLOC, and
yours is 0.1 per KLOC, who has to have the larger support staff?  Who
will probably have happier players?

> 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.

Speedy implementation today means 'hack' because that's the fastest
way we have to build products.  Usually, we build them from scratch.
I raved about component approaches before and I'll mention them again.
In a well-understood field where any sort of stability has developed,
components should be created so as to retain the investment that a
company has made in software.  When software is being reused, it will
be debugged and stay debugged.  Rapid development will take place to
create *new* areas of functionality that players have never
experienced before.  They appreciate that.

Software companies hire people because they have created the same
pieces of software over and over again, which is blatantly ludicrous
from an industry standpoint.  "Bob is our graphics guy.  He built the
graphics systems for games A, B, and C."  Bob's reuse of code probably
took the form of copying his graphics code from game A and
fitting/hacking it into the environment of game B, etc.

>> 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...

Jeff, give the man a break.  He's saying that fixing a bug before it
reaches those 100,000 players is a heck of a lot better than
afterwards.  You're agreeing with him, but giving him a hard time as
well.

>> 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.

And cynicism does?  Goodwill and cooperation scale nicely, thank you.
Guess where this free, moderated, mailing list that you're a member of
came from?  Or those free MUDs that people are playing?

>> 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.

So we should *introduce* bugs so that everyone understands up front
that the environment is going to be buggy, that players can expect
bugs at a certain guaranteed rate, and the support system can be
structured far in advance?

And as for getting rid of all bugs, the day will come when software
does exactly what the specifications call for.  Then it will just be
an issue of getting the specifications the way we want them.

JB

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