Skip to the content.

ゲームプランナーが知っておくべき乱数の話


はじめに:「本当のランダム」はゲームに向かない

「ランダム」と聞けば、誰でも「予測不可能な出来事」を思い浮かべる。しかしゲーム開発において、本当に予測不可能な「真の乱数」を使うことはほとんどない。理由はシンプルだ——真の乱数は再現できず、デバッグもテストも成立しないからである。[1][2]

実際のゲームで使われるのは「疑似乱数(Pseudo-Random Number Generator / PRNG)」だ。これは数学的な計算で生成される「乱数っぽい数列」であり、同じ初期値(シード)を与えれば必ず同じ結果が再現される。プランナーとエンジニアが共通認識を持つべき「乱数」とは、この疑似乱数のことを指す。[3][1]

さらに重要なのは、「数学的に正しい乱数」と「プレイヤーが自然に感じる乱数」は別物 であるという点だ。この認識を持っているかどうかで、ゲーム体験の品質が大きく変わる。[4]


疑似乱数の仕組みと3つの主要アルゴリズム

疑似乱数は「シード値(初期値)→計算アルゴリズム→乱数列」という流れで生成される。シードが同じなら出てくる数列は常に一致する。これは一見「欠点」に見えるが、ゲーム開発ではむしろ デバッグ再現やリプレイ機能の実現 に使える「強み」でもある。[2][1]

同じシードから同じ乱数列が生成され、デバッグ再現とリプレイに活用できることを示す図

以下は、ゲーム開発で使われる3つの代表的なアルゴリズムの比較だ。

主要アルゴリズム比較

アルゴリズム 特徴 周期 速度 主な用途
線形合同法 (LCG) 歴史が古く実装が簡単。C言語の rand() に多く使われる 短い(32bit以下) 非常に速い 軽量な乱数が必要な場面、古いゲーム
メルセンヌ・ツイスタ (MT) 周期が (2^{19937}-1) と極めて長く、統計的品質が高い 圧倒的に長い やや遅い Python標準の random、スタンドアロンRPGなど
Xorshift系 (xoroshiro128++ など) XORとビットシフトのみで動作、最速クラス。品質も良好 (2^{128}-1) 最速 ゲームループ内の頻繁な乱数生成、ブラウザ

[5][6][7][3]

線形合同法の落とし穴

特に注意が必要なのが 線形合同法 だ。C言語の標準 rand() の多くはこれを使っており、下位ビット(最も小さい桁)が0と1を交互に繰り返す という性質がある(特に法(モジュラス)が2のべき乗の実装で顕著に現れる)。[8][2]

つまり「偶数か奇数か」を下位1ビットで判定するコードを書いた場合、偶数→奇数→偶数→奇数……と完全に交互になってしまう。これが後述するカルドセプト・サーガ事件の根本原因だ。[9][8]

線形合同法の最下位ビットが0と1を交互に繰り返し、偶奇も固定で交互になることを示す図


疑似乱数の「品質」をどう評価するか

プランナーがエンジニアと話す際、乱数の「品質」をどの軸で見るかを知っておくと会話がスムーズになる。[3]

近年のゲーム開発では PCG(Permuted Congruential Generator) が選択肢として注目されつつあり、周期重視なら メルセンヌ・ツイスタ、速度重視なら xoroshiro128++ が定番の候補となる。[3]


失敗事例①:カルドセプト・サーガ(2006年)

事件の概要

2006年11月22日、Xbox 360向けに発売されたボードゲーム『カルドセプト・サーガ』(バンダイナムコゲームス)は、熱狂的なファンを持つシリーズ最新作として発売直前に「ゴールド殿堂ソフト」の認定も受けていた。しかし発売後、プレイヤーたちが「ダイスの出目がおかしい」と気づく。[10][8]

何が起きたか

検証の結果、ダイスの出目が「偶数→奇数→偶数→奇数」と交互に繰り返す という致命的な欠陥が発覚した。[10][8]

原因は前述の通り、内部の乱数生成が 線形合同法の最下位ビットをそのまま利用していた ためと推定されている(メーカーは原因の詳細を公式には明言していないが、観測された挙動から広く推定されている)。この実装では下位1ビットが必ず0と1を繰り返すため、偶奇が交互固定になってしまう。[8][9]

カルドセプトはボードゲームであり、ダイスの出目がそのまますごろくの移動マス数に直結する。偶数ダイス面を持つセプター(プレイヤーキャラ)が常に有利・不利という、非常にゲームバランスを損ねる状況になった。[8]

対応の経緯と影響

プランナーへの教訓

この事件で得られる教訓は大きく3つある。

  1. 「とりあえず rand() 使っておこう」は危険:C言語標準の rand() は線形合同法実装が多く、下位ビットに致命的な偏りが生じることがある。エンジニアに「どのアルゴリズムを使っているか」を確認する習慣をつけること[2]
  2. ダイスやサイコロの「偶奇」は乱数の下位ビットに直結する:「1〜6を返してほしい」という仕様で、内部が下位ビット依存なら偶奇交互になる。プランナーも結果のビット構造を意識すべき
  3. 早期検証の重要性:発売から3週間も認識されなかったのは、内部テストで検出されなかったことを意味する。乱数の品質テストは仕様確認の対象に含めるべきだ

失敗事例②:XCOM シリーズの「99%ミス問題」

XCOM(Firaxis Games)は戦略タクティカルゲームで、命中率が画面に表示される仕様だ。しかし「95%表示なのに3回連続ミスした」「99%なのに外れた」という不満がプレイヤーから絶えない。[11][12]

実際には 確率論的には正しい。99%でも100回に1回は外れる。しかし人間の感覚では「99%は当たって当然」と捉えるため、1回のミスが「バグかチート」のように感じられる。[13][11]

99%命中でも100回に1回はミスすることを、99個の命中マスと1個のミスマスで示した図

さらに、Firaxis版『XCOM』では乱数の シードがセーブデータに保存される 実装になっており、リロードしても同じ手順で行動すれば同じ結果になる、という「事前確定型(シード固定型)」の挙動だった。これはセーブ&ロードによる引き直し(save scumming)を抑制する意図的な設計だったが、プレイヤーには「表示されている確率が嘘」に見えた(なお拡張版『Enemy Within』ではロード時にシードを振り直す任意設定が追加された)。[11]

この問題は乱数実装の失敗ではなく、確率の表示と乱数アーキテクチャの組み合わせが体験と噛み合わなかった事例 と言える。[4]


コラム:同じ「シード保存」でも明暗が分かれる——『風来のシレン』の中断セーブ

XCOMの「シード固定」はプレイヤーの不信を買ったが、ほぼ同じ「乱数の再現性」を武器にして名作と評価されたのが、チュンソフトの『不思議のダンジョン』シリーズ(『トルネコの大冒険』『風来のシレン』)だ。

初期作のセーブ(中断)は、いわゆる状態のスナップショットではない。乱数シードと、プレイヤーがそれまでに取った全行動(入力)を記録しておき、再開時にその行動を最初から再生(シミュレート)して中断地点の状況を復元する という、リプレイ型の方式を採っていた。[20][21]

この設計は理にかなっている。不思議のダンジョンはフロアに入るたびに乱数で地形・アイテム・敵配置を丸ごと生成するため、その時点の盤面をそのまま保存するより、「フロア開始時のシード+それ以降の入力」を保存するほうが、はるかに容量効率が良いからだ。[20]

そして副次的な効果として、セーブからやり直す「リセット技(save scumming)」が原理的に封じられる。中断データから再開しても、それは続きを再現しているだけで、過去をやり直せるわけではない。これはローグライクの「一度の失敗が取り返しのつかない緊張感」というジャンルの根幹そのものだ。[21]

注目すべきは、XCOMとシレンが 本質的に同じ「シードによる再現性」という仕組み を使っていながら、プレイヤーの受け止め方が正反対だった点だ。XCOMでは「表示された確率が嘘に見える」不満につながり、シレンでは「やり直せないからこそ面白い」という魅力として受け入れられた。違いを生んだのは乱数の正しさではなく、ジャンルの文脈とプレイヤーへの提示の仕方 である。本記事が繰り返し述べてきた「数学的な正しさよりプレイヤーの納得感」という教訓が、ここにも表れている。[4]

余談:SFC版『風来のシレン』の乱数は、当時主流だったテーブル参照や線形合同法ではなく、XORとシフトを用いる線形帰還シフトレジスタ(LFSR/Xorshift系)に近い先進的なアルゴリズムが使われていたと解析されている。[22]


早期に乱数の失敗へ気づけた事例:『Slay the Spire 2』

カルドセプト・サーガの偏りが「発売後」にプレイヤーの手で発見され、メーカーの公式認定までに3週間を要したのに対し、ちょうど20年後の2026年には、対照的な経緯をたどった事例が生まれた。デッキ構築型ローグライク『Slay the Spire 2』(Mega Crit)で報告された乱数の偏りである。本作は早期アクセス(アーリーアクセス)中であり、一人のプレイヤーによる学術的な分析がきっかけとなって、偏りはわずか数日で修正された。これは「乱数の偏りに早期に、しかも学術的に気づけた」好例として、本記事で取り上げる価値がある。[23][24]

「気のせい」だと思われていた偏り

プレイヤーコミュニティでは以前から、特定のランダムイベントで「いつも同じ結果ばかり出る」「不運が偏っている」という声が上がっていた。だが、こうした訴えは長らく 確証バイアス(自分の思い込みを裏づける事象ばかりが記憶に残る認知の偏り。後述)として片付けられがちだった。実際、後に偏りを突き止めた分析者自身も、当初はそれらの投稿を典型的な確証バイアスだと反射的に切り捨てていたという。[23][24]

ところが調べてみると、プレイヤーの直感のほうが正しかった。本作の乱数は、確かに偏っていたのである。後述する「数学的に正しい乱数とプレイヤーが感じる乱数のズレ」が 逆向き に現れた——つまり「正しいはずの乱数が偏って感じられた」のではなく、「偏って感じられた乱数が、実際に偏っていた」事例だという点が、この事例を特異で示唆に富むものにしている。[23]

何が起きていたか——「相関した乱数生成器(CRNG)」

分析を行ったのは、マサチューセッツ工科大学(MIT)で数学・コンピューターサイエンス系の学士、およびコンピューターサイエンス系の修士を修めたAndy Tockman(tckmn)氏。2026年6月15日、同氏は確率分布の実測データを添えた技術レポートを公開した。[24][23]

本作は、イベントや戦闘など用途ごとに 個別の乱数生成器(RNG)を多数用意し、それぞれ異なるシードを与える 設計を採っていた。「別々のシードを与えれば、各RNGは独立に振る舞うはずだ」という、一見すると妥当な前提に立った実装である。前作『Slay the Spire』では全RNGが同一の初期状態から始まってしまい、過去のランダム結果から未来の結果を予測できる「相関した乱数(CRNG:Correlated RNG)」が問題となっていたため、その反省を踏まえた対策でもあった。[23][25]

ところが、シードの差し替えに使われた下層の擬似乱数(C# 標準の System.Random)には、出力がシード値に対してほぼ 線形 に振る舞うという性質があった。このため「シードが既知の一定値だけずれた2つのRNG」は、出力もまた既知の量だけずれた値を返してしまう。結果として、あるRNGの最初の出目を観測すれば、ほかのすべてのRNGの最初の出目に関する情報が得られる——独立どころか、すべてが相関した状態に陥っていた。[23]

独立なRNGの散布図と、System.Randomの線形性で相関したRNGの散布図を比較した図

これは本記事冒頭で述べた「使っているアルゴリズムの素性を確認せよ」という教訓の、20年越しの再演でもある。カルドセプト・サーガが線形合同法の 下位ビット に足をすくわれたのに対し、本作は標準ライブラリの乱数が持つ 線形性 に足をすくわれた。いずれも「とりあえず標準の乱数を使えばよい」という発想の危うさを示している。[8][23]

具体的な影響

レポートが挙げた偏りの例は、ゲームバランスや進行体験に直接響くものだった。[23]

興味深いのは、この発見が 狙って見つけたものではなかった 点だ。分析者は当初、特定の強力なコンボが成立するシードを探すプログラムを書いていた。ところが、ある条件を加えた途端に該当シードが一つも見つからなくなり、不審に思って乱数の生の出力を可視化したところ、本来バラバラに散らばるはずの値がきれいな相関を描いていた——そこから全乱数の相関を洗い出す調査へと発展したのである。偶然の違和感を放置せず、可視化と統計で裏を取った姿勢こそ、この事例を「学術的」たらしめている。[23]

早期発見と迅速な修正

同氏はレポートの結びで、この挙動はバグであり修正されるべきだと開発元へ呼びかけた。本作がまだ早期アクセス中であり、前作で同種の問題が発覚した時期よりも開発サイクルのはるかに早い段階で見つかったこと、そして問題の修正自体は技術的に容易であること(同氏は差し替え可能な約50行の代替乱数生成器のコードまで添えた)を根拠に、開発チームは必ず対応するだろうと期待を述べている。[23]

その期待は、わずか4日で現実になった。2026年6月19日、Mega Critはメジャーアップデート v0.107.1 を配信。このアップデートには「RNGの刷新(RNG Rework)」が含まれ、これまでの乱数生成に偏りがあったことを認めたうえで、新たな乱数生成器を実装したと報告している。通常はベータ版での検証を経てから本実装へ移すところを、異例の速さで対応した格好だ。開発元は分析者へ謝意を示し、これでプレイヤーの“不運”も本当にランダムになったとユーモアを交えて応えたと報じられている。[24][26]

プランナーへの教訓

この事例が示すのは、失敗の回避策というより 「偏りに気づける組織と文化」の作り方 だ。

  1. 「別シードなら独立」も素朴な仮定にすぎない:カルドセプトの「下位ビット問題」と同じく、独立性は下層アルゴリズムの素性に依存する。複数系統の乱数を使う設計では「シードをずらせば十分」と決めつけず、系統間の相関まで検証対象に含めるべきだ
  2. プレイヤーの「偏ってる」という直感を、確証バイアスと即断しない:認知バイアスは確かに存在する(後述)。しかし「気のせい」で片付ける前に、検証可能なデータを取れる体制があれば、本物の偏りを取りこぼさずに済む
  3. 早期アクセス・開発初期こそ外部検証の好機:発売後の発覚は修正コストも信頼回復コストも跳ね上がる。開発の早い段階で、コミュニティの分析を受け入れ、迅速に直す姿勢が被害を最小化する

「数学的に正しい乱数」と「プレイヤーが感じる自然な乱数」

前述のXCOM問題の背景には、認知科学で説明できる人間の偏りがある。[4]

これらの認知バイアスにより、数学的に正しい一様乱数がプレイヤーには「偏っている」「操作されている」と感じられる ことがある。ゲームプランナーが認識すべきは「確率の正しさよりも、プレイヤーの納得感を優先する設計が必要」という点だ。[4]


「それっぽい乱数」を作る設計テクニック

1. 袋方式(Bag Shuffle / 非復元抽選)

通常の抽選では「連続して同じ結果が出る」可能性があるが、袋方式では 全ての候補を「袋(箱)」に入れ、引いたら戻さない 非復元抽選を取る。[14][4]

例:1〜6のダイス出目をすべて袋に入れ、順番に引いていく。6回で全出目が1回ずつ出ることが保証される。引き終えたら袋を補充してシャッフル。これにより「同じ目が連続しすぎない」という自然な分布が実現できる。[15][14]

この発想はガチャに限らず幅広く使われる。テトリスの「7種類のテトリミノを1セットとして袋から順に出す」ピース生成や、音楽プレイヤーで同じ曲を繰り返さないシャッフル再生も、同じ非復元の考え方だ。[15]

ガチャに応用したものが「ボックスガチャ(箱ガチャ)」で、箱の中身が固定されているため、引くほど残りの当たりに当たりやすくなる。「N回で確定で最高レアが出る」天井システムも、引いた回数だけ当たりへ近づくという点でこの発想を取り入れたものだ。[16]

2. 確率変動型(Weighted Dynamic Random / 局所性乱数)

前の結果に応じて次回の確率を変動させる手法。「外れが続いたら当たりやすくなる」「当たりが続いたら外れやすくなる」という設計がプレイヤーの納得感を高める。[4]

ソシャゲのガチャ天井(Pity System)はこれの一形態だ。「天井を引き継ぐかどうか」はゲームバランスと収益性に直結するため、プランナーが明確な仕様として定義しておく必要がある。[17][16]

3. 複数乱数の合計(正規分布近似)

複数の乱数を加算して平均を取ると、中央付近の値が出やすく、極端な値が出にくい 分布になる(中心極限定理)。[15]

例:ダメージ計算でサイコロを1個振るのではなく2〜3個振って合計する。これにより「致命的なラッキー/アンラッキー」を抑えつつ、ランダム性は維持できる。RPGのダメージ幅をTRPGが複数ダイスで表現するのはこの理由による。

サイコロ1個・2個・3個の合計分布が、個数を増やすほど中央に寄ることを示す棒グラフ

4. 事前確定型 vs 事後抽選型

乱数の「いつ決まるか」も設計上の重要な選択だ。

方式 説明 利点 注意点
事前確定型 結果を事前に生成(またはシード固定)し、行動時に取り出す リプレイ再現が容易、バグ追跡が簡単 プレイヤーがリロードしても変わらない(XCOMの事例)
事後抽選型 行動のたびにその場で乱数を生成 直感的で「公平感」がある リプレイの再現が困難

[11][3]

乱数を行動前に決める事前確定型と、行動後に決める事後抽選型の違いを示す時系列図

5. シード共有による再現性の活用

シード値を共有することで、同じマップ・同じ結果を再現できる のが疑似乱数の利点だ。Minecraftのワールド生成はシードを入力することで同じ地形が再現できる仕組みであり、これがコミュニティでの「シード共有文化」を生んだ。[3]

デバッグの現場でも「バグが出たときのシードを記録しておく」ことで、再現環境が即座に構築できる。プランナーが「バグ報告にシードを含める」文化を作ると開発効率が上がる。


プランナーとエンジニアの共通言語チェックリスト

乱数にまつわる仕様を作る際、以下の項目をエンジニアと確認しておくと、カルドセプト・サーガのような事故を防ぎやすくなる。

確認項目 なぜ必要か
どのアルゴリズムを使うか 線形合同法の下位ビット問題を避けるため
乱数が「いつ」決まるか(事前/事後) プレイヤー体験と整合性を保つため
シード管理はどうするか デバッグ再現・リプレイ機能のため
天井カウントはセッション/アカウントどちらに紐付くか ガチャ仕様の抜け漏れ防止
確率の表示と内部実装は一致しているか プレイヤーの不信感防止(景品表示法対策含む)
局所的な偏りテスト(連続同値判定など)を行ったか カルドセプト型の事故防止

[2][3][4]


真の乱数が使われる場面

「真の乱数(ハードウェア乱数)」が実際に使われるのは、主にセキュリティが求められる場面だ。[18][2]

インテル製プロセッサにはハードウェア乱数生成器(RDRAND命令)が内蔵されており、熱ノイズを利用して真の乱数を生成している。ただしゲームロジック内の毎フレーム処理に使うには高コストであり、「疑似乱数の初期化(シード生成)に真の乱数を使う」という組み合わせが実用的だ。[19][2]


まとめ:乱数設計はプランナーの仕事

乱数は「エンジニアに任せればいい」と思われがちだが、どんな体験を生むかを決めるのはプランナーの仕事 だ。

「数学的に正しい乱数」がプレイヤーを不満にさせることは珍しくない。カルドセプト・サーガはアルゴリズムの選択ミス、XCOMは確率表示と実装のミスマッチ——どちらも根本はプランナーと実装者の認識のズレから生まれた問題だ。[11][10][4]

一方で『Slay the Spire 2』は、同じ「乱数の偏り」でも明暗が分かれる。発売後に発覚し対応が後手に回ったカルドセプト・サーガとは対照的に、早期アクセス中に外部の学術的分析で偏りが突き止められ、開発元がわずか数日で修正した。20年でゲーム開発のあり方は大きく変わった——オープンな開発体制と、データを扱えるコミュニティ、そして開発元の応答速度が、偏りを「致命傷」ではなく「改善の機会」へと変えたのである。[23][24]

乱数は「偶然性というスパイス」だ。それが過度なストレスになるか、適切なドキドキ感になるかは、設計者の理解次第である。アルゴリズムの詳細を全部覚える必要はない。しかし「どんな性質があり、どこで問題が起きやすいか」を知っておくことが、実装者との健全なコミュニケーションにつながる。[4]


References

1. 乱数をゲームで使う考え方|ランダム要素と確率計算の実装 - 乱数をゲームで使う考え方が分かる。ランダム要素と確率計算の実装を、Unity実装例とともに解説します。初心者でも理解できるよう、数式は最小限で …

2. 擬似乱数というかarc4random()の話。 - なるようになるかも - 擬似乱数と言えば、かのカルドセプトサーガの悲劇が有名です。 ダイスの出目が必ず奇数と偶数の繰り返しになるという、地味ながらゲームバランスの …

3. ゲーム制作技術メモ - 疑似乱数について - えむげんの箱庭 - ゲーム制作で欠かせない疑似乱数について、基本的な仕組みから品質の指標、代表的なアルゴリズム(PCG・メルセンヌツイスタ・xoroshiro128++)を解説 …

4. ゲームプランナー向けの乱数の話 | PDF - 参考論文・標準的なゲームプレイヤにとって自然に見える疑似乱数列の生成法・不満を抱かせにくいゲーム用擬似乱数列の生成と利用(野村 久光, SilaTemsiririrkkul, 池田 心)。

5. Unityでゲームを作ってるので乱数について勉強を始めてみたよ - メルセンヌ・ツイスタは既存の乱数生成法の弱点を補ったようなアルゴリズムで、周期が{2}^{19937}-1という気が遠くなるような長さの乱数生成法です。

6. 乱数について本気出して考えてみる - TechRacho - 線形合同法は32bitや64bitなど小さい内部状態で実装可能です。 他の有力なアルゴリズムだと、xorshift系の疑似乱数があります。名前の通りxor演算とshift …

7. 高速で質もよい疑似乱数生成アルゴリズム xorshift(xor128) - ヘキサドライブは、ゲーム制作 … 乱数生成といえば、『メルセンヌ・ツイスタ(MT)』がよく使われているだ …

8. カルドセプトサーガのダイスは偶→奇→偶→奇 - これは、非常にシンプルな線形合同法である。この乱数の最下位ビットは0と1の繰り返しになる。すなわち、偶数と奇数が交互に生成される。このことから、 …

9. 2.乱数発生の原理 - で詳しく述べますが,線形合同法に関する問題点として は,2進数で表現した乱数の下位ビットに,乱数列全体としての周期よりも短い周期性が現れる …

10. カルドセプト サーガ - バグ問題。 ソフトの発売後、オフライン・オンラインを問わず、ゲーム進行が不可能となるバグや、不可解な仕様が大量に発見された。バグの発見状況に関しては、有志 …

11. Only in XCOM where RNG is so bad that point blank shots … - Soooo confirmation bias is simply showing that there is no RNG just a seed at the start of the match…

12. 99% means the chance of you getting mad when it misses - Just started a new campaign and one of my rookies missed 4 shots, all 76%+, in a row. I know that’s …

13. I don’t mind a tough game, But missing 90% of my 99% hit … - It’s possible to have 99% a chance of something happening, but end up missing every time. Try it out…

14. The perception of randomness is an important element in … - One way round this is “bag random” where all the results 1-20 are put in a bag and you pull them out…

15. ゲーム制作技術メモ - 疑似乱数の品質とランダム性の定番 … - ゲーム開発で使う「乱数」は一様に見えて、実は用途ごとに求められる性質が異なります。サイコロやカードのシャッフル、音楽再生のランダム性、銃弾の …

16. ガチャ機能の作り方メモ:レアリティ・確率・天井を「不信感なく」 … - まとめ:ガチャは「確率」より「信頼」を先に作る · 目的を1行で定義する · レアリティの役割を決める · 表示設計(内訳・天井)を先に固める · 抽選ロジックと …

17. ガチャシステム完全解説|確率・レア度・天井の仕組み - ガチャ機能を作るときのレアリティ設計、排出確率、天井システム(一定回数で必ず入手)などの考え方と実装例を解説。ユーザーが不信感を抱かない表示の …

18. 乱数生成 - 通常、サイコロを振ると、1から6までの乱数が得られる。 ランダム化などの様々な応用により、ランダムデータを生成する様々な方法が開発されてきた。サイコロを転がす、 …

19. 「真の」ランダム数生成器? : r/computerscience - こんにちは - コンピュータサイエンスでよく聞くことの一つは、コンピュータは真のランダム数を生成することはでき …

20. ゲームのバグの話がしたかったんです。(前編) - 496の落書き帳 - 風来のシレンのセーブデータは初期状態(シード)+入力からなるリプレイデータであり、フロアを乱数生成する不思議のダンジョンでは、状態のスナップショットを保存するよりリプレイ情報を保存するほうが容量効率が良いと解説。

21. ルールと操作方法 - トルネコの大冒険 不思議のダンジョン 攻略 - 「中断」でセーブしてプレイを止められるが、ダンジョン内は自動的にセーブされ続けるため、前回セーブした地点から再スタートのようにやり直すことはできない仕組みである旨を記載。

22. SFC版風来のシレンの乱数生成アルゴリズムの話 解析編 - Qiita - SFC版風来のシレンの乱数生成ルーチンを解析。テーブル参照や線形合同法が多かった時代に、XORとシフトによる線形帰還シフトレジスタの特徴を満たす先進的なアルゴリズムが使われていたとする。

23. Correlated randomness in Slay the Spire 2 - Andy Tockman (tckmn) - 一次ソース。本作の多数のRNGがC#標準 System.Random のシード線形性により相関し、ネオーの骨の呪い分布やリバウンドの入手不能化などゲームバランスに直結する偏りを生んでいたことを、確率分布の実測と原因解析・修正案とともに示した技術レポート。

24. 『Slay the Spire 2』にて数学者が「乱数の偏りバグ」をガチ分析し修正に至る - AUTOMATON - tckmn氏の分析と、それを受けたMega Critによる早期修正(v0.107.1)の経緯を伝える日本語報道。MIT出身ユーザーによる学術的分析が迅速な修正につながった点を解説。

25. Correlated Randomness in Slay the Spire - Forgotten Arbiter - 前作『Slay the Spire』におけるCRNG(相関した乱数)問題を解析した先行研究。本作レポートが題名・構成のオマージュ元として参照している。

26. Slay the Spire 2 - Major Update #2 - v0.107.1 - Steam News - 開発元Mega Critによるパッチ告知。これまでの乱数生成の偏りを認め、乱数生成器を刷新(RNG Rework)したことを公表した一次ソース。


この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。