CRA 322: Craps Variance Simulator Guide

A craps variance simulator is useful only if it models the actual wager, game state, stake changes, and stopping rules. Its purpose is not to discover a winning pattern. It is to show how widely real results can spread around a known mathematical expectation.

A good simulator can answer questions such as: How often might a $500 bankroll survive 500 decisions? What range contains most session results? How large can drawdowns become? How many trials are needed before the estimated average stabilizes?

It cannot tell you what the next shooter will do.

Start with a wager that can be defined exactly

Do not begin with “simulate craps.” That instruction is too vague. Craps contains one-roll wagers, contract bets, place bets, Come bets, free-odds bets, working and not-working rules, and multi-roll states.

A proper specification identifies:

• the wager or combination of wagers;
• the amount on each wager;
• when each bet is placed;
• whether bets are working on the come-out roll;
• the point state;
• odds multiples and table limits;
• presses, regressions, or removals;
• bankroll and stop conditions;
• number of sessions and decisions.

If those rules are wrong, a million simulated rolls produce a precise answer to the wrong question.

Verify the simplest benchmark first

The Pass Line is a useful test because its overall probabilities are known. Across the complete come-out and point cycle, the Pass Line wins with probability 244/495 and loses with probability 251/495.

For a $10 flat wager:

EV = (244/495 × $10) + (251/495 × −$10)
EV = −$70/495
EV ≈ −$0.1414 per resolved wager

The house edge is therefore about 1.414% of the flat amount wagered.

Before trusting a more complicated model, simulate a very large number of $10 Pass Line decisions. The average should approach a loss of roughly $0.1414 per resolved decision. If it does not, inspect the dice generator, point-cycle logic, push rules, and settlement code.

That benchmark is not proof that every session will lose 14 cents per bet. It verifies the long-run center of the distribution.

Rolls, decisions, and sessions are different units

A frequent simulation error is dividing by the wrong denominator.

• A roll is one outcome of two dice.
• A resolved decision is a wager that has reached win or loss.
• A session is a sequence controlled by bankroll, time, or stop rules.
• Total action is the sum of all amounts wagered, including repeated and simultaneous bets.

One Pass Line decision may require one roll or many rolls. A Place 6 may resolve, remain active, be pressed, or be removed. A Come bet may travel to a number while other wagers remain on the layout.

Report results in units that match the question. “Average loss per roll” and “average loss per resolved Pass Line wager” are not interchangeable.

Build the state machine before adding strategy

A realistic craps simulator should track the game as a state machine.

At minimum:

1. Come-out state: no table point is established.
2. Point state: 4, 5, 6, 8, 9, or 10 is active.
3. Wager state: each bet is active, inactive, moved, pressed, paid, pushed, or removed.
4. Bankroll state: available funds after each settlement.
5. Session state: continue or stop under the selected rule.

The official rules determine which dice totals establish a point, win immediately, lose immediately, or leave the wager unresolved. The site’s craps bets guide and true odds versus casino payouts provide the wager-level background needed before coding.

Do not add a betting progression until the flat-bet model reproduces known probabilities and expected values.

What a useful output report contains

A single average hides the feature people care about most: the spread of possible results.

For each scenario, report:

• mean ending profit or loss;
• median result;
• standard deviation;
• 5th, 25th, 75th, and 95th percentiles;
• probability of finishing ahead;
• probability of losing a specified amount;
• probability of bankroll depletion;
• maximum drawdown distribution;
• average total action;
• average number of rolls and resolved decisions.

The mean answers the long-run cost question. Percentiles answer the session-risk question. Bankroll depletion answers whether the proposed stake is practical.

A result such as “average loss $28” is incomplete if the 5th percentile is −$450 and the bankroll is $300.

More trials reduce sampling noise, not game variance

A simulation estimate changes from run to run because it is based on a random sample. Larger samples reduce the standard error of the estimated mean:

Standard error of the mean = session standard deviation ÷ √number of sessions

Suppose the standard deviation of simulated session results is $250.

10,000 sessions:  $250 ÷ √10,000 = $2.50
40,000 sessions:  $250 ÷ √40,000 = $1.25

Quadrupling the number of independent sessions halves the standard error. It does not make individual sessions less volatile.

NIST’s guidance on sample size and estimation error explains why more observations improve precision when estimating a mean.

Use enough trials for the statistic being reported. Rare bankroll-ruin events or extreme percentiles may need far more trials than a rough mean estimate.

Keep the random-number process auditable

Two fair six-sided dice can be modeled by independently generating each die from 1 through 6 and summing them. Do not generate totals 2 through 12 uniformly; those totals do not have equal probability.

There are 36 equally likely ordered dice combinations:

• total 7 has 6 combinations;
• totals 6 and 8 have 5 each;
• totals 5 and 9 have 4 each;
• totals 4 and 10 have 3 each;
• totals 3 and 11 have 2 each;
• totals 2 and 12 have 1 each.

A basic validation table should compare simulated frequencies with these theoretical proportions. Large persistent deviations suggest a coding or sampling problem.

For reproducibility, record the software version, scenario settings, number of trials, and random seed. A fixed seed allows another person to reproduce the same test run. A different seed checks whether the conclusion survives another random sample.

Simulating betting systems without fooling yourself

A progression must be described as an exact rule. “Press when winning” is not enough.

Define:

• starting unit;
• amount of each increase or decrease;
• trigger for a change;
• maximum stake;
• reset rule;
• bankroll constraint;
• table-limit constraint;
• treatment of pushes and unresolved bets;
• session stop rule.

Then compare it with flat betting on the same wager, over the same number of opportunities, using the same starting bankroll.

A progression can change the distribution dramatically. It may produce many small wins and a few large losses, or vice versa. It does not change the expected value of each dollar placed on the underlying negative-expectation wager.

For a fixed house edge h and stakes b₁ ... bₙ:

Expected loss = h × Σbᵢ

The progression changes Σbᵢ, often substantially. It does not turn h negative for the casino.

Common simulation mistakes

Stopping winners but not losers. Comparing sessions that stop at +$100 with sessions that continue until ruin creates an asymmetric experiment.

Ignoring insufficient bankroll. A model should reject a wager the bankroll cannot fund, not allow a negative cash balance unless credit is explicitly part of the scenario.

Treating odds as ordinary house-edge action. Free odds have zero house edge on the odds amount, but they increase volatility and bankroll requirements. Keep flat and odds action separate.

Using too few sessions. A graph can look convincing even when its tail estimates are unstable.

Optimizing on one random sample. Testing hundreds of systems and publishing the luckiest one is data mining, not evidence of an edge.

Changing several rules at once. Compare one change at a time: wager type, stake, odds multiple, session length, or stop rule.

A practical simulator workflow

1. Write the rules in plain language.
2. Derive at least one known expectation by hand.
3. Implement dice and game-state logic.
4. Validate outcome frequencies.
5. Validate flat-bet expected value.
6. Add bankroll and stopping rules.
7. Run many independent sessions.
8. Report the full distribution, not only the mean.
9. Repeat with another seed.
10. Interpret results as risk ranges, not predictions.

The craps odds calculator is useful for checking individual dice probabilities. The general variance simulator helps illustrate how short-run outcomes can remain far from expectation.

A craps simulator is most valuable when it disproves overconfidence. It shows that a low-edge wager can still produce severe short-run losses, that larger odds require a larger bankroll, and that a smooth-looking betting system can hide a damaging tail. Use it to understand uncertainty—not to manufacture certainty.