マルチプレイヤー システムのアーキテクチャを説明しているように見える、Valve のこの記事を読んでいます。ドロップされたパケットを処理できるように、クライアントでレンダリングを数ティック遅らせているようですが、パケットを「デルタスナップショット」(隣接する 2 つの状態の差) として送信することもあります。
時間 A、B、C があり、クライアントが時間 A では正しいが、B でパケットをドロップし、C でパケットを受信するとします。時間 C での状態を正しく推定するにはどうすればよいでしょうか? C のパケットは状態 B と C の間のデルタのみを伝え (私が思うに)、クライアントは A の状態しか知りません。ここで何が欠けているのでしょうか?
デルタは、(デルタまたはスナップショットによって) 送信された前のメッセージに関連している必要はありません。代わりに、それらは最後に承認された状態に関連します。したがって、上記の例では、C での更新は A に関連するデルタである可能性があります。したがって、メッセージ B を失うと、デルタが大きくなり (そして潜在的にエラーが蓄積される) 不便になりますが、最終的にはメッセージが通過して確認され、サーバーは、その更新された状態に関連するデルタの送信を開始できます。
完全な状態は、定期的に、またはクライアントの要求に応じて同期されます。内挿/外挿を使用して、完全な位置更新を待機している間のパケット損失を補正できます。一部のイベントでは、確実な配信が必要であり、受信を確認する手段を追加できます。
Glenn Fiedlerのブログには、ネットワーク ゲームに関する優れた記事がいくつかあります。
Quake 3 ネットワーキングに関するこの古い記事は、似ているように聞こえます。デルタ状態は、受信した最後のクライアント確認済み状態からの変更を表します。そのため、サーバーがクライアントが遅れていることを確認すると、クライアントの状態と現在のサーバーの状態の違いから次のデルタが作成されます。
実装を見なくても、パケット C には、それがデルタであるパケット (この場合はパケット B) の ID も含まれていると想像できます。
クライアントがパケット A に続いてパケット C を受信すると、パケット B をまだ見ていないことがわかり、その結果、サーバーから完全な更新を要求できます。
サーバーはおそらく定期的に完全同期 (デルタではなく) を送信しますが、それほど頻繁ではありません。少なくとも私はそうしています。
たまに完全なスナップショットを送信していると思います。これが、遅延のあるゲームでは、デルタ フレームがドロップされるときに人々が間違った速度で実行し、完全なスナップショットが入ったときに正しい位置に「テレポート」することが含まれる理由です。
リンクされた記事から：
通常、フル (非デルタ) スナップショットは、ゲームが開始されたとき、またはクライアントが数秒間大量のパケット損失に見舞われたときにのみ送信されます。クライアントは、cl_fullupdate コマンドを使用して完全なスナップショットを手動で要求できます。