[CoLoCo] dice rolls in C

[Kevin Fries]

On Tue, 2008-02-05 at 16:58 -0500, TheZorch wrote:
> Andrew wrote: 
> Here's a challenge.  Create a program which can do RPG dice rolls.
> RPG dice are your average 6 sided (should be able to specify now how
> many) plus a 20 sided, an 8 sided, two 10 sided for percentages, and a
> 12 sided die.   I can't remember anything I learned of C back in 1995.
> I was programming on Unix at the time and it was ANSI-C not C/C++.

The problem with these types of "simulations" is that they rarely are
able to properly simulate actual dice throws.  All they are able to do
is pick pseudo-random numbers from an algorithm and normalize it between
1 and the number of sides on the dice.  This assumes in a perfect world,
every number has an equal number of chances of coming up, and therefore
should create a situation where every number will come up an even number
of times, given a large enough sampling.

The problem with this exercise is that it is neither random (has to do
with how RPG works at the lowest level) nor accurate.  In a physical
world, the dice throws are never truly random either.  Watch someone
throw a pair of dice say 20 times.  Every time they will pick the dice
up in a particular way, roll them in their hands in a particular way,
and toss them in a particular way.  Each of these ways are as unique as
the player.  Note the numbers that come up.  Then repeat the experiment
with four other players.  Due to the differences in the way each person
will do it, you will find, despite what you would think, certain numbers
will come up more often for certain players.  This is one area where
theory and reality are very different from one another.

Casinos had the same problems with the introduction of card based
gambling machines.  The standard way of "shuffling" a deck was to assume
that if the desk was truly shuffled, each card would have an equal
chance of coming up at any point.  So the standard method was to have an
array of 52 cards and an empty array.  Pick a RPN from 1 to 52 and
remove that card from array 1 and add it to the end of array 2.  What
the casinos found was that the odds of hands actually changed!  Think
about how cards are actually shuffled.  The deck is cut approximately in
half (within 5 to 7 cards of half would be a good estimate) then cards
are transferred from the BOTTOM of each stack 1, 2, 3, maybe even 4 or 5
at a time before the same is done from the other stack.  This causes
cards of the same suit (assuming you are starting from an unshuffled
deck).  This increases the chances of flushes and flush straights
because cards starting from similar places have a better chance of
staying together, than with the truly RPN method.  As a casino, having
higher paying hands come up more often turns a winning machine into a
losing one.

The same problem occurs with dice.

The real trick is how to create a roll mechanism that really does
emulate how people roll dice.  Then apply that physics engine to the
roll of the dice.

Just a thought

-- 
Kevin Fries
Senior Linux Engineer
Computer and Communications Technology, Inc
A Division of Japan Communications Inc.