[MUD-Dev] Re: DGN: Why give the players all the numbers?

David Hunt david.w.hunt at comcast.net
Tue Sep 16 15:13:55 CEST 2003


From: "Rayzam" <rayzam at travellingbard.com>

> In fact, you can do both. What we do on Retromud is to give
> descriptive scales for many stats [though not player stats]. Then
> we have helps that list all the descriptions in order. Players can
> then rank them, assign numbers to them, use any sort of math they
> want. But when it first hits them, it is in descriptive words.

A better alternative is to provide both with a means for the player
to choose. While descriptive scales alone are useful for immersion,
they hide the underlying game mechanics. It has been pointed out
repeatedly that players will eventually reverse engineer at least a
reasonable approximation of the game. Why not put that energy to
better use comparing your intended design to observable results?
Players will find and report subtle problems faster and more
reliably than peer review or quality assurance. As long as you are
willing to commit resources to fixing these subtle problems in a
timely manner, players will appreciate your openness and dedication
to making the game better.

Obfuscation is only advantageous when you have something to
hide. Either you don't have the development resources to track down
and fix problems the players point out, or you are trying to
maintain the illusion of the infallible admin. The longer you can
hide the problems, the longer you have to fix them. In the end, this
approach tends to cause resentment because even if you do fix the
problem in a reasonable time frame, the players still have to spend
substantial effort validating your fix.

I'm going to go further and argue that the development process for
fixes should be very open as well. Players should know in reasonable
detail what is going to be done and when it is expected to be
implemented. They should be able to monitor the progress of
particular problems. When players can see that something is being
done, they are far more reasonable and much less likely to take
their money elsewhere. It doesn't require much in the way of
additional resources provided you have a reasonably functional
defect tracking system. I can't imagine a large software project
doesn't already have one, so it simply becomes a matter of making it
available to your customers.

Regards,

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



More information about the mud-dev-archive mailing list