エンティティ補間と遅延補償

なぜ生のパケットをそのまま描くと破綻するのか

権威型サーバー（authoritative server）方式のマルチプレイヤーでは、ゲーム状態の真実はサーバーが握り、各プレイヤーの位置や向きをスナップショットとして定期的に配信します。配信レート（tick rate）は典型的には毎秒20〜64回で、連続的ではありません。60fpsで描画するクライアントから見れば、他プレイヤーの新しい位置情報は数フレームに一度しか届きません。

この離散的なスナップショットを届いた瞬間にそのまま反映すると、他プレイヤーは1秒間に20〜64回だけワープするカクついた動きになります。さらにUDPパケットは到着間隔が揺らぎ（ジッタ）、順序が入れ替わり、時に欠落します。生データを直接描けば、その揺らぎがそのまま画面の震えとして現れます。この問題を、描画の滑らかさ（クライアント側の補間）と、当たり判定の正しさ（サーバー側の遅延補償）という2つの独立した仕組みで解くのが本稿の主題です。

スナップショット補間：あえて過去を描いて滑らかさを買う

エンティティ補間（entity interpolation）の中核は、受信済みの2つのスナップショットの間を内挿して描くことです。ポイントは、クライアントが常に「最新の受信状態」ではなく「少し過去の状態」を描く点にあります。描画時刻を意図的に 補間遅延（interpolation delay、しばしば100ms前後）だけ巻き戻し、その時刻を挟む2つのスナップショットから線形補間で位置を求めます。

補間の基本手順（描画フレームごと）:

  render_time = now - interp_delay        // 例: interp_delay = 100ms
  (S0, S1) = render_time を挟む前後のスナップショットを選ぶ
             // S0.t ≤ render_time ≤ S1.t
  alpha = (render_time - S0.t) / (S1.t - S0.t)   // 0..1
  pos   = lerp(S0.pos, S1.pos, alpha)     // 位置は線形補間
  rot   = slerp(S0.rot, S1.rot, alpha)    // 回転は球面線形補間

なぜ過去を描くのか。それは内挿を成立させるには、描こうとする時刻の「後ろ」のスナップショットが手元に届いていなければならないからです。render_time を現在に置くと未来の点が必要になり内挿できません。補間遅延 を確保することで、その分の余裕の中に必ず2点が入り、パケットが1つ欠けても次の点まで滑らかに繋がり、ジッタも吸収されます。代償は他プレイヤーが 補間遅延 ＋ 平均遅延だけ「過去に見える」こと。この見た目の遅れが、後のラグ補償で埋め合わせる対象になります。

外挿（extrapolation）：バッファが枯れたら未来を推測する

render_time より後ろのスナップショットがまだ届いていない場合、内挿すべき2点が揃いません。パケットが大きく遅延・欠落したときに起きます。ここで選択肢は2つ。ひとつは他機をその場で停止させて次の受信を待つ（フリーズ）。もうひとつが外挿（extrapolation）で、直近の速度・加速度から未来位置を推定して描き続けることです。

外挿（前方の点が無いとき）:

  dt        = render_time - S_last.t          // 最新点からの経過
  pos_guess = S_last.pos + S_last.vel * dt    // 等速仮定で前進
  // 実際に次のスナップショットが届いたら真値へ補正する

外挿は内挿と正反対の性質を持ちます。内挿は確定した過去を描くので必ず正しく滑らかですが、外挿は未確定の未来を描くので、対象が急に止まる・曲がると予測が外れ、真値が届いた瞬間に位置が飛ぶ（rubber-banding）。そのため外挿は短時間（せいぜい数フレーム、100〜250ms程度）に制限し、超過したらフリーズへ切り替えるのが安全策です。等速外挿が基本で、加速度まで見ると誤差が発散しやすくなります。動きが予測しづらいゲームほど外挿は不利で、内挿主体に倒す設計が好まれます。

ラグ補償：サーバーが「撃った瞬間」へ巻き戻す

ここまでで他プレイヤーは滑らかに、しかし 補間遅延 ＋ 遅延だけ過去に表示されています。プレイヤーが画面上の敵の頭に照準を合わせて撃つとき、その敵はサーバー上の現在位置ではなく過去の位置です。もしサーバーが現在の状態で当たり判定を取れば、狙ったはずの弾はことごとく外れます。速い敵ほど表示位置と現在位置の差が開くため、遅延の大きいプレイヤーは「明らかに当てたのに当たらない」状態に陥ります。

これを解決するのがラグ補償（lag compensation）＝サーバー側巻き戻し（server-side rewind）です。サーバーは全エンティティの位置履歴を一定時間ぶんリングバッファに保持しておき、あるプレイヤーの射撃コマンドを受け取ったら、そのプレイヤーが実際に画面で見ていた時刻まで世界を巻き戻し、その過去の状態でヒットスキャンの当たり判定を行います。

サーバー側のラグ補償（射撃コマンド受信時）:

  // クライアントが弾を撃った時点で見ていた時刻を再構成
  cmd_time = server_recv_time
             - player_rtt / 2          // 上り遅延ぶん戻す
             - player_interp_delay      // 他機の補間遅延ぶん戻す

  // その時刻の全ヒットボックス位置を履歴から復元（必要なら内挿）
  restore_all_hitboxes_to(cmd_time)

  hit = raycast(shot_origin, shot_dir)  // 巻き戻した世界で判定
  restore_all_hitboxes_to(present)      // 判定後すぐ現在へ戻す

要点は、サーバーが RTT/2（上り片道遅延）と撃った側の 補間遅延 を足し合わせて、そのプレイヤーのクライアント画面と同じ過去の瞬間を復元することです。これにより「自分の画面で頭に合わせて撃った」という主観がサーバー判定と一致し、遅延の大小によらず撃つ側の体験は公平になります。多くの実装ではクライアントが射撃コマンドに自分の見ていたタイムスタンプ（あるいはコマンド番号）を添えて送り、サーバーはそれを検証したうえで採用します（過大な巻き戻し要求はチート防止のため上限でクランプします）。

公平性のトレードオフと設計判断

横にスクロール

エンティティ補間とラグ補償は、遅延という物理的制約の下で「誰の主観を正とするか」を選ぶ仕組みです。撃つ側を優先すれば命中体験は良くなるが遮蔽後死（撃たれる側の不公平）が増え、撃たれる側を優先（現在時刻で判定、巻き戻さない）すれば遮蔽は守られるが高遅延プレイヤーはまともに当てられません。中間として、巻き戻し上限を短く保つ、ヒット確定はサーバーだが発砲エフェクトはクライアント予測で即出す、被弾者側の視点でも一定の猶予（favor-the-shooter を弱める）を入れる、といった調整が行われます。

さらに tick rate を上げれば履歴の時間解像度が上がり、巻き戻し精度と応答性が改善しますが、帯域とサーバーCPUのコストが線形に増えます。スナップショットはデルタ圧縮（前回確認済み状態との差分のみ送る）や関心領域（AoI）フィルタ（見えない相手は送らない）で帯域を抑えるのが定石で、これらは補間・補償の基盤となるデータ供給の質を左右します。ネットワーク層のジッタ・パケットロスの扱いはネットワークの原理・プロトコル側の理解が、他プレイヤーを滑らかに見せる補間・外挿の描画はグラフィックス・レンダリングの原理側の理解が土台になります。

まとめ

離散的なスナップショットとジッタの多いUDPを前提に、ネットワークゲームは描画と当たり判定を別々の仕組みで滑らかかつ公平にします。エンティティ補間は描画時刻をあえて 補間遅延 だけ過去へ置き、受信済みの前後2スナップショットを内挿することで、疎で不揃いなパケットからでも他プレイヤーを滑らかに描きます。前方の点が届かないときは、直近の速度から未来を推す外挿で短時間だけ穴を埋めますが、誤予測で位置が飛ぶため内挿主体が基本です。こうして他機は過去に表示されるため、サーバーは射撃時に RTT/2 + 補間遅延 だけ世界を巻き戻すラグ補償で、撃った側が見た瞬間の当たり判定を再現します。これは撃つ側の主観を守る反面、遮蔽したはずの撃たれる側に理不尽を強いる原理的なトレードオフであり、巻き戻し上限や被弾側への猶予で最大の不公平を制限します。補間遅延の長さ、スナップショットレート、巻き戻し上限という3つのパラメータをどう設定するかが、そのゲームのプレイ感と公平性の性格を決めるのです。