The laws of probability

coder at ibm.net coder at ibm.net
Fri Jun 6 20:00:40 CEST 1997


As promised.

This is partially written as a speach I'm now not going to give, so
forgive the pompousness.

One thing I've been looking at is causitively controlling probability
within the game.  Thus, at the crude level, a Ring Of Luck could say
make all probability choices come out in the player's favour, or a
Ring Of Bad Luck could make them all come out against him.  It gets
more interesting if you merely warp the probability field instead of
forcing it to 0 or 1 however.  Then you could have a curse of Minorly
Bad Luck, which would just mean that probability choices for that
player would start to fall against him more often.

To do this two things need to be done:

  1) All probability choices have to go thru a central clearing house
where they are "shifted" by the appropriate weight factor, +ve or -ve. 
Without a central clearing house for probability decisions (or at
least a consistant and shared structure), you can't have broad ranging
probability shifts.

  2) The _direction_ of probability values has to be the same.  One
(1) must always be success as defined by "what the player wanted", or
"to the player's advantage", and zero (0) must always be failure.  ie
no negative logic.  Without this pattern a good luck weighting will
force the probability calculations to return sometime return more
successes (ie what you want) and sometimes return more failures (ie
exactly what you don't want).

Next the probability fields need to be split into areas.  It would be
neat for instance to have a device which increases luck during magic,
or another which increases luck during combat, theivery, and such. 
You don't want to have different probability engines for every
different *type* of probability action: for one your programmers would
go bonkers, and you'd not be able to easily have a device which
affected several probability fields at once (eg a ring which increases
luck at magic, but confers very bad luck in combat).

The thing you can't do is to invert the entire probability field.  You
can't have something like, "Wear this ring and all the old certain
things become nearly impossible, and all the old incredibly rare
things become possible".  Follow that far enough and your character is
going to asphyxiate because the probabilities underlieing brownian
motion and the motion of all the air molecules/atoms near him just
accidentally conspired together so that your character is now in a
pure vacuum, only to find that 3 seconds before he expires all the air
has returned to form a small black hole just below his navel. 
Inverted probability fields are things of nightmareish
unpredictability -- literally anything can happen, and more frequently
than what should happen.  

Can't do that.  Even if you could go that far, your players couldn't
and would leave before they arrived.

My solution:

  To make probability calculations a little finer, the actual scale
fills an unsigned 32bit integer.  0 is failure, MAX_UINT is success.

The probability call works on the form:

  ChanceCalc (base_probability, type_list, char_weight_map,
env_weight_maps}

base_probability is a computed value.  This is your normal predictive
calculation; various stats rolled together or whatever.  It is a
deterministic value on the character's chances of doing whatever
presuming that no other external circumstances intervene.  

  eg  If Bubba is attempting to decapitate an Orc with an axe, and he
has enough strength, and the Orc is largely immobile, etc you could
reckon that 75% of the time he'd do it.  75% of MAX_UINT would be the
base_probability.

type_list is a list of the probability fields that will affect this
probability call.    Is magic involved?  Is combat involved?  Is
physical dexterity involved?  Whatever.  The general probability field
has been sub-divided into more specific probability fields, each of
which has been assigned a name.  type_list is a list of the
probability field names which affect the action being attempted.

The weight_maps are lists of pairs, probability field names and
weights,  The char_weight_map is a list of the probability field
weights assigned to that specific character.  The env_weight_map is a
list of probability weights assigned to where ever the character is.

The calculation is: 

  X is a random number from 0 - MAX_UINT.

  Y is the sum of all the char_weight_map entries which match type
entries in type_list.

  Z is the sum of all the env_weight_map entries which match type
entries in type_list.

  if (base_probability + Y + Z < X) then
    return 1
  else
    return 0
  endif

Gotta ring that makes the bearer more successful in sword-play?  Just
have it add an entry to the character's SWORD char_weight_map and
everything else takes care of itself.  Got another ring which makes
the fellow clumsy?  Just add a matching entry.  Got a spell which
makes an area unlucky?  Add an entry to the area's env_weight_map. 
Etc.

Next up, magic structures.
  
--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list