In brief
Simulation creates the available outcome stories. Optimization assigns their selection weights. Validation checks that the files, payouts and reported distribution agree. Treat these as separate stages so you can tell which one failed.
- Debug a small book before generating a large one.
- Recalculate statistics from the final exported weights.
- Treat validation warnings as work to resolve, not decorative console output.
Start small enough to inspect every event
In the pinned lines run script, simulation counts, thread counts, compression and run conditions are explicit. For a first debug run, edit the corresponding assignments in your copied game:
num_threads = 1
rust_threads = 1
batching_size = 100
compression = False
num_sim_args = {"base": 100, "bonus": 100}
run_conditions = {
"run_sims": True,
"run_optimization": False,
"run_analysis": False,
"run_format_checks": False,
}
These settings deliberately create debug output. They are not release settings. In particular, compressed-file verification is disabled because this pass is for reading uncompressed events; restore compression and all required release checks later.
From the math repository root on Windows, run the example with env\Scripts\python.exe games/0_0_lines/run.py, substituting your copied game folder when applicable. A small outcome count does not guarantee every rare event appears. Construct explicit fixtures or forced cases for those events.
Read one complete round
Choose a round ID, inspect its board and follow its ordered events to the final payout. Confirm the frontend can replay that same sequence. Then examine zero payout, bonus entry, retrigger and cap cases individually. Catching an incorrect event here is cheaper than finding it after a large compressed export.
The math quick start distinguishes debugging from large simulation runs and recommends substantial per-mode diversity for production. Its 100k-plus guidance is a starting point for discussion, not proof of coverage or approval. Your mechanics and weighted distribution determine what additional evidence is needed.
Optimize a distribution, not a headline number
The sample optimization setup separates outcome criteria and contributes RTP through different buckets. When changing the game, review those constraints alongside the actual rules. Updating only rtp in the main configuration does not automatically make every optimization condition consistent.
Ask three questions after optimization: Does the weighted RTP match the intended mode? Which payout bands contribute most of it? Has an unreasonable amount of weight concentrated on a few repeated outcomes? A technically balanced average can still hide an undesirable distribution or a visibly repetitive book.
For every mode, retain a report containing cost, RTP, non-zero payout probability, above-cost payout probability, maximum payout, maximum-payout probability, outcome count and payout-band contributions. Add event-specific frequencies where relevant. Define each metric rather than relying on ambiguous labels such as “high volatility.”
Independently calculate the small fixture
This standalone Python example checks the arithmetic from part 4 using exact fractions. It does not need the SDK:
from fractions import Fraction
rows = [(70, 0), (20, 50), (10, 850)]
total_weight = sum(weight for weight, payout100 in rows)
mode_cost = Fraction(1)
rtp = sum(Fraction(w * p, 100) for w, p in rows)
rtp = rtp / total_weight / mode_cost
hit = Fraction(sum(w for w, p in rows if p > 0), total_weight)
assert rtp == Fraction(95, 100)
assert hit == Fraction(30, 100)
print(f"RTP {float(rtp):.2%}; non-zero payout {float(hit):.2%}")
Expected output: RTP 95.00%; non-zero payout 30.00%. Extend the independent calculation to your real lookup table, using sufficiently large integer types for weights. Do not sample only a handful of browser spins and call that a mathematical validation.
Release validation and warnings
Generate the final compressed books, optimized lookup tables and index together. The pinned RGS verification utility checks payout matching, integer constraints and additional distribution properties. It includes checks labelled as three-star volatility limits. Those are versioned implementation checks, not a substitute for the current team-specific review requirements.
Some conditions produce warnings. A process exiting successfully therefore does not prove that every suitability check passed. Read the report and make unresolved warnings fail your own release gate. Do not suppress them to obtain a green dashboard.
Keep the exact book, lookup table, configuration and reports from one build. Reusing an old table with a new book can produce a package whose filenames look correct while its data disagrees.
Finish this part
Save a debug replay, a final weighted report and the validation output for each mode. Document every unresolved warning. Proceed to frontend polish only when the exported result and the independent arithmetic tell the same story.