[MUD-Dev] Re: Systems you use

[J C Lawrence <claw#under,engr.sgi.com>]

On Thu, 23 Apr 1998 13:17:52 +0100 (BST) 
Ling <K.L.Lo-94#student,lboro.ac.uk> wrote:

> Out of interest, what system do people use for their randomness and
> why?  Here's a list of some of the ones I can immediately remember
> with short explanations of how I know they're used.

I have a random number generator which claims to be "non-lumpy"
(picked it out of DDJ some years ago).  

> Linear probability, percentile, 1D100, 1D20: Self-explanatory,
> probably the most popular one.  Often conducted as a 'roll higher to
> succeed'.  Eg: 60% chance of hitting someone, minus their defensive
> modifiers, plus attacking modifiers.  Roll over to achieve.
> Variants include systems using a float those value hovers between 0
> and 1 (simply a finer version) and Palladium games using a 1D20.

I use percentile variants almost exclusively.  Choice of suitable
multiple break points for your criteria can make almost any curve form
-- including the multiple-roll/extreme-peak/trough variations.  Note:
I've found it easier and sufficiently cheap to use the multiple-roll
technique for the very low probability oddities to not bother with
figuring the appropriate percentile marks to get the same curve.

> Strange multiple D6 only: Easier to give examples for this one.

> For Heavy Gear (DP9): character rolls number of D6's equal to their
> skill.  Complete 1's result in a fumble.  Result of the roll is
> equal to the highest die rolled.  In the event of multiple 6's,
> additional 6's contribute a +1 to the roll.  Coz of this, the
> probability curve is *highly* non-linear after 7.  Simple, quick.

Note: I use a *lot* of non-linear curves.  My random function returns
a 64bit unsigned integer.  I then define value ranges for the vcarious
responses, at leat one of which ranges results in a further (possibly
several) number generation(s) for torqued curves.  I could of cour do
the same thing by defining very small sub-ranges for the torques, but
accuracy of probability definition suffers as well as ease of defining 
oddities.

> Combat Resolution Table (CRT): Advocated by Steve Jackson (of SJG
> fame).  Attacking strength and defensive strength are turned into a
> ratio and a single die is rolled to get a list of potential results.
> Eg: Hovercraft Alpha with fires with a strength of 3 at APC Beta
> with defence of 2, ratio is 3:2.  A table might look something like:

I do cascaded effects.  I guess in a way I use a generated table (its
really just an f(x) return), to determine the result of a given
attempted action.  I then use that result to determine what resultant
actions to compute.

> Other: Random numbers are dependent upon stats.  Eg: Strength of 200
> will allow rolls of 1-200 or variation of.

Yup, I use stats (well, probability fields -- see earlier discussion)
to modify and warp the base curves and distributions.

> When it comes down to it, some of the systems listed can emulate the
> others so it is all down to a matter of preference.

This is the real point.  When you get right down to it any probability 
system can be described in terms of any other probability system.  The 
only *real* advantage (other than comutational load) of any system
over another is the mental model it gives the programmer/user.  People 
find some models easier to "think with" and to apply to new situations 
than others.  

-- 
J C Lawrence                               Internet: claw#null,net
(Contractor)                               Internet: coder#ibm,net
---------(*)                     Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

-- 
MUD-Dev: Advancing an unrealised future.