[MUD-Dev] The laws of probability

[clawrenc at cup.hp.com]

In <199706070616.GAA56998 at out1.ibm.net>, on 06/07/97 
   at 07:25 PM, coder at ibm.net said:

>As promised.
...
>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

You can then add wild-carding to the probability types to allow
simpler matching.

To be even slicker, you can extend the definition of the
char_weight_map and env_weight_map semantics.  Instead of a simple
mapping of a probability type to a weight, make each node a list of
probability types and an associated weight.  Then if the type_list for
a given calculation matches ALL the types listed in a *_weight_map
node, then the weight value for that node is applied.  If only a
partial match or no match, the probability weight it not added.

This allows objects which attempt to mutate multiple probabilities as
a harmonic system.

Next up is to change the weight definitions to be chance values
instead of weights.  Then instead of summing all the weights as above
and comparing them to the random number, do the following:

  X is a random number from 0 - MAX_UINT.

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

  Z is (((MAX_UINT - base_probability) / MAX_UINT) * Y)

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

Now the weights "push" or "pull" the probability towards or from the
absolutes, but never, ever reach them.  The curves have suddenly
becomes asymptotic.  

Similar can also be done by changing Z to not be the sum of the
values, but instead to be the sum of the maximum and minimum values in
the matching sets.  This tends to flatten the curves and makes
significant probability displacement more difficult UNLESS the methods
which add entries to the *_weight_maps instead of just logging a new
entry with a new weight to be thrown into the mix, instead locate an
eixistant matching entry and then update its weight value (ie do
accumulation within the list).

  eg

  char_weight_map contains an entry:  {{MAGIC, COMBAT}, 17}

  The player puts on a necklace which has a {{MAGIC, COMBAT}, -5} 
    and {{DEX}, 9} probability field.  Rather than just adding two 
    new nodes to the char_weight_map, instead it modifies the 
    existant node so that the list becomes:

    {{{MAGIC, COMBAT}, 12}, {{DEX}, 9}}

What this allows is for different probability field algorithms to
decide whether or not to make new entries, or modify existant entries
(ie are they additive or not)?  

Hurm.  

Of course similar could be achieved with the old algorithm) by having
the probability field algorithm make the determination up front
whether to add a new node (additive), or to do nothing because of an
existant node with a similar or greater value.  It does not *quite*
end up at the same thing tho.  Consider:

  char_weight_map is empty.

  Player puts on a ring which adds a single probability 
    field: {{MAGIC, COMBAT}, 17}

  char_weight_map contains a single entry:  {{MAGIC, COMBAT}, 17}

  The player puts on a necklace which has a {{MAGIC, COMBAT}, 5} 
    probability field.  Its not additive, so the list remains 
    unchanged.

  The player now removes the ring, the {{MAGIC, COMBAT}, 17} entry
    is removed, and the char_weight map is now empty.

This adds an interesting twist -- the probability spell fails if it
can't create its entire effect.  You could even add specific failure
case semantics (such as adding other nodes or modifying existant nodes
such as changing that 17 /down/ by 5 to reflect the failed 5
addition).

Just some thoughts.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...