ゲームラグ白書 › 同期設計
低いスナップショット送信レート Low snapshot / update rate
原因ID sy-low-send-rate · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発
図と実験のあるメインページでこのカードを開く →
サーバーが位置の更新（スナップショット）を1秒に数回しか送らないと、その分だけ補間バッファを長く取る必要があり、ほかのキャラクターをより遠い過去の姿で見ることになります。
なぜ 送信量を節約するため、位置の更新を1秒に5〜10回しか送らない → すると なめらかに描くにはバッファをパケット間隔の2倍（200〜400ms）取る必要があり、短くするとパケットを1つ落としただけで止まる → 画面では 相手の方向転換が遅れて見え、判定と食い違う。バッファが短いとカクつき、パケットロス時にはワープ
- 症状
- カクつき, ワープ, 不発・ロールバック
- 要因
- 遅延, パケットロス
- 誰に起きるか
- サーバー全体
- いつ
- 常に
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発
- ゲーム開発チームの対応
- サーバー：近い対象や戦闘中の対象は頻繁に、遠い対象はまれに送る、変わった部分だけを送って（デルタ圧縮）1回のサイズを減らし、送信頻度を上げる。クライアント：補間バッファの長さをパケット間隔に合わせて自動調整。
- 数値の目安
- 1秒に10回ならパケット間隔100ms、バッファ200ms。Ping 150msの片道遅延75msを足すと、相手を約0.3秒前の姿で見ることになります。
- グラフでは
- 最初から常に高い · クライアントごとのパケット到着間隔、補間バッファの長さ
- 確認箇所
- サーバー側のパケットキャプチャで1人のユーザーへ向かうフローだけに絞り、WiresharkのI/O Graphsで毎秒のパケット数と間隔を確認。ゲーム側のログがあれば、オブジェクトごとの更新間隔と、クライアントの補間バッファの余裕（次のスナップショットが届くまでの残り時間）も合わせて確認
- 該当する場合
- 位置の更新が毎秒5〜10回（間隔100〜200ms）と常にまばらで、補間バッファを200ms超に設定しているか、バッファの余裕が頻繁に0になる
- 該当しない場合
- 更新は細かく送られているのに到着間隔だけがぶれるなら、ジッター・パケットロス側。混雑時に遠いオブジェクトだけをまれにしか受け取らないなら、接続ごとの送信バジェット・優先度
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
毎秒10回の更新なら、補間200msで1回の欠落に耐えられる。Half-Lifeのデフォルトは毎秒20回・補間100ms - Snapshot Interpolation Gaffer On Games
毎秒10個なら、2個連続のパケットロスまで耐えるのに350msの遅延が必要、毎秒30個なら150msに減る - State Synchronization Gaffer On Games
優先度の累積で重要なオブジェクトをより頻繁に送り、帯域幅の上限内で残りを順番に送信 - 8.8. The “I/O Graphs” Window Wireshark
表示フィルターに合うパケット数・バイト数を時間区間ごとのグラフに描く
あわせて読みたい原因
同じ層：同期設計
同じ症状（カクつき）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る