ゲームラグ白書 › 同期設計
Pingに削られる短い判定の受付時間 Timing window too short for latency + reaction
原因ID sy-short-window · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
回避・パリィ・ガードのように反応すべき時間が短いと、Pingがその時間を削ってしまい、よけられない攻撃が生まれます。
なぜ ボスの攻撃の予兆0.5秒、パリィの判定0.2秒のような短い判定の受付時間 → すると 予兆を見るのが遅れ（下りの遅延 + 補間）、自分の入力も遅れて届く（上りの遅延 + ティック待ち） → 画面では 確かによけたのに当たる、パリィが不発になる
- 症状
- 不発・ロールバック, 入力遅延
- 要因
- 遅延
- 誰に起きるか
- 自分だけ, 特定の機能だけ
- いつ
- 特定の操作をしたとき
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・サーバーインフラ
- ゲーム開発チームの対応
- サーバー：攻撃の予兆をサーバー時刻で予約して前もって送る、判定の受付時間をPingの分だけ延ばす（ラグコンペンセーション）。クライアント：受け取った予兆を予約されたサーバー時刻に合わせて再生。
- インフラチームの対応
- ユーザーが多い地域の近くにサーバーを配置（地域サーバー）し、Ping自体を減らす。
- 数値の目安
- Ping 150ms、補間100msなら、予兆が自分の画面に出るまで約0.18秒、自分の入力がサーバーに届くまで約0.1秒かかります。人の反応時間0.25秒を足すと、0.5秒の予兆に反応するのはほぼ不可能です。
- グラフでは
- 一部だけ高い · 回避・パリィの失敗率（Ping帯別）
- 確認箇所
- サーバーログに判定の受付時間の開始・終了時刻、ユーザー入力のサーバー到着時刻、そのユーザーのRTTを記録し、失敗率をPing帯（例：50ms刻み）ごとに分けて確認
- 該当する場合
- Pingが高い帯ほど失敗率がはっきり高く、失敗した入力が受付時間の終了から少し後（RTTと補間時間を足した値以内）に届いている
- 該当しない場合
- Ping帯に関係なく失敗率が同程度なら、攻撃パターンの難易度の問題。入力が受付時間内に届いているのに失敗と出るなら、判定コードかサーバー側の検証を確認
- 確認手段
- ゲームサーバー・クライアントのログ・メトリクスが必要
出典
- Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
単純反応時間の平均は約231ms（機器の遅延を補正すると213ms）、近年の大規模研究では233〜400ms - Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
精密で締め切りが短い行動ほど遅延に敏感（一人称で約100ms、三人称で約500ms、全体を見渡す俯瞰視点で約1,000msが限界） - NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
サーバー時刻（ServerTime）に合わせてイベントを予約し、全クライアントが同じ瞬間に再生する方法
あわせて読みたい原因
同じ層：同期設計
同じ症状（不発・ロールバック）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る