決定的ロックステップ（RTS）

状態を送らず「入力」だけを送るという発想

横にスクロール

『StarCraft』『Age of Empires』のような RTS（リアルタイムストラテジー）は、画面上に数百〜数千のユニットが存在します。もし各ユニットの位置・体力・状態を毎フレーム全プレイヤーへ送信すれば、帯域はユニット数に比例して膨れ上がり、大規模な戦闘ほど破綻します。決定的ロックステップ（deterministic lockstep）は、この問題を発想の転換で回避します。同期するのはゲーム状態ではなく、プレイヤーの入力（コマンド）だけです。

前提は単純かつ強力です。全クライアントがまったく同じ初期状態から出発し、まったく同じ入力列を、まったく同じ順序で、まったく同じ決定的なシミュレーションに食わせれば、途中経過も最終結果も完全に一致する——という決定論の性質を使います。送るべきは「プレイヤー1が座標(x,y)へ移動を命じた」といった数十バイトのコマンドだけで、その結果ユニットが実際にどう動くかは各端末が自分で計算します。帯域はユニット数に依存せず、プレイヤーが発行するコマンド数だけに比例するため、8人対戦で数千ユニットが乱戦しても通信量はごくわずかで済みます。

決定性という厳しい制約：ビット単位で一致させる

ロックステップの利点はすべて「全クライアントのシミュレーションが完全に一致する」という前提に乗っています。逆に言えば、どこか1台でも計算結果が1ビットでもズレた瞬間、以後の予測は雪だるま式に発散し、対戦は崩壊します。この状態を desync（同期ズレ）と呼びます。したがってロックステップ実装の本質は、ネットワークコードそのものよりも「シミュレーションを完全に決定的に保つ」ことにあります。決定性を壊す主な要因は次のとおりです。

• 浮動小数点演算: 同じ式でも、CPU アーキテクチャ・コンパイラ・最適化レベル・x87 と SSE の違い・FMA（積和融合）の有無・命令の並べ替えによって、丸め結果の最下位ビットが変わりうる。これがロックステップ最大の敵。
• イテレーション順序: ハッシュマップやセットを走査する順序が端末間で異なると、ユニットの処理順が変わり結果がズレる。順序が保証されたコンテナ（挿入順・ID 順）を使う必要がある。
• 乱数: 各端末が独立に乱数を引くと当然ズレる。シードを共有した決定的な擬似乱数生成器を全端末で同一手順で回す。
• 未初期化メモリ・ポインタ値・アドレス依存: 実行ごとに変わる値を計算やソートキーに使うと発散する。

決定性を担保する代表的な戦略が固定小数点演算です。座標や速度を「実数」ではなく「1単位=1/1000 のような固定スケールの整数」で表し、加減乗除をすべて整数演算に落とします。整数演算はどのプラットフォームでも結果が完全に一致するため、浮動小数点の非決定性を根本から排除できます。平方根や三角関数も、整数入力・整数出力の自前ルックアップテーブルや近似で実装し、標準ライブラリに依存しないのが定石です。

遅延ステップ：回線遅延をどう吸収するか

ロックステップの2つ目の課題は遅延です。あるターンのシミュレーションを進めるには、その ターンに属する全プレイヤーの入力が到着していなければなりません。誰か1人のパケットが遅れると、全員がその人を待って停止する——これが素朴な同時ロックステップの弱点で、体感は最も遅いプレイヤーの回線に律速されます。

これを緩和するのが入力遅延（input delay）＝遅延ステップです。プレイヤーが今フレーム N で出したコマンドを、その場では実行せず、N + d フレームで実行すると全員が約束します（例えば d = 3）。こうすると各コマンドには送信から実行まで d フレーム分の猶予が生まれ、その間にパケットが全端末へ届けばよいことになります。d はラウンドトリップ遅延（RTT）を吸収できる大きさに設定します。

入力遅延つきロックステップの1フレーム:

  1. 今フレーム N の自分の入力を採取し、実行予定フレーム N+d を
     付けて全プレイヤーへ送信する
  2. 実行すべきフレーム N の入力（= d フレーム前に配られた
     全員のコマンド）が揃っているか確認する
     - 揃っている → フレーム N のシミュレーションを1ステップ進める
     - 未着がある → stall（全員が待つ／描画は補間で滑らかに見せる）
  3. フレーム N の状態からチェックサムを計算し、比較用に共有する
  4. N ← N+1 へ進む

同期チェックサム：発散を即座に捕まえる

決定性は「壊れていないこと」を祈るものではなく、継続的に検証するものです。そのために各ターンごとに、そのフレームのゲーム状態全体（全ユニットの座標・体力・乱数生成器の内部状態など）を1つの値へ畳み込んだチェックサム（同期ハッシュ）を計算し、全プレイヤーで突き合わせます。あるフレームでチェックサムが1人でも他と食い違えば、その瞬間に desync が起きたと確定できます。

同期チェックサムの役割:

  ・毎フレーム（または一定間隔で）状態をハッシュ化して交換
  ・値が全員一致 → シミュレーションは同一の軌道上にある
  ・値が食い違う → その端末が発散。どのフレームで壊れたかが判明する
  ・デバッグ時は状態をより細かく（変数単位で）記録し、
    壊れた最初のフレームを二分探索で特定してバグ源を絞り込む

チェックサムの真価はデバッグにあります。desync は再現が難しい最悪級のバグですが、「どのフレームで初めてズレたか」が分かれば、その1フレーム前後だけを詳細ログと突き合わせ、原因（順序依存のコンテナ走査、うっかり混入した浮動小数点、共有し忘れた乱数引き）を追い詰められます。運用面では、desync を検出したら即座にゲームを停止しリプレイやログを保存する設計にしておくと、事後解析が現実的になります。

まとめ：使い分けの判断軸

決定的ロックステップは、大量のユニットを低帯域で同期するという RTS 固有の要求に対する、極めて合理的な解です。入力だけを配り計算は全員が各自で回す——この単純な原理が、通信量をユニット数から解き放ちます。代償として全端末のシミュレーションを完全に決定的へ保つ厳しい規律が求められ、浮動小数点の非決定性を固定小数点で封じ、回線遅延を入力遅延で吸収し、同期チェックサムで発散を常時監視する。この三点セットを設計に織り込めるかどうかが、ロックステップを成立させる分水嶺です。GPU 側の描画やアニメーションは非決定的で構わず、決定性を要求されるのはあくまでゲームロジック（シミュレーション）に限られる——描画と計算を明確に分離する設計思想は、グラフィックスのトップで扱う描画パイプラインの考え方とも接続します。