[MUD-Dev] Re: Thoughts

Hal Black hal at moos.ml.org
Wed Jan 20 02:02:20 New Zealand Daylight Time 1999


On Wed, Jan 13, 1999 at 04:32:16PM -0800, Caliban Tiresias Darklock wrote:
> I'd be lying if I pretended getting something into Koster's laws isn't one
> of my primary motivations in many of my posts on this list. Raph's list of
> laws lies firmly in an area that I've always given a lot of thought to, but
> I *still* don't have anything in there, which really bothers me. That said,
> I'll fire off my current candidates and then go hide from the flying
> tomatoes and cabbages. ;)
> 
> The code is the contract:
> Any usable ability or object is a promise. If your game has a "haggling"
> skill, there is obviously someplace you can haggle. If there is a hammer you
> can carry, there must be a nail you can drive. If you do not deliver a place
> to haggle and a nail to drive, you have broken your contract with the
> player. Even if you only do this once, word will spread.

And if you have a hammer that can drive builder A's 4-inch nail, it should
also be able to drive builder B's 3.5-inch nail.  But then we're getting back
to the global vs. specific verbs argument.

I agree with it as a guideline for mud design, but I don't see it fitting
as a "Law" per-se on the canonical Koster list.  Those seem to be involved with
some sort of behavior given a condition, where this is more of a design
guideline - but a good one!

> The power of two:
> Twice is always. If a player observes an effect twice, he will expect to see
> it every time. If he doesn't, he will think something is wrong. If you
> assure him that nothing is wrong, he will think *you* are wrong.

I'll argue against this one.  I believe there is something from psychology
that says something different.  There was an earlier thread by JCL on effects
as rewards and motivating factors for players.  Take the situation where
some action produces a reward as an effect only some of the time rather than
all the time, we have a case of partial reinforcement verses total
reinforcement.  For some reason, psychology tests tell us that partial
reinforcement is a better training tool than total reinforcement!  So, not only
do people not find fault with somewhat inconsistent results, they are more
likely to try it more often given that it works some of the time!

> How benchmarks are built:
> When no measure of quality is readily provided, a measure of quality will be
> invented by a player who performs well under that measure. It will be
> supported by others who perform well under it. If there are enough of those
> people, the rest of the playerbase will conclude that this is the "correct"
> measure of a player's skill. This becomes the de facto object of your game,
> and you will be blamed for its every ill while those who created it will
> take all the credit for its successes.

This certainly is true of the computer industry. 8')

> It's the thought that counts:
> Stupid restrictions are okay if the player discovers them himself, but not
> if you tell him they exist. In Squaresoft's "Parasite Eve", a dead body
> blocks your passage down a forest path. You could, of course, simply step
> over the body were this real life. Upon determining the restriction's
> existence, the player accepts it. Reporting it to another player who has not
> yet observed the restriction, however, meets with indignance and outrage at
> such an unacceptable breach of realism. (This is specifically of interest to
> commercial game authors, since it implies that *telling* potential players
> you don't support something is a Bad Thing, whereas just plain not
> supporting it would probably be fine. Also consider the reactions of your
> public to proposed features; telling someone you're going to give them
> something is very different from actually giving it to them.)

I think a lot of this has to do with the fact that players start to feel
some sense of ownership in the game they're playing.  Perhaps they've put
a lot of time into building their character's stats or roleplaying
personality.  Perhaps they've carefully weaved their own domain into the
game world.  So here's my attempt to hijack 2 minutes of your fame:  Players
and Builders who feel a sense of ownership are more apt to accept shortcomings
(in simulation or otherwise) in a game than those with no sense of ownership.
  8')

Otherwise, seems like a nice list of laws.  I always like to hear the
anecdotes that people tell that taught them some of their lessons in game
design.  Do you have any to share that spawned your list of laws?

Here's another attempt at a law I'll throw in:
  The more responsive an admin is to user feedback of a given type, the more
the admin will get.  Specifically, as an admin implements features from user
suggestions, more ideas for features will be submitted.  Likewise, as an
admin coddles whining players, more whining ensues.




More information about the MUD-Dev mailing list