[MUD-Dev] Thoughts

Caliban Tiresias Darklock caliban at darklock.com
Wed Jan 13 16:32:16 New Zealand Daylight Time 1999


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.

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.

Code Never Dies:
Whenever you put a feature into the server, it is virtually impossible for
that feature to come back out. It does not matter how old or obsolete or
broken or buggy it becomes. It may be repaired, even replaced, but never
removed. It follows logically that no feature should ever enter the game
without careful and thorough consideration.

The law of ill repute:
Negative commentary is both more common and more persistent than the
positive variety. While word will spread when you have something really cool
in the game, many players will hoard such information as valuable. Word will
spread much faster when something has gone wrong, because no one values the
information; it is cast aside as soon as possible, and at every opportunity
thereafter, in the apparent hope that the player will eventually be rid of
it.

The theory of player relativity:
No statistic has meaning without comparison. Unless you know where the other
players are, where you happen to be is completely irrelevant. This is true e
ven in games where there is no score or statistic, because when you do not
provide a way of measuring performance, the public will invent one
externally.

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.

Peek-a-boo:
If the player cannot see it, it does not exist. If you do not display a
level, then your game has no levels. If you do not expose a system, there is
no such system. If no secret item has been found, there are no secret items.
If no score is displayed, the game has no score.

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

| Caliban Tiresias Darklock            caliban at darklock.com
| Darklock Communications          http://www.darklock.com/
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=-






More information about the MUD-Dev mailing list