[MUD-Dev] Chances of success (was d20 system)

Travis Casey efindel at earthlink.net
Thu Aug 16 15:10:10 CEST 2001


Thursday, August 16, 2001, 8:35:05 AM,
Daniel.Harman at barclayscapital.com wrote:
> From: Travis Casey [mailto:efindel at earthlink.net]
>> On Wednesday 15 August 2001 05:42 pm, Bobby Martin wrote:

>>> For example, in Cosm we decided we want the chance of success on
>>> a skill to be proportional to the ratio (skill level)/(skill
>>> level + difficulty).  This way an increasing skill increases the
>>> chance of success, but there is never either a certainty of
>>> success or certainty of failure.
 
>> Yep.  I suggested exactly that on this list a few years ago.
>> See:

>>   http://www.kanga.nu/archives/MUD-Dev-L/1997Q4/msg00045.php
 
>> Shawn Halpenny replied back then that he was already using a
>> similar system.

> So have any problems come to light with this system after 3 years
> usage?

You'd have to ask Shawn, since he was the one using it... I'm not
sure if he's even still on the list.

> I like it although I'm not completely convinced as to how easy it
> would be for a person with 50 skill to beat someone with 100
> skill.

Like anything else, it depends on circumstances.  In a "fair fight",
the person with 50 skill almost certainly won't win.  But how often
do PCs stoop to fighting fair?  :-) If the person with 100 skill has
a dagger, no armor, and has just been in another fight, and the
person with 50 skill has plate armor, a longsword, and is fresh,
things aren't nearly so clear about who will win.

Also, since nothing else is specified about the system by what was
given, there's all sorts of questions.  What's the maximum damage
that a weapon can do?  The average damage?

> Especially if the fight is longish which would start to correct
> any statistical abberation.  For me marginally long fights are a
> necessity as quick fights are more likely to preclude tactics and
> make healing spells etc. of negligable use in combat.

> I do have one issue with the system proposed in the linked post
> however, and that is with having the arbitrary hit point cap of
> 120.

It's in how you define "hit points".  The D&D-style definition
includes not just how much damage you can take, but also your
ability to *avoid* damage.  That's why a D&D character's armor class
doesn't generally get better with higher levels -- the increased hit
points reflect improved defensive ability.

In a system such as my paper RPG (and in Jon's system that he was
mentioning), hit points include *only* your physical ability to take
damage, and do *not* include your ability to avoid damage.  That
sort of thing would be covered by dodge skill, weapon skills, and
other things.

To put it in more detail: the traditional D&D rationalization for
hit points increasing with levels is that the majority of the
increase represents skill, luck, divine favor, and other such
things, not just an increase in the physical ability to take damage.
If Grargk the Orc hits a fighter with 10 hit points, and does 14 hit
points of damage, then Gragrk has managed to stab that fighter
through the chest, slash their throat, or hit them in some other way
such that they're out of the fight and will die soon.  If, however,
Grargk hits a fighter who has 40 hit points with that blow, while
the blow has not changed, the fighter managed to dodge in such a way
that it still hurts, but the injury isn't serious -- a cut on the
shoulder instead of slashing the throat, side cut open instead of
the blow going through the chest, etc.

The problem with how D&D does things, though, is that it's not
specified how much of hit points is what.  Knowing how to dodge an
incoming blow doesn't help you if you fall in a lava pit.  If a
fighter under a D&D-style system is blindfolded, or has his/her legs
tied together with a short rope, they won't be as able to dodge.  If
a character violates his/her faith, their divine favor should
decrease.  And so on.  Thus, the D&D "lump it all into hit points"
approach makes the common case simple, but it makes the unusual
cases very hard to adjudicate.

The approach that many other systems use is that hit points are just
your ability to take damage.  Your ability to dodge, luck, divine
favor, and other such things are broken out and handled separately.
This makes the common case more complicated, but makes it much
easier to handle the unusual cases.

In a paper RPG, one major thing to think about in deciding which
sort of system to use is how often you expect the "unusual cases" to
come up.  In a computer RPG, there's less worry about the system
being complicated under "normal use".

> I've not thought about it too much, but it seems to me that by
> putting a limit in you are setting yourself up for difficulty in
> the future.

All you're really saying, under this sort of system, is that there's
a limit to how much vital tissue destruction a human being can take
and live.  Now, how much vital tissue a particular attack actually
destroys is another story -- just as in D&D, a high-skill fighter
may get a slash to the side instead of being run through.  The
difference is that this is reflected by either having the attack do
less damage, or by having fewer attacks do damage, rather than by
giving the character more hit points.

> This goes against my instincts though in that I think continual
> character improvement is key to this type of game.

This allows for continual improvement, though -- you can improve
skills continually.  Indeed, character improvement in skill-based
systems tends to happen more often than in level-based systems,
since small increases in ability are more likely to be visible.

> Of course better armor will factor into the original hp limited
> equation too I guess.  Balancing these multidimensional curves is
> truly a nightmare. Just because computers allow you to make
> complex systems doesn't make us any better at concieving and
> understanding the full ramifications of our design decisions ;)

It's more difficulty, but I'd hardly call it a nightmare.  Pencil &
paper RPGers have been managing to successfully create and use more
complex systems than the typical mud game system for more than
twenty years now.  Of course, it's possible to go too complicated --
but I think there's a lot of room between a D&D-style system and one
that's too complicated to be usable/understandable.

> Another thing I've been thinking off is how to efficiently model
> dmg curves for a weapon if I don't want to stick with a linear
> probability or standard bell curve. I think it would be nice to
> literally drag points on a graph.  You could then have weapons
> with a mean dmg of 20 but a potential dmg of 200 every 1 in 200
> blows. In fact if you had weapons that had negative points on the
> graph, they could even dmg the user at times (well its a dangerous
> weapon /shrug - hell I've smacked myself with a pair of nun-chucks
> :).

In my old paper system, damage worked this: the difference between
how well you attacked and how well your opponent defended was your
success level.  The amount of damage done was the weapon's damage
level (which, for muscle-powered weapons, also depended on the
user's strength) times the success level, with a success level of 0
(barely hit) counting as 1/2.  With this setup, it was possible in
rare instances for an unskilled attacker to seriously hurt, or even
kill, a skilled opponent with one blow.  Of course, the chances of
that happening got higher if there were circumstances against the
skilled opponent, or if the unskilled character's player decided to
spend luck points on the blow.

I've seen some people use a system where there's a random roll for
damage, and extra is added on for good hits.  And, of course,
there's always the traditional-style "critical hit" systems, which
can allow weapons to sometimes do large amounts of damage.  (And
fumble systems, which can allow weapons to sometimes hurt their
wielders.)

--
Travis Casey
efindel at earthlink.net

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list