タイムスタンプなしの受信即時再生 Events played on arrival (no timestamps)

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

サーバーのイベントに発生時刻を付けず、受け取ったらすぐに再生すると、ネットワークのジッターがそのまま演出のタイミングのばらつきになります。

なぜ「攻撃開始」「エフェクト再生」のイベントを届いた瞬間に実行 → すると パケットごとに到着時間が違うため、間隔がばらつく → 画面では 連続攻撃のモーションが速くなったり遅くなったりし、ボスの攻撃パターンのタイミングが毎回違う

症状: カクつき, 早送り
要因: ジッター
誰に起きるか: 自分だけ
いつ: 常に
担当: 主担当 ゲーム開発チーム・クライアント開発 · 副担当ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: クライアント：イベントに付いた時刻に合わせて再生（イベント予約・補間バッファ）。サーバー：イベントに発生時刻（サーバー時刻）を付けて送る。
グラフでは: 不定期なスパイク · イベントの再生間隔、パケットの到着間隔
確認箇所: サーバーログのイベント発生時刻と、クライアントログの到着・再生時刻をイベント番号で突き合わせて間隔を比較。開発ビルドでジッターを加えて（tc netemのジッター値、Unrealのネットワークエミュレーションの最小・最大遅延）再現してみる
該当する場合: サーバーでの発生間隔は一定なのに、再生間隔が到着間隔をそのままなぞってばらつく
該当しない場合: 到着間隔はそろっているのに再生がばらつくなら、クライアントのフレームの問題（フレームタイムのスパイク）。サーバーでの発生間隔からぶれているならティックバジェット超過
確認手段: ゲームサーバー・クライアントのログ・メトリクスが必要

出典

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
更新ごとにサーバー時刻を付け、現在時刻から補間時間（100ms）を引いた目標時刻の位置で描く
Snapshot Interpolation Gaffer On Games
受け取ったスナップショットをすぐ描くとジッターで途切れ、補間バッファに少しためてから描くとなめらか
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
RPCに送信時刻を入れ、受信側がサーバー時刻に合わせてエフェクトを再生する例
tc-netem(8) — Linux manual page iproute2
送信パケットに遅延・ジッター（delay TIME JITTER）とパケットロス（loss random PERCENT）を加え、実際のネットワークを模倣する試験ツール
Using Network Emulation in Unreal Engine Epic Games
サーバー・クライアントに最小・最大の遅延とパケットロス率を設定して試験、コンソールではNetEmulation.PktLagのように設定