Wizard Recommends Cards

Ask the Wizard Column 125 Addendum

Hi Michael,

In your 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:

  1. Player inserts a coin and begins a spin.
  2. Slot program generates 3 random numbers to determine the position of the wheels.
  3. [wheels spin]
  4. Fill in the viewport with the symbols appearing on the wheels.
  5. Payout matching occurs.
  6. Matched payouts are paid.
  7. 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 0Wheel 1Wheel 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 coordinateviewport 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.