By Marty Wollner






I have a definition of LIVE BETTING:


The wager is booked BEFORE the occurrence of a physical event that determines the outcome. The event MUST BE FAIRLY DISTRIBUTED, resulting from equally probable outcomes. The use of electronics may be used to control the timing of the conveyance of the results of the event, but never for generating it. The use of electronics to record a live event upon which subsequent wagering could occur (such as dog race slot machines) is NOT considered LIVE BETTING by this definition.




SnapRoll is an invention to provide the best of both worlds… live gaming AND chip less wagering.


The idea for this started out in a WizardOfVegas forum thread titled:


Fair Games?


The poster asked:


Thank you, Michael and all of the Administrators, for your amazing sites and for all of your time! Also, I appreciate the input from "most" others - if not informative, it's usually entertaining!

My questions today are regarding the fairness of live games in various jurisdictions. While there has been much discussion regarding the fairness of video poker and video keno of all varieties, I do not recall nor could I find any discussion in this respect regarding the live games.

Are there regulations regarding the fairness of the dice, decks, etc., that are used on the tables in Nevada, Louisiana, or any other state?

Are most of you table game players out there confident that you are rolling fair dice and/or being dealt from a fair deck without any "slight of hand" by the dealer (or the shuffler)? Please include the state(s) and/or casino(s) in which you play (or avoid) table games.

My apologies if this has already been discussed or divulged - I did attempt to search for any similar topic. Thank you all for your time!





I’m a big advocate of LIVE gaming, so I chimed in:


To answer your question, if its done right, the house has no need to cheat... why rock the boat when you already got a good thing going? It's better for a casino to keep a clean reputation that get away with scamming it's own customers here and there.

If you're paranoid about it, then, that's the whole thing about live gaming! The house had BETTER keep the game fair for its own protection.

I don't understand how anyone can trust anything that results from an electronic Random Number Generator (RNG).

Did you know that there is no such thing as "Random"... it is impossible to actually program it, so they do their best by simulating random in the software.
Nearly all modern slot machines work this way. I bet there's a lot of players who, if they knew this ...


that slot machine reels are NOT random number generators any more, they're DIGITAL DISPLAY UNITS, slowly spinning down to a combination that was already programmatically selected before they started spinning,


... they wouldn't play any more.

The best of both worlds is to start with a LIVE event, such as a dice roll, and then let people book their bets against the outcome, but do it using electronic systems that ensure safety and they also ensure that any odds calculations performed are "FAIR" as well. They can't cheat in that part of the electronics (the pay-out mechanism), or if they did, it would be real easy to catch and prove, (see above).

What is needed is a way to plug LIVE GAMMING into slot machines and other forms of entertainment.



MathEx replied:


No slot player wants to see 10 dice rolling every time they spin the reels, and no casino will accept the slowdown and mechanical fragility of such a system. Slot games have been operated by RNG-controlled stepper motors since the 1980s...



I then went through the following paragraphs, which outline how the SnapRoll invention works:



A LIVE craps table has random timing as to when the thrower shoots, and a LIVE roulette table is the same. In both cases, if these were being used in a game of SuffleMaster RapidCraps or RapidRoulette, the system knows about 2 seconds before the roll/spin is completed that it will occur. There is a 2 second time-window of knowing a randomization event will definitely occur in real-time (I know there might be a few failures, like dice thrown off the table).


Next, lets get 1,000 separate craps/roulette tables all being monitored at the same time (all in REAL-TIME) by a centralized system. The odds are very good that overall, a STEADY FLOW LIVE RANDOMIZATIONS can be obtained. It will all be real; it will all be real live randomization events, each one occurs wherein the wager is made BEFORE the fact, not after, like video dog-racing.

The SNAP_ROLL is just another randomization input device to a RollStation just like a live roulette table, or a live roulette table spin being mapped into a dice randomization input, or an actual RNG, OR NOW IT CAN ALSO BE A SNAP_ROLL:

As the stream of live randomization events arrive, they individually SNAP into each of the reel positions and a set of live video feeds displays this as SNAPSHOTS of these events as they occur in REAL-TIME, one reel after the next.

The player, instead of seeing a set of video dice sprayed out for each number, he sees live video-feeds of events all over the world in REAL-TIME, making up his randomization inputs.

IT WILL BE AS FAST AS SLOT MACHINE REELS, EASILY and true live gaming, yet safe and secure. The best of both worlds. I believe I now hold the patent that makes this possible, THANKS TO YOU, MATH EXPERT!!




MathEx then replied with:


You should calculate the bit rate of your proposed RNG because you're off by many orders of magnitude. How many slot machines do you think you could hook up to 1000 craps tables and support the non-stop game-play players have come to expect? Here's a hint: the answer has two digits.






MathEx questioned the capacity and capability of this device. I was able to test the validity of the system because I already have the system in place. Note that, as usual, MathEx IS CORRECT in his preliminary guestimates.


I wrote a few windows command procedures that call some old interface programs that send coded messages into my Alarm Notification System. Without any code or database configuration changes, the system is now capable of accepting any number of live rolls from anywhere on the network; each live roll is sent, unsolicited, from its source as a set of two messages:


The first is a “New Roll” message, specifying:


-The source node id

-The source port id

-The time of submission (localized at source)

-A “New Roll” identifier consisting of “/System_ID = SNAP /ALARM_ID = 1”

-A string of information detailing the profile of live media feeds available from the source, for example, live video, live audio, live snapshot streams, etc…

   |Video_1=VidChan3009 |Audio_1=A1Chan9003|SnapStream_1=PhotoCast0039|

-A “SUBSCRIPTION TAG STRING” used to identify the roll that will be submitted (in step 2 of the process):

   |SubscribeTo = RollerID_7_1_7|





The second step in the process is submitting a “RollFinished” message, specifying:


-The source node id

-The source port id

-The time of submission (localized at source)

-A “RollFinished” identifier consisting of:

 /System_ID = SNAP
 /Alarm_ID = 2
 /Alarm_Sub_ID = RollerID_12_Roll_23332


-The results of the roll:

|COMPLETING|SnapRoll test from node = 2 |ROLL = RollWAS_7




My alarming system is really fast. It reduces latency to milliseconds even across the network because of the way it’s designed; it accepts these unsolicited messages and (nearly instantly), it queues, processes, and re-distributes the data wherever it’s needed.


I ran a series of 50 and 100 instances of this Roller program concurrently. I staggered the startups every group of 5 by a different prime number of seconds (to simulate randomization between Rollers):


Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 3

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 7

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 11

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 13

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 17


Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 2

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 6

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 10

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 12

Start_Test1_DDR_SnapRoll_1.bat 0 6 54 5 16



In a continuous loop, each of these:


  1. Sends the NewRoll message
  2. Waits 6 seconds
  3. Sends the FinishedRoll message
  4. Waits for 54 seconds


My alarming software has monitors that show how many of these Rollers are in the 6-second waiting period:



Monitored at 7-second intervals, here are the numbers of available live randomizations concurrently available:




50 rollers, 6 second NO-MORE-BETS lockdown, then 54-second pause:

4 4 2 2 1 1 12 10 4 4 4 3 2 3 1 2 2 13 9 11 6 4 3 3 2 1 2 1 10 15 10 11 4 5


100 rollers, 6 second NO-MORE-BETS lockdown, then 54-second pause:

5 3 6 16 17 12 8 4 4 5 13 21 18 9 8 5 3 17 20 19 10 7 3 4 4 18 19 15 10 4 5 3 10 21 16 9


50 rollers, 5 second NO-MORE-BETS lockdown, then 55-second pause:

2 1 11 5 3 5 2 1 1 2 10 7 2 4 1 2 1 0 7 10 3 3 2 2 0 6 6 9 4 4 2 2 1 11 7 7 5


100 rollers, 5 second NO-MORE-BETS lockdown, then 55-second pause:

13 14 8 5 2 3 2 16 10 13 9 3 3 3 2 15 11 10 9 4 4 3 4 17 13 7 7 3 3 4 12 18 16 6 7 3



30-Second CYCLES:


50 rollers, 6 second NO-MORE-BETS lockdown, then 24-second pause:

20 12 9 18 13 11 8 20 11 6 20 11 7 8 14 9 6 19 10 5 12 12 11 5 22 12 9 18 13 10 6


100 rollers, 6 second NO-MORE-BETS lockdown, then 24-second pause:

20 23 21 27 20 20 26 20 23 22 29 23 19 28 21 24 21 23 25 19 25 20 19 23 21 26 20 26


50 rollers, 5 second NO-MORE-BETS lockdown, then 25-second pause:

2 7 9 4 3 2 2 1 11 8 8 4 2 1 2 1 12 8 6 4 2 2 1 12 5 4 3 2 1 1 1 12 7 3 3 1 2


100 rollers, 5 second NO-MORE-BETS lockdown, then 25-second pause:

21 21 20 16 21 20 23 15 21 20 12 17 23 19 13 18 21 15 14 16 15 13 21 23 20 13 17





These tests were done using fixed periodic cycling, however, there is some latency. Beyond that, each of the rollers were started up in staggered time offsets and the system was allowed to stabilize by waiting for at least 11 complete rolls from every roller before sampling.


I am certain that an additional amount of randomization may need to be introduced to make this a fair study, however, this is a simulation of a collection of live games; if the pool of available rollers suddenly ran low (perhaps a few tossed the dice off the table at the same time), I think it would be a cool boost for the game because it would promote the COMMON GAMING EXPERIENCE even more.


I’d like to hear a common groan among the crowd when stuff like that happens, it gives a common focus and creates a common goal for everyone to accomplish.


This ties back into one of MathEx’s concerns, that being enough numbers to go around.


-         How many craps shooters do I claim are needed for an entire casino to enjoy a live game? One.


-         OK, if so, then, how many RNDs do we need for one casino’s slot machines? One.



AND NOT ONLY THAT, IT’S A LIVE randomizer, and players make the bets BEFORE the dice are thrown, and they get to see the dice fly, live, on the screen in REAL TIME, and anticipate the bounces just as well as the dude who threw em!!!


Is MathEx possibly worried that people will settle in and figure out the publicly displayed, fixed-for-life mappings, and all bet one way or another?


Why else is he worried that the number of SnapRolls will be in double digits? Why isn’t just one set of live rolls enough for every wager in the world (in various forms) to bet upon?






THINK ABOUT THIS… this is what I keep calling the “shared gaming experience”, its a fundamental theme to my patent, specifically mentioned in both of em.


Back to being worried about the players ganging up on the poor casino like a stock market ambushing an I.P.O.?





The casinos can MAP and distribute these numbers to these machines any way they see fit, and do it for hidden advantages:


They could group all of a winning mapping in one area of the casino, and group the opposite mapping on the other side. As craps players, for example, win or loose, these positive vs. negative results could be shared among all of the games in these segregated clusters. They could group the roulette Reds together with the craps “wrong” players at the same time.


One side of the casino now has a common goal and a common enemy… little “regional clicks” can now be developed… what used to be segregations by game type can now be a building – wide segregation of right/wrong craps players joined by respective armies of red/black spin-freaks with a few field-player and 0-00-green outcasts here and there just to spice things up.


Everyone in one area is either all ecstatic or they all wanna tear the place apart, well, not really, but actually, sort of… But I chalk this up as positive passion… this is the sort of camaraderie that men go to fight wars over!


Can you imagine the roar when things get heated up?



Still Worried?



Is the casino worried about distributing these numbers so players can take advantage?


They could “checkerboard the arrangement into 4 quads: right/red, right/black, wrong/red, wrong/black. Think about THIS now… for the first time EVER, the house can legally, ELIMINATE ALL GAMING RISK AND CONTROL BALANCE OF PAYOUTS AMONG THE ENTIRE OPERATION!



I can start to think of a dozen ways they could make it awesome, here is just one:



PurplePeopleEaters vs. GreenZombies:



Purple: Win on every roll of a 12, Loose on every roll of a 2


Green: Win on every roll of a 2, Loose on ever roll of a 12



Each “SIDE” can also have a side-bet Tower-of-Power counting 2’s vs 12’s and the winners might get to blast the losers with cold air or something nutty and funny like that.



The possibilities are endless, and, it’s all at a huge reduction in costs to everyone involved, and it SAFE!



The best of both worlds.