[MUD-Dev] Balance of Character Power

Travis Casey efindel at polaris.net
Sun Oct 5 15:47:03 CEST 1997


[Just getting around to answering some old messages -- our Internet
connection
at work has been slow this last week, and I've been upgrading our two
computers
at home]

Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:
>
>Presenting a balanced(?) system:
>
>Characters, NPCs and Critters have a species/race maximum of hit
>points.  Bear with me on the abstract notion of total hit points for
>a moment.  They might be split locationally (limb-based) or
>subdivided into damage categories (concussion/blood points).
>A human character starts the game with the average racial hit points
>of 60.  The maximum that can be attained is around 120.  This is
>"maxing out" is achieved through premier body conditioning and
>highest stats (constitution/stamina perhaps).

[cuts made to appease the bandwidth gods]

A very good system.  My home-brewed paper RPG uses a similar system --
"hit points" are the multiple of a being's Health and Size attributes.
Thus, large creatures can take more damage than small ones, and
characters can only increase their "hit points" by increasing their
size (which has its own drawbacks) or by increasing their health.  I've
been using this system for about seven years now, and it's worked very
well for me.

I don't have a hit location system, since I haven't come up with one
that's both fast enough and takes into account enough variables.  If I
convert this system over to mud use, though, I'll almost certainly add
one, since speed will be much easier to achieve.

>Now on to armor and equipment.  There are 20 fixed armor types, in a
>modern or SF game these may be extended due to different levels of
>technology.  I won't address these yet, since I'm currently only
>concerned with ancient/medieval types of armor.  These armor
>types range from unarmed to fully plate armored head to toe.

Small note:  the "head to toe" bit implies that these 20 types also
include where the armor covers as part of the variation.  If you're
using a hit point system with locations, though, it seems to me that
it would make more sense to have fewer armor types and allow "mixing"
different types of armor on different locations.

[more cut]

>These are of course the system extremes, yet they show BALANCE even
>at the extremes of min/maxing development.  This is I think a key
>point in combat balance.  Give David a chance against Goliath no
>matter what the odds.  I don't see David EVER defeating Goliath in a
>vanilla DIKU mud nor do I see it happening in basic D&ngntD rpg.  I
>remember calculating the odds for a 1st level vs. 20th level warriors
>and it was around 1 in 15000 for the 1st level to win.  D&singD and
>Diku being battles of hit point attrition rather than amazing one
>time lucky shots.

Of course, this is an intentional design feature of D&D.  Whether the
original DIKU mud designers also intended it, or just didn't think about
it when they based their system on D&D, I don't know.

I thought of a system a while back which has the characteristic of always
giving the lower-skilled character a chance.  Here's how it works:

  A character's chance of success is determined by the ratio between
  his/her skill and the difficulty of the task, the formula being

    skill/(skill + difficulty) = chance of success

  (Note that both skill and difficulty are numbers >= 0)

  Thus, if Theresa has a score of 20 in lockpicking and is trying
  to pick a difficulty 50 lock, she has a 20/(20 + 50) = 20/70 =
  roughly 0.29 probability of success.  Hanse, with a score of
  136 in lockpicking, has a 136/(136 + 50) = 136/186 = 0.73
  probability of success.

  The difficulty may be dependant on another character's skill.  Thus,
  if Hanse has a 75 in shortsword and Theresa has a 45 dodge, Hanse has
  a 0.625 chance to hit Theresa.

  A character's skill score should be partially "innate" -- that is,
  even an untrained character shouldn't have a 0 score in any skill.

  Notes:

  1.  Unless a difficulty is 0, the character never has a 100% chance
      of success.  On the other end of things, given the accuracy to
      which most computers will calculate fractions, there will almost
      never be a 0% chance of success.

  2.  Builders and coders can easily get a feel for probabilities of
      success.

  3.  Absolute skill doesn't normally matter in competitions -- only
      relative skill does.  Thus, a character with a 60 is twice as
      good as a character with a 30, and a character with a 120 is
      twice as good as someone with a 60 -- and a 120's chance of success
      against a 60 is the same as the 60's chance of success against a
      30.

  4.  Changes in skill at the high end mainly benefit the character when
      fighting other high-skill characters.  For example, a move from
      80 to 100 skill only increases your chance of success from 0.80 to
      0.83 against a 20 skill, but increases it from 0.47 to 0.53 against
      a 90 skill.

>My theory in a nutshell:
>Balance and realism are anathema to a Solo/HacknSlash style game.
>Solo/HacknSlash games will eventually approach Monty Haul (imbalance)
>as players "win" the game and implementors must implement new
>challenges to hold "winning" players interest.  The designer has two
>choices, make the power curve 'slow and long' or 'fast and short'.
>Or better yet implement a totally different type of game.  One that
>can't be "won".

Combat balance and realism are definitely anathema to a Hack'n'Slash
game -- if combat were realistic, someone who engaged in combat with
lethal weapons that long generally wouldn't survive very long.  A
Hack'n'Slash game will be imbalanced between high and low level
characters in terms of combat -- it doesn't need to be "Monty Haul"
in the original sense of the term, however (that is, having a game
which has no real danger and huge rewards for the characters).

Balance, however, is often an overrated concept.  It doesn't truly matter
whether PCs are balanced against each other, unless competition between
PCs is a major part of your game.  In a traditional mud setup, where PCs
don't normally compete with each other, what matters is the balance between
the PCs and the tasks they take on.  In a hack'n'slash style game, this
means
giving high-level PCs tasks to take on that are still challenging to them --
which, as Jon notes, means that the implementors will need to make new
challenges as characters become more powerful.  This isn't necessarily a
problem, as long as the implementors realize that they need to do this from
the start and are willing to do this (or recruit others to do it).

Something that does need to be avoided is the scenario where high-level
characters can go into lower-level areas and be able to advance rapidly
without significant risk to themselves.  A number of ways have been tried
to avoid this -- in a Hack'n'Slash game, you might want to not award
characters any experience for defeating monsters that are more than a
few levels below them.  You may also need to reduce other rewards, such
as monetary awards.  This might be possible through "realistic" effects --
for example, if you can hit the orc hard enough to kill it in just three
blows even with its armor, chances are that the orc's armor won't still be
in saleable condition afterwards.

Of course, I'd still prefer to implement a different kind of game, but
Hack'n'Slash games *can* work -- they just need a bit more thought than
has normally been put into them.  :-)
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html





More information about the mud-dev-archive mailing list