Following is an e-mail I received regarding the question on how slot machines go from the symbols on the payline to what the player wins, as asked in the December 13, 2004 column.
Hi Michael,
In December 13, 2004 column there was a question about how payouts are
determined, and you gave a fair answer. However, it doesn't address
the question of how payouts would be handled in a non-mechanical
machine, and I'd wager that mechanical and non-mechanical machines are
handled the same way internally these days. I can give an answer
based on an implementation I've done of a system which allows the
specification of arbitrary slot machines. I can't say if this is how
it's done by IGT, though I'd be surprised if it was substantially
different than this.
This will probably be quite lengthy, so if you want to forward it on
to the original question poser, that would be fine; or, if you want to
put it on your website, that's fine too. Or, if you want more detail
for putting it on your website, I'd be happy to flesh this out more.
For simplification, I'll ignore the slightly complicating factor of
virtual wheels; but it's not because the are overly complicated, it's
because it makes the discussion even more lengthy.
First, a little terminology:
symbols : The pretty pictures which appear on the wheels
For the machine in question, we have a set of symbols:
{ Red Seven, White Seven, Blue Seven,
Red Bars, White Bars, Blue Bars,
Blanks }
I will abbreviate these as:
{ R7, W7, B7, RB, WB, BB, B }
viewport: The viewable section of the slot machine.
In the case of the Red/White/Blue machine mentioned, if it is
the machine I think it is, the viewport is three (3) rows and
three (3) columns. This will be noted as a viewport of size
[3, 3].
Here's what the viewport looks like; the coordinates are shown
in each position:
Wheel 0 Wheel 1 Wheel 2
Row 0 [0, 0] [1, 0] [2, 0]
Row 1 [0, 1] [1, 1] [2, 1]
Row 2 [0, 2] [1, 2] [2, 2]
payline: The coordinates in the viewport for winning symbol matches.
For the machine in question, we'll assume there is only one
payline, the middle row of the viewport.
We can represent this as a set of [x, y] coordinates:
{[0, 1], [1, 1], [2, 1]} <- middle row of [3, 3] viewport
payout : The number of coins returned for a winning combination.
Payouts are frequently based on the number of coins played. In
this case, we'll assume only one coin can be played, and thus
there is only one payout for each winning combination of
symbols.
So, let's say the payout for {R7, W7, B7} is 500 coins when 1
coin is played; in this case you'd have a payout of:
{ 1, 500, [R7, W7, B7] }
The first item is the number of coins played, the second is the
number coins to be paid out, and the third is the symbols which
yield that payout.
wheel position: The wheel stop number of the top line of the
viewport.
The original query indicated that the winning stops for [R7,
W7, B7] on the physical wheels were [8, 8, 8]. We'll consider
that stop number 7 is immediately prior to stop number 8. We'll
also consider that stop 9 immediately follows stop 8 on the
physical wheels.
Recalling the viewport show above, here's how the viewport
would look for a winning combination of [R7, W7, B7]:
Wheel 0 Wheel 1 Wheel 2
Row 0 stop 7/?? stop 7/?? stop 7/??
Row 1 stop 8/R7 stop 8/W7 stop 8/B7
Row 2 stop 9/?? stop 9/?? stop 9/??
Ok, now we've got the foundation for seeing how a winning combination
can be determined on-the fly, based on the symbols on the wheels, the
wheel positions, the paylines and the payouts.
Remember that all the slot machines today are computers -- even though
they are mechanical, internally they are just computers running a
program, so we can imagine how the program might work:
- Player inserts a coin and begins a spin.
- Slot program generates 3 random numbers to determine the position of
the wheels.
- [wheels spin]
- Fill in the viewport with the symbols appearing on the wheels.
- Payout matching occurs.
- Matched payouts are paid.
- Lather. Rinse. Repeat.
Step 5 is the seemingly tricky part which is the crux of the original
question. But, remember that we've got paylines, and payouts and the
contents of the viewport to help us out. With these tools, it's
really easy to determine winning combinations.
Considering our example, we have the following:
viewport: Wheel 0 Wheel 1 Wheel 2
Row 0 stop 7/?? stop 7/?? stop 7/??
Row 1 stop 8/R7 stop 8/W7 stop 8/B7
Row 2 stop 9/?? stop 9/?? stop 9/??
Payline : {[0, 1], [1, 1], [2, 1]}
Payout : { 1, 500, [R7, W7, B7] }
The slot program will obtain the symbols from the payline coordinates
in the viewport:
payline coordinate viewport data
{[0, 1], [1, 1], [2, 1]} == [8/R7, 8/W7, 8/B7]
And then it will compare them with the symbols associated with the
payout:
viewport data payout information
[8/R7, 8/W7, 8/B7] == { 1, 500, [R7, W7, B7] } ?
If there is a match, the payout value is awarded, if not, it waits for
the player to insert another coin.
The key to all this magic is a table of payline coordinates and a
table of payouts -- each wheel spin is matched on-the-fly for winners.
And, this is all *very*, *very* fast.
Using my slot specification system, I've implemented the Wizard of
Odds Fruit Slot as a proof of concept, and as a sanity check to make sure the actual
payout value (produced by my system) is correct over large numbers of
simulations.
I can simulate 10 million spins of the wheels in about 10-12 seconds
(3.2GHz Dell Inspiron 9100).
That's 833,333 slot spins per second, far faster than you could ever
possibly hope to push the SPIN button!
If the original questioner, or anyone else, wants more information,
they can contact me directly at ***, but please
don't put my email on your website. - T.H.
