ゲームラグ白書 › 同期設計
先行演出後のサーバー拒否 Client-side feedback rejected by server
原因ID sy-optimistic-reject · 主担当 ゲーム開発チーム・クライアント開発 · 副担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
自分の画面で先に見せたヒット・スキルを後からサーバーが認めないと、確かに見た結果がなかったことになります。
なぜ ヒットエフェクト・スキルモーションをサーバーの確認前に先に再生（先行演出） → すると サーバーが射程・対象の位置・クールタイム・リソースを改めてチェックして拒否 → 画面では 血しぶきが出たのにダメージなし、スキルのモーションだけ出て効果なし、クールタイムだけ回る
- 症状
- 不発・ロールバック, 引き戻し
- 要因
- 遅延
- 誰に起きるか
- 自分だけ, 特定の機能だけ
- いつ
- 特定の操作をしたとき
- 担当
- 主担当 ゲーム開発チーム・クライアント開発 · 副担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- クライアント：ダメージの数字・死亡・報酬など確定が必要な部分だけサーバーの結果で表示、よくある拒否理由は先にチェック、拒否されたらクールタイム・リソースを元に戻して理由を表示。サーバー：射程・対象位置のチェックにPingの分の余裕を持たせる、拒否の応答に理由を含めて送る、スキルごとの拒否率をメトリクスとして収集。
- 数値の目安
- 拒否の応答は、押してからPing + ティック待ちの分だけ遅れて届きます。Ping 150msなら、約0.2秒の間「当たった」と思い込みます。
- グラフでは
- 一部だけ高い · スキルごとのサーバー拒否率（Ping帯別）
- 確認箇所
- サーバーで、スキルごとの拒否率と拒否理由（射程、対象位置、クールタイム、リソース）を集め、ユーザーのRTT帯別に分ける。クライアントには、先行演出した行動が拒否された回数を記録
- 該当する場合
- 拒否が特定のスキルと射程・対象位置の理由に集中し、Pingが高いほど拒否率が上がる
- 該当しない場合
- 拒否理由がクールタイム・リソースでPingと関係ないなら、クライアントとサーバーのデータ値（クールタイム、コスト）が違っていないかを確認。拒否はなく、演出がサーバー応答の後にしか始まらないなら、サーバー応答後にだけ演出（リクエスト・レスポンス方式）
- 確認手段
- ゲームサーバー・クライアントのログ・メトリクスが必要
- もっと詳しく
- 先行演出はPingを隠す最もよい方法です。ただし、クライアントとサーバーが判断に使う情報（相手の位置、残りのリソース）が違うほど、拒否が増えます。スキルごとの拒否率をメトリクスとして集めておくと、判定が食い違う箇所を見つけやすくなります。
出典
- Using Gameplay Abilities in Unreal Engine Epic Games
Local Predictedのアビリティはクライアントで即座に実行するが、サーバーが最終決定し、結果を覆すことがある - Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
武器の発射をクライアントで予測してエフェクトを先に再生し、サーバーの結果で予測の誤差を修正
あわせて読みたい原因
同じ層：同期設計
同じ症状（不発・ロールバック）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る