[MUD-Dev] How much is enough?

Talies the Wanderer snicker at pinkpig.com
Thu Apr 25 10:12:58 New Zealand Standard Time 2002

"Justin Coleman" <JMCOLE at main.djj.state.sc.us> wrote:

> My opinion, possibly ill-informed, is that a system like this
> would be less susceptible to being "gamed" by those people
> obsessed with being numerically "the best" at any given
> system. The lack of exact feedback would make it harder, if not
> impossible to determine which of two similar items was best - say
> you have two swords, but one of them does one percent more damage
> than the other one. In most current systems, you can see the
> numbers plain as day, and you instantly know which one is better,
> encouraging comparison and min-maxing.

I've seen a number of different attempts at "inexactness" - but each
one is invariably defeated by the players as they work out the
numbers on their own.  Of course, if a programmer *really* wanted to
hide those numbers, it actually wouldn't be that hard.  Take this
"standard" number-to-phrase conversion chart for the "severity" of a
wound (apologies for the mangled code - I cut up some ROM-based code
my roommate works on for this:)

  if (dam == 0)        { vs = "miss";       vp = "misses";          }
  else if (dam <=   4) { vs = "scratch";    vp = "scratches";       }
  else if (dam <=   8) { vs = "graze";      vp = "grazes";          }
  else if (dam <=  12) { vs = "hit";        vp = "hits";            }


Now, add a little "randomness" to it.  rhit is a random number from 1 to 3, 
generated for each separate attack.

  if (dam == 0) 
    { vs = "miss"; vp = "misses";              }
  else if ( dam <=   4 ) and ( rhit  = 1 ) 
    { vs = "scratch";  vp = "scratches";       }
  else if ( dam <=   4 ) 
    { vs = "graze";    vp = "grazes";          }
  else if ( dam <=   8 ) and ( rhit  = 1 ) 
    { vs = "scratch";  vp = "scratches";       }
  else if ( dam <=   8 ) and ( rhit  = 2 ) 
    { vs = "graze";    vp = "grazes";          }
  else if ( dam <=   8 ) and ( rhit  = 3 ) 
    { vs = "hit";      vp = "hits";            }
  else if ( dam <=   12 ) and ( rhit  = 1 ) 
    { vs = "graze";    vp = "grazes";          }
  else if ( dam <=   12 ) and ( rhit  = 2 ) 
    { vs = "hit";      vp = "hits";            }
  else if ( dam <=   12 ) and ( rhit  = 3 ) 
    { vs = "injure";   vp = "injures";         }

This would present an invisible factor that the player would never
see, thus making it nearly impossible, except perhaps over the
course of killing hundreds of goblins, to determine the exact
variables in play.  It's probably over-thinking, but if you really
wanted to keep 'em guessing, this would be the way to go.  (FYI, I
am not a programmer - I just make it up as I go along.)

Sean Middleditch <elanthis at awesomeplay.com> wrote:

> For example, in my MUD, there are no classes or levels - just
> skills. However, I'm working on a psuedo-class system.  In it,
> classes are defined by skills, and the importance of the skills.
> (I.e., a fighter has high importance for combat skill, small
> importance for riding skill, no importance for cooking skill.)
> Then, the skills of a player are added and averaged and weighted
> according to those psuedo-class definitions, and a "level" is
> determined for each class.  The best class for that player (or
> maybe best 3 - I haven't determined yet) is used as the class for
> the player.  So, when the players' skills have reached a high
> enough level to "level up" in their class, they'd get the reward,
> perhaps a higher title ("You are now a Journeyman Wizard!") and so
> on.

Wow - that's very similar to Dungeon Siege's method.  Anyone can BE
any class, but it gets respectively more difficult to be a jack of
all trades vs being a single-class.  There are 4 basic skills that
contribute to probably a dozen different classes: Melee (Fighters),
Archery (Bowyers), Combat Magic (Mages), and Nature Magic (Druids).
Combine two, like Bowyer and Nature Magic, and you get Ranger.  It's
rather nicely done, I thought.

> The problem with things like Health and such is that numbers are
> needed.  You need to see how much damage you can take, how much
> you/monsters are dishing out in damage, and so on.  You can
> replace that with a percentage, but that gets annoying.  You are
> still showing the players numbers (i.e., the goblin causes 5%
> health damage), but now, when the players health gets larger, they
> lose indication of how much damage they can take.  For example, a
> giant used to cause 60% damage. Now that the player is much
> stronger, can he handle the giant?  All he'll know is that the
> giant will cause less damage, but not how much - and it may be
> deadly trying to find out.  That would be annoying.  it's one of
> those realism vs. fun things.

I don't know - it seems to work pretty well in DragonRealms.  The
wound system there is very realistic, from bruises to broken bones
to severed limbs - and despite the lack of any "instant heal" in the
game, players manage combat rather well.

> To fix the maximizing of weapons/armor, you need to pull out as
> much of the numbers from the items asyou can, and put them in the
> system.  When a character has used a longsword his whole life,
> then finds a magical shortsword, that longsword may continue to be
> better for him, because he is very usnkilled with the shortsword.
> It ceases to be which item is more powerful, but which item the
> character would favor.

Let me preface this with the comment that I actually enjoy a
well-drawn skill-web with unfamiliar weapon penalties and exclusive
weapon bonuses.  That being said, weapon specialization needlessly
complicates the system.  When properly done, it provides a slight
added sense of realism, and allows the player to "customize" his
choice of weaponry, giving the appearance of "excellent" skills for
a minimum of effort.  Improperly implemented, however, you end up
with min/maxing worse than you can imagine.  For those who played
the brown-book series of AD&D, check out "Elven Bladesinger" in the
book of Elves for an example of truly hideous min/maxing with
weapons specializations.  I had a player in a tabletop game who
insisted on that character, and much to my eternal regret, I allowed
it.  Lesson learned.  Players will ALWAYS find a way to min/max, and
the more complex the system the more likely they are to find an

Talies the Wanderer

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list