From: caplan@island.COM (Rob Caplan)
Subject: NET.RPG:  Mechanic:  Skill resolution
Organization: Island Graphics Corp.
Date: Wed, 18 Nov 1992 02:57:53 GMT


Ignoring for the moment which dice should be rolled (as Torben
Mogensen pointed out, there is much more to a mechanic than dice) I'd
like to work on how the results of that roll can be interpreted.

The goal is a simple, orthogonal skill resolution mechanic which
provides reasonable results at an arbitrary level of detail.  It
should tell how well the attempt succeeded (or how poorly it failed),
rather than just a binary success/failure result, and it should handle
all skills equally; special cases shouldn't be necessary for chasing,
communicating, fighting, using magic or super powers, etc.

For our input, lets assume a skill value has been generated through
some function of a characters skill level, various situational
modifiers and (possibly) a random element.

The specific function is unimportant, although the range and
distribution of the final number will have a strong effect on our
system (but we can ignore them for now and come back and fill them in
later, once we know how they will be used).

For our output, we want an indication of the level of success.  Two
options are returning an absolute value ("Excellent Success") or
returning number of result points, which can be used to "buy" a
desired outcomes (call the former the "Success Level" system, and the
latter the "Result Point" system).

Success levels have the advantages of simplicity and orthogonality.
The GM assigns a difficulty (which might be incorporated into the
input function as a situational modifier) to the task and converts it
into an label that can be easily applied to any situation.

On the other hand, result points are both more complex and more
flexible.  For each task the GM needs to assign result point costs to
various outcomes (of course, this can reduce to the Success Level
model where X result points buy a Y success).  Result points can also
easily simulate multiple actions (you can buy as many actions as you
get result points for) or extended length actions (you keep adding
result points until you earn enough to succeed).

In either system, we need to convert from the skill value to the
success level/result points.  For simplicity's sake, we'll want to
either stick with easily computed functions (+/- or simple division,
but probably not logs, etc.) or with a table (which allows for more
complex formulae, but requires looking things up).  Likewise, the
skill values should be small to keep the numbers easy to work with.

And, in both cases, we need to decide how to account for the
difficulty of the task.  For a Success Level system, the difficulty
can be added in to the Skill Value as a situational modifier, or it
can be incorporated into the table, effectively using a different
table for each of a discrete level of difficulty.  A Result Point
system can use either of those methods (in which case it is
essentially the same system), it can make more difficult tasks cost
more result points.  The Result Point system can also combine these
systems by including situational modifiers into the Skill Value while
raising the cost for attempting more difficult feats.  Attempting to
shoot somebody in the fog would charge the penalty to the Skill Value,
while attempting to shoot somebody in the leg would raise the result
point cost of the action.  

A Result Point system also has to determine when the points are
declared.  If the player has the option of purchasing several
different effects from a single roll, must the effects be chosen
before the number of result points are available or can it be delayed
until after?  Delaying the decision could result in characters
performing actions they wouldn't normally attempt if they didn't know
they happened to have enough result points to succeed, and an increase
in the number of successful attempts at difficult tasks since people
would tend to do the most difficult task they had the points for, but
no harder.  If the decision must be made early, then characters will
be less likely to get lucky and achieve a spectacular success, since
they will usually attempt to act within their ability.  A third option
would be to give an early general declaration, generate the result
points, and then spend them based upon the general declaration.  A
spectacular success on the declaration "I'm running to the other side
of the room" wouldn't allow swinging across on a chandelier as a
shortcut, but a spectacular success on the declaration "I'm swinging
across the room on the chandelier" might allow smashing into the enemy
at the end of the swing.  IMHO, this third option makes best use of
the advantages of the Result Point system over the Success Level
system.


Example Resolution Tables:
[Assumption:  Skill Value is open ended but usually close to 0]

Skill   Success Level		  Result       Result
Value                             Points(1)    Points(2)
 -8     Disastrous Failure	    -3
 -7				      		-3
 -6
 -5             		      		-2
 -4     Major Failure		    -2
 -3	       			      		-1
 -2     Failure                     -1
 -1	        		        	 0
  0	Near Miss	             0
  1     Marginal Success             1           1
  2	Fair Success		     2
  3				      		 2
  4     Good Success 		     3
  5				           	 3
  6
  7				      		 4
  8     Excellent Success	     4
  9				      		 5
 10
 11				        	 6
 12
 13				        	 7
 14
 15				        	 8
 16	Spectacular Success	     5
  .                                  .           .
  .                                  .           .
  .                                  .           .



With this the Success Level system is done--all that's left is for the
GM to define what a "Good Success" means for the task at hand.  

On the other hand, the Result Point system is about to get somewhat
complex.  The GM still has to assign point costs to various actions.
This requires at least one table, more the more detailed we want to
get.  A success level-like table can be used as a general guideline,
possibly with more specific tables for different types of activity.
Potentially, this could use separate tables for each skill (or even
for separate uses of each skill--people who like highly detailed
combat systems might want a different table for each weapon or combat
style).


Example Result Point table:  Combat
Cost     Action
1        Feint     (Bonus to next attack vs. defender)
1        Maneuver  (Force Defender to move (defender chooses where))
2        Maneuver  (Force Defender to move (attacker chooses where))
2        Stun      (Cause defender to lose action)
2        Wound     (Damage defender)
3        Knockdown (Defender falls down)
4        Disable   (Defender loses use of arm or leg)
4        Disarm    (Defender drops weapon)
5        KO        (Defender knocked out)
8        Kill      (Defender dies)



I like the idea of the Result Point system quite a lot, aside from the
number of special cases (and tables) it requires.  Because of this,
I'm worried that it could bog down during play, although generalizing
it to the Success Level system in most cases should fix that.


What do you all think?


Rob Caplan
caplan@island.com