Wie RNGs und Gewinnmechanik getestet werden
Die Integrität des Slots beruht auf zwei Säulen: einem hochwertigen RNG (Random Number Generator) und einer korrekten Gewinnmechanik, die Zufallszahlen ohne Offset in Ergebnisse abbildet. Das Testen ist nicht ein einziger Test „für Glück“, sondern ein ganzes System: kryptographische Resistenz des RNG, statistische Prüfungen, Monte-Carlo-RTP/Volatilitätssimulationen, deterministische Sitze für Reproduzierbarkeit, Audit-Protokolle und Zertifizierung in unabhängigen Labors. Unten ist ein komplettes, praktisches Förderband.
1) RNG-Architektur: Woraus „Zufall“ besteht
Entropiequellen: OS (CSPRNG/'/dev/urandom', CryptGenRandom), Hardware-TRNGs (sofern verfügbar), Systemgeräusche.
Algorithmus: Server-basiertes CSPRNG (z. B. CTR_DRBG/HMAC_DRBG) oder hochwertiges PRNG (PCG/Xoshiro) mit Thread-Unabhängigkeitskontrolle.
Saatgutpolitik (Seed): Primärseed aus CSPRNG, separate Streams pro Session/Spiel/Fitu, Schutz vor Wiederverwendung, sichere Lagerung (HSM/Secure Storage).
Server → Client: das Ergebnis wird auf dem Server berechnet, Client - nur Visualisierung; irgendwelche „Präludien“ (Near-Miss/Teaser) haben keinen Einfluss auf das Ergebnis.
Unabhängigkeit der Spins: keine automatische Anpassung an die Balance; das Fehlen von „Glücksstreifen“.
Kontrollfrage: In welchem Stadium wird das Ergebnis akzeptiert? Antwort: vor der Wiedergabe der Animation, mit Fixierung auf das unveränderliche Log.
2) RNG-Mapping → Ergebnis (keine Verschiebung)
Der richtige Sweep von Zufallszahlen in den Gewichten von Zeichen/Zellen ist der Schlüssel zum Fehlen von „modular“ und anderen Verschiebungen.
Einheitliche Stichproben: Wenn Sie eine Zahl aus dem Bereich'[0, N) 'benötigen, verwenden Sie Rejection Sampling und nicht' rand ()% N', um Bias bei'2 ^ k% N ≠ 0 'auszuschließen.
Gewichtete Stichproben: Kumulative Verteilungen (CDF) oder der Alias-Algorithmus (Vose) für schnelle Stichproben nach Gewichten.
Mehrfachziehen: Ein separater RNG-Aufruf pro Trommel/Zelle/Ereignis, nicht das „Streuen“ einer Zahl auf das gesamte Feld.
Garantien auf Code-Ebene: eigenschaftsbasierte Invariantentests („Summe der Frequenzen ≈ Gewichte“, „kein Segment unterrepräsentiert“).
3) Was genau wir überprüfen: Ziele und Metriken
RTP (Return to Player) - durchschnittliche Rendite,%- Volatilität/Varianz - Streuung der Ergebnisse
- Hit Rate - die Häufigkeit jedes Gewinns
- Bonus Frequency - Häufigkeit des Eintritts in den Bonus
- Max Exposure - theoretisches Maximum (x von der Wette)
- Stationarität - keine Zeitverschiebungen/Freigaben
4) Statistische RNG-Tests (Off-Line-Battery)
Verwenden Sie „Butterys“ für lange Sequenzen (10⁸+ Bits/Werte), getrennt für jeden RNG-Stream:- Momente und Korrelationen: Monobittest (Anteil 0/1), Autokorrelation (lag k), Serien- und Paarkorrelationen.
- Тесты NIST SP 800-22: frequency, block frequency, runs, longest run, FFT, approximate entropy.
- TestU01/Dieharder: zusätzliche „Stresstests“ (birthday spacings, matrix rank, random excursions).
- KS/ χ ² durch Eimer: Vergleich der empirischen und theoretischen Gleichmäßigkeit auf'[0,1) 'und auf Zielbereichen.
- Poker-Tests (für Gruppen von Bits) und „Gap-Tests“.
Akzeptanzkriterien: p-Werte im zulässigen Intervall (nicht „zu perfekt“), keine systematischen Ausfälle bei festen LED-Werten, stabile Ergebnisse auf verschiedenen Plattformen/Compilern.
5) Kartierungsstatistik (spielspezifisch)
Selbst ein perfekter RNG kann durch falsches Mupping ruiniert werden. Wir überprüfen genau die Verteilung der Ergebnisse:- Symbol-/Maschenfrequenzen: χ ² auf Übereinstimmung mit Gewichten (nach Walzen/Clustern/Münzen).
- Kombinationen/Linien: Binomialintervalle für Gewinnkombinationen; Vergleich mit Referenztabellen.
- Bonus-Trigger/Retrigger: Intervalle zwischen Ereignissen (geometrisch/negativ binomial) + KS/AD-Tests.
- Unabhängigkeit der Trommeln: Kreuzkorrelationen zwischen den Positionen (wir schließen das „Zusammenkleben“ aus).
6) Monte Carlo Simulation RTP/Volatilität/Frequenzen
Reproduzierbare Simulationen sind der Kern des QA der Mathematik.
1. Einstellung: Wir erfassen die Version der Mathematik, Sids, Gewichte/Strings/Auszahlungstabelle.
2. Lauf: ≥10⁷ - 10⁸ Spins für die Stabilität der Schwänze; separat - lange Bonussitzungen.
3. Schätzungen und Intervalle:- RTP-Schätzung: (\hat {RTP} =\bar {X}), wobei (X) der Gewinn in xBet ist.
- Konfidenzintervall (CLT): (\hat {RTP }\pm z_{\alpha/2}\cdot s/\sqrt {n}).
- Erforderliche Stichprobe: (n\approx (z\cdot s/\varepsilon) ^ 2) für den Fehler (\varepsilon).
- Für Hit Rate/Bonus Rate - binomiale (Wilson) Intervalle.
- 4. Schwänze: p95/p99/p99. 9 Gewinne pro Spin und Bonus; Kontrolle „max exposure“.
- 5. Stabilität: Empfindlichkeit gegenüber ± δ Änderungen der Gewichte ("robustness runs').
7) Determiniertheit und Reproduzierbarkeit
Deterministische Sids für QA: Der gleiche Sid → die gleichen Ergebnisse (Golden-Run).
Identische Ergebnisse auf Plattformen: Compiler/Bibliothek Versionsfix, Endianness-Check, FPU-Modi.
Save-Stays: Wiederherstellung des unterbrochenen Bonus/Spin ohne „Umdrehen“ des Ergebnisses.
Replay-Infrastruktur: Ausführen eines „problematischen“ Seed + Step-Tickets zur Analyse.
8) Sicherheit und Anti-Tamper
WORM-Protokolle (oder Merkli-Hash-Ketten): Aufzeichnung des Ergebnisses und der Eingabeparameter vor der Animation.
Signaturen von Bildern und Math-Listen: Version der Auszahlungs-/Gewichtstabellen - im Manifest mit Unterschrift.
Kunden-Integritätskontrolle: Verschleierung, Hash-Überprüfung, Anti-Instrumentierung.
Server-authoritative: nur der Server entscheidet über das Ergebnis; Der Client enthält keine „versteckten“ Prüfungen.
9) Belastungs- und Langzeittests
Soak-Tests: Hunderte Millionen Spins mit Sid-Rotation; Kontrolle von Speicher-/Ressourcenlecks.
Hohe Konkurrenz: parallele Sitzungen von RNG-Streams → keine Rennen/Lock-Inhalte.
Netzwerkdegradation: Wiederholte Abfragen/Timeouts ändern das Spin-Ergebnis nicht.
10) Validierung von UX-Invarianten (Interface Integrity)
Near-miss: Animationen ändern die Wahrscheinlichkeit nicht; Verbot des „Manipulierens“ von Haltestellen für das Drama.
Spin-Geschwindigkeit: Beschleunigung/Turbo hat keinen Einfluss auf den RNG.
Training/Demo-Modi: entweder ehrlich oder markiert und Mathematik getrennt.
11) Überwachung nach Freigabe (Statuskontrolle in der Produktion)
SPC-Karten/Kontrollpläne: RTP nach Zeitfenster/Casino/Geo - in zulässigen Korridoren.
Driftdetektion: PSI/JS-Divergenz der Gewinn-/Frequenzverteilungen.
Alarme: Abweichungen → Blockierung des Spiels/Marktes, Rekalkulation von Protokollen, Bericht.
12) Zertifizierung und Dokumentation
Bereiten Sie das Paket für das Labor vor (GLI/eCOGRA/BMM/iTech usw.):- RNG-Beschreibung: Algorithmus, Entropiequellen, Erntepolitik, Flussunabhängigkeit.
- Quellen/Binaries des RNG-Moduls (oder Inspektionsartefakte) + Testprotokolle.
- Mathe-Blatt: Auszahlungstabellen, Gewichte, RTP-Breakdown (Basis/Bonus/Jackpot), max Belichtung.
- Simulationsberichte: Volumen, Metriken, Konfidenzintervalle.
- Logs/Replays: Format, Signaturen, Retention-Richtlinie.
- Versionierung: Unveränderliche Hashes von Artefakten (Bild, Assets, Mathe).
13) Häufige Fehler und wie man sie vermeidet
'rand ()% N' und modularer Offset. Verwenden Sie rejection/alias.
Ein RNG für alles ohne Threads. Machen Sie unabhängige Streams, vermeiden Sie versteckte Korrelationen.
Kartierung „nach schönen Indizes“. Überprüfen Sie immer die Frequenzen mit Gewichten χ ²-Tests.
Kleine Simulationen. 10⁶ ist ein „Rauchcheck“, Schwänze brauchen 10⁸.
Mangel an deterministischen Sitzen. Ohne sie können Fehler nicht reproduziert werden.
Der Kunde entscheidet über das Ergebnis. Nur Server, nur WORM-Protokolle.
Keine Nachüberwachung. Die Veröffentlichung ist nicht das Ende, sondern der Beginn der statistischen Kontrolle.
14) Formeln und Mini-Spickzettel
χ ² auf Gleichmäßigkeit (k Eimer):[
\chi^2=\sum_{i=1}^k \frac{(O_i-E_i)^2}{E_i},\quad E_i=n/k
]
Vergleichen mit (\chi ^ 2 _ {k-1}).
KS für kontinuierliche Verteilung:[
D=\sup_x F_n(x)-F(x)
]
RTP-Konfidenzintervall (CLT):
[
\hat{\mu}\pm z_{\alpha/2}\frac{s}{\sqrt{n}}
]
Wilson für den Anteil p (Hit/Bonusrate):
[
\frac{p+\frac{z^2}{2n}\pm z\sqrt{\frac{p(1-p)}{n}+\frac{z^2}{4n^2}}}{1+\frac{z^2}{n}}
]
15) Checklisten
Techdesign RNG
- Quelle CSPRNG/TRNG; dokumentierte Seed-/Stream-Richtlinie
- Unabhängige Streams, kein Shared-State-Rennen
- Rejection/alias statt „%“
- Server-authoritative; Ergebnisfix vor Animation
- WORM-Protokolle, Artefakt-Signaturen
Statistiken und Simulationen
- Battery NIST/TestU01/Dieharder - bestanden
- χ ²/KS/early - auf Mapping-Ergebnisse
- ≥10⁷ - 10⁸ Spins CI nach RTP/Frequenzen in Toleranzen
- Schwänze p95/p99/p99. 9 und max exposure unter Kontrolle
- Robustness-Läufe bei ± δ zur Waage
QS/Engineering
- Deterministische Sitze; Ticket-Replikationen
- Soak/Last; Speicher-/CPU/Latenzstabilität
- Zusammenfassung des Spin/Bonus ohne Änderung des Ergebnisses
- Plattformübergreifende Identität der Ergebnisse
Compliance/Dokumente
- RNG-Spezifikation + Quellen/Artefakte
- Math Sheet + Simulationsberichte
- Protokollierungs-/Retentions-/Audit-Richtlinien
- Versionierung und Hashes von Bildern/Auszahlungstabellen
Das Testen von RNGs und Gewinnmechaniken ist Statistik- und Sicherheitstechnik. Sie schützen die Spieler und die Marke, wenn:
1. RNG Racks und richtig gesät, 2. Kartierung der Ergebnisse ohne Offset und reproduzierbar, 3. RTP/Frequenzen/Schwänze werden durch große Simulationen bestätigt, 4. das Ergebnis wird aufgezeichnet und vor der Animation auditiert, 5. Post-Release-Monitoring fängt jeden Drift.
So bleibt der Slot ehrlich, vorhersehbar (im statistischen Sinne) und manipulationssicher - und Sie werden zertifiziert und bauen langfristiges Vertrauen auf.