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

サーバー応答後にだけ演出（リクエスト・レスポンス方式） Request-response (no client-side feedback)

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

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

ボタンを押しても、サーバーの応答が来るまでアニメーションも音も出ません。Pingがそのまま反応速度になります。

なぜ スキル・移動・アイテム拾いを、サーバーの確認が来てから再生 → すると 押した瞬間から、往復時間 + ティック待ちの間まったく反応なし → 画面では Pingが150msなら、すべての行動が0.2秒ずつ遅れてもっさりする

症状

入力遅延

要因

遅延

誰に起きるか

自分だけ

いつ

常に, 特定の操作をしたとき

担当

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

ゲーム開発チームの対応

クライアント：アニメーション・音・エフェクトは押した瞬間に開始（先行演出）、結果（ダメージ・報酬）だけをサーバーの確定後に表示、移動・通常攻撃は予測してすぐに反映、サーバーから位置の補正を受けたら、その位置からまだ確認されていない入力を適用し直す。サーバー：受け取った入力で移動を自ら計算し、クライアントが予測した位置との差が基準を超えたときだけ補正値を送る。

数値の目安

反応時間 ≈ Ping + ティック間隔の半分 + 1フレーム。1秒20ティック・Ping 150msなら約190ms。

グラフでは

最初から常に高い · 入力から演出開始までの時間、RTT（Ping）

確認箇所

開発ビルドのクライアントログにボタン入力の時刻、最初のアニメーション・音の開始時刻、サーバー応答の到着時刻を記録し、ゲーム内のRTTと並べて確認。エンジンのネットワークエミュレーション（Unreal NetEmulation.PktLag）や試験サーバーのLinux tc netemで遅延を加え、Pingを変えながら測定

該当する場合

演出の開始が常にサーバー応答の到着と同じ瞬間で、入力から演出までの時間がRTT + ティック待ちの分あり、加えた遅延の分だけそのまま延びる

該当しない場合

演出は押した瞬間に始まり、ダメージの数字などの結果だけが遅れるなら正常な設計。Pingが低い環境でもティック間隔以上遅れるなら、二重のティック待ちかクライアントのフレームの問題

確認手段

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

もっと詳しく

ターン制、カード、放置系のように速い反応が必要ないゲームでは、この方式が最も単純で安全です。問題になるのは、リアルタイムの操作があるゲームで、移動や通常攻撃までこの方式で作った場合です。

出典

1. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
   サーバーの結果だけを待つクライアントでは、遅延が500msならすべての行動が500ms後にしか見えない。クライアントサイド予測とサーバー補正で解決
2. Using Gameplay Abilities in Unreal Engine Epic Games
   Local Predictedは押した瞬間に実行してサーバーが最終決定、Server Initiatedは予測がないため使う本人に遅延が見える
3. Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
   クライアントが移動を予測・保存しておき、サーバーとの誤差が許容値（MAXPOSITIONERRORSQUARED）を超えたときだけ補正し、補正後に保存しておいた移動を適用し直す
4. Using Network Emulation in Unreal Engine Epic Games
   サーバー・クライアントに最小・最大の遅延とパケットロス率を設定して試験、コンソールではNetEmulation.PktLagのように設定
5. tc-netem(8) — Linux manual page iproute2
   送信パケットに遅延・ジッター（delay TIME JITTER）とパケットロス（loss random PERCENT）を加え、実際のネットワークを模倣する試験ツール

あわせて読みたい原因

同じ層：同期設計

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

同じ症状（入力遅延）を起こすほかの層の原因

• 大人数の描画負荷 L1 クライアントのゲームプロセス
• メインスレッドのパケット処理ボトルネック L1 クライアントのゲームプロセス
• V-Syncとレンダーキュー L1 クライアントのゲームプロセス
• 省電力モード・サーマルスロットリング L2 クライアントのOS・端末
• 同じ端末の他のアプリによる帯域幅の占有 L2 クライアントのOS・端末
• ディスプレイ・入力デバイス・フレーム生成による遅延 L2 クライアントのOS・端末
• Wi-Fiチャンネルの混雑 L3 家庭内ネットワーク
• バッファブロート（ルーターのキュー） L3 家庭内ネットワーク

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