ゲームラグ白書 › 同期設計

コマンド同期の経路計算の不一致 Command sync with divergent pathing

原因ID sy-path-mismatch · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発

図と実験のあるメインページでこのカードを開く →

「ここへ行け」だけをやり取りして経路は両側でそれぞれ計算すると、計算が少し違うだけで、キャラクターやモンスターが別の経路を進んだ後、元の位置に引き戻されます。

なぜ クリック移動・モンスターの追跡で目的地だけを送り、経路はクライアントが別途計算 → すると 地形データの違い、ほかのキャラクターとの衝突、計算順序の違いで、サーバーと別の経路を移動 → 画面では モンスターが壁をすり抜けて進んだ後にパッと位置が移る、クリックしたキャラクターが滑るように向きを変える

症状

ワープ, 引き戻し

要因

遅延

誰に起きるか

特定の場所・チャンネル, 自分だけ

いつ

移動中・マップ切り替え時

担当

主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発

ゲーム開発チームの対応

サーバー：経路の中間地点（ウェイポイント）も一緒に送る、定期的に位置を合わせる。クライアント：ずれはなめらかに収束させる、サーバーと同じ地形データを使う。

グラフでは

不定期なスパイク · オブジェクトごとの位置補正の回数・距離

確認箇所

サーバーが送った位置とクライアントが計算した位置の差をオブジェクトごとに記録し、補正が起きた座標をマップ上にプロットしてみる。両側の経路の結果や位置をチェックサムにまとめて定期的に比較すれば、ずれ始めた時点を見つけられる

該当する場合

補正が特定の地形（段差、狭い通路、坂）や混雑した場所に集中し、ネットワークのメトリクスが正常なユーザーでも同じ場所で繰り返し起きる

該当しない場合

場所に関係なく、パケットロス・ジッターが跳ねた瞬間にだけ補正されるなら回線の問題。1匹のモンスターが複数の人の画面で同時に飛ぶなら、モンスターの制御権が遅いクライアントにないかを確認

確認手段

ゲームサーバー・クライアントのログ・メトリクスが必要

もっと詳しく

クリック移動・タブターゲットのゲームがPingに鈍感な理由の1つがこの方式です。その代わり両側の結果が同じになる保証がないので、ときどき位置を合わせる仕組みが欠かせません。浮動小数点演算は、CPUの種類、コンパイラとその最適化設定（デバッグビルドとリリースビルドの違いを含む）によって結果がわずかに変わることがあります。ロックステップ・ロールバックのように入力だけをやり取りし、両側の計算結果がまったく同じだと仮定する構造では、この小さな差が積み重なり、2つの画面のゲーム状態が分かれてしまうずれ（desync）が起きることがあります。

出典

1. Deterministic Lockstep Gaffer On Games
   同じマシンでは決定的でも、コンパイラ・OS・CPUが違えば浮動小数点の結果が変わることがある
2. State Synchronization Gaffer On Games
   入力と一緒に状態も送れば、完全な決定性がなくても両側を合わせられる
3. Peeking into VALORANT's Netcode Riot Games
   パケットロスや、2体のキャラクターが同じ場所へ行こうとしたときに、サーバーとクライアントのシミュレーションが食い違い、補正が必要になる
4. 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond Game Developer
   ごく小さな差が時間とともに大きくなり、ワーカーユニットの経路が少しずつずれる。ワールド・オブジェクト・経路探索をチェックサムで比較してずれ（out-of-sync）を見つける
5. Floating Point Determinism Gaffer On Games
   同じ浮動小数点のコードでも、コンパイラ・CPUアーキテクチャ、デバッグ・リリースビルドによって結果が変わることがある。AMDとIntelのCPUが超越関数でわずかに異なる値を返した事例
6. /fp (Specify floating-point behavior) Microsoft
   /fp:fastは浮動小数点演算の順序を入れ替えたりまとめたりするため、ほかの/fp設定と結果が変わることがあり、FMAでまとめた演算も、別々に乗算・加算した結果と異なることがある

あわせて読みたい原因

同じ層：同期設計

• サーバー応答後にだけ演出（リクエスト・レスポンス方式）
• 逐次往復の多いプロトコル（chatty）
• スキルの先行入力なし
• Pingに削られる短い判定の受付時間
• ラグコンペンセーションのない判定
• 過剰なラグコンペンセーション
• クライアント権威型
• ロックステップでの最も遅いプレイヤー待ち
• ロールバックネットコードの予測失敗
• タイムスタンプなしの受信即時再生
• 二重のティック待ち
• 厳しすぎるサーバー検証
• ホスト（部屋主）型の構成
• 先行演出後のサーバー拒否
• 低いスナップショット送信レート

同じ症状（ワープ）を起こすほかの層の原因

• 過度な外挿（デッドレコニング） L1 クライアントのゲームプロセス
• 受信バッファのあふれ L2 クライアントのOS・端末
• Wi-Fiのバックグラウンドスキャン L2 クライアントのOS・端末
• Wi-Fiの干渉・電波の弱さ L3 家庭内ネットワーク
• バッファブロート（ルーターのキュー） L3 家庭内ネットワーク
• 基地局のハンドオーバー（移動中） L3 家庭内ネットワーク
• モバイル電波の弱さ・不感地帯 L3 家庭内ネットワーク
• 5G↔LTEの頻繁な切り替え（5Gエリアの境界） L3 家庭内ネットワーク

図と実験のあるメインページでこのカードを見る