[MUD-Dev] Re: let's call it a spellcraft

Michael.Willey at abnamro.com Michael.Willey at abnamro.com
Fri Sep 25 12:10:53 CEST 1998


     ____________________Reply Separator____________________
     Subject:  [MUD-Dev] Re: let's call it a spellcraft
     Author:   mud-dev at kanga.nu ("Brandon J. Rickman"
     <ashes at pc4.zennet.com>)
     Date:          9/25/98 3:29 AM

---------------------------------
>On Thu, 24 Sep 1998 Michael.Willey at abnamro.com wrote:
>> The "zero, one, and many" axiom applies just as well to
>> game design as to programming concerns.  How many game
>> design problems are the result of "magic numbers" that
>> are far too easy to butt up against?
>
>Is that a design problem, the magic numbers are too
>low?  (Assume that the magic numbers have been correctly
>coded as user configurable constants.)  No, someone
>just needs to raise the numbers, tune the code.
>The older and popular codebases suck because they can't
>be tuned, they are badly designed.

Even with tuning of the magic numbers many systems still
suffer design flaws.  Take for instance the commonly
seen percentile skill system.  Each skill is rated on a
linear scale of 1 to 100, and when an ability is rated
at 100 it can never be higher.  Joe Player can raise
his skills to the same levels as the gods.  He can be
perfect.  Raising the magic number to 200 or even 2000
slows the process down but doesn't eliminate the underlying
problem.

One of the reasons I'm rewriting Dreamshadow's game
system for our new project is because of a rash of players
who through legitimate means have managed to gain skills
at obscene levels.  (Over 200 in a system where advancement
over 100 was intended to be near-impossible.)  They're
butting up against magic numbers embedded in the very
concepts of the system - the quickness of advancement,
assumptions of "reasonable" skill levels and an underlying
assumption that nobody would actually invest that much
time into any one character. We were wrong.

So I'm trying to develop a game system along completely
different assumptions.  Allowing characters to begin
with professional level skills, assuming that players
may spend 8 or more hours a day for years advancing
these abilities, and trying to take the focus away from
the whole "leveling" concept, as starters.

>Even with the "zero, one, and many" rule of thumb, you
>still have to design the numbers with some individual
>care.  How many hit points does the weakest monster get?
>If a fly has 10 hit points, but a pea shooter only does
>1 point of damage, the fly takes 10 hits to kill.  It
>isn't the maximum values (or lack thereof) that are
>important, but the granularity of the "usable" range of
>values.  There may not be a monster weaker than a fly in
>the game, but you are allowed to conceive of such a thing,
>a monster that is a mere fraction of a fly's fortitude.
>But with a 1d1 pea shooter there is no room below, no
>weapon can be worse and still be effective.  This is why
>you start butting up against the too-low magic numbers,
>because the small values aren't, er, small enough.  The
>max limit is still within a "usable" range, it is a high-
>traffic number.

I agree with you, but don't see any simple solutions to
the problem.  The number of units between 0 and Maximum
can be increased forever, but you can't do much to increase
the number of units between 0 and 1.  The best that you
can do is decide carefully what constitutes 1 unit.

That has to be applied to every unit category, too - what
is 1 unit of damage, 1 unit of health, or 1 unit of skill?
How do they interact?

>Anyway, I lose interest in a game if the only goal is
>to max out my skills.  Shouldn't there be fun things to
>do after I have I a buff character?

I agree.  For me, character advancement is a means to an
end, not an end in itself.  I want a world that's fun to
explore and interact with.  I want the game system to be
complex and challenging, but not the only goal of the game.
That's why the DS2 design team's unofficial motto is
"By Spades, For Spades".  That, or "No Cheese". ;)






More information about the mud-dev-archive mailing list