[MUD-Dev] Re: Levels versus Skills, who uses them and when.

Caliban Tiresias Darklock caliban at darklock.com
Mon Jan 4 13:36:48 New Zealand Daylight Time 1999


-----Original Message-----
From: Travis S. Casey <efindel at io.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Monday, January 04, 1999 12:45 PM
Subject: [MUD-Dev] Re: Levels versus Skills, who uses them and when.


>Definitely.  I've long said, "Build the game that *you* would like to
>play."

Or, as in my case, take the best damn game you've ever seen in your life,
and buy the rights. ;)

>Chances are that someone else will like it too, and it's much
>easier than trying to figure out what other people would like.


Here's the thought process I'm intending to use. (Right now, it's a much
simpler process: take what the other guy gave you and make it work.)

Put up a minimal working system. (In my case, were I starting from scratch,
this would mean moving and fighting and little else; as I am not, this means
putting up exactly what I have without additional modifications.) Let people
play with it. Give them an email address to write to.

People being cynical, they will complain. Take the complaints, and make
notes of them. Fix them in the next release. Put the name of the complainer
in the release history: "Bob found a problem, so I fixed it."

People being innovative, they will make suggestions. Take the suggestions,
and if they are good suggestions (or can be made good suggestions -- "I want
an antimatter weapon that pierces all armor" could be met with a corollary
defense that causes antimatter weapons to overload and detonate, which in
turn could be met with a scanner that tells you whether a player has
antimatter defenses), add them in the next release. Put the name of the
suggester in the release history: "Bob had an idea, so I used it."

Over time, if you continue this process, the game will theoretically become
what people want in an organic fashion. This neatly avoids the question of
what to do in the first place; you do something very simple and stripped
down. It avoids the question of what people want; they will tell you. It
avoids the question of how to reward those who find bugs or create features;
you credit them. (Attention is the currency of the future, after all.) In
the end, you have a game that people like to play, and which keeps getting
better.

However, you can't fix every "problem" (it is too easy to get killed), and
you can't add every "feature" (I don't like paying taxes). Some such things
can be fixed by making them configurable; you could make taxes a
configuration variable, so if you set it to 0 then no one pays taxes. Some
things can't be fixed; if you keep getting killed, maybe you just really
suck at this game. And, of course, this assumes that you have tight control
over the distribution and internal operation of the server, which may not be
the case. (It's sort of imperative to this particular project, at the
moment.) It also assumes you have designed a reasonably extensible framework
underneath everything in the first place.

Note also that your particular server concept may not lend itself well to
"minimal" design. ;)

| 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