マルチプレイヤーゲームでの位置の補間

マルチプレイヤーゲームの帯域幅を節約するために、サーバーティックごとにすべてのオブジェクトを更新するのではなく、各オブジェクトがupdateRateを持ち、このオブジェクトがXサーバーティックごとに更新されることをゲームに伝えます。

オブジェクトの更新メッセージを受け取ったとき、次の更新が来ると予想される時間を計算します。

origin = serverCurrentPosition
diff = serverNextPosition - origin
arriveTime = now + timeBetweenTicks * updateRate

オブジェクトを描画するとき、次の更新までの残り時間を計算し、それに応じて位置を補間します。

step = 100 / timeBetweenTicks * updateRate
delta = 1 - step * ((arriveTime - now) / 100)
position = origin + diff * delta

それは動作します...しかし、図面にはまだ少しのジッターがありますが、私の理論では、スケーリングはある程度のラグを処理する必要があるので、すべてがうまくいくはずです、そうでしょうか？

ここでの質問は、これが最良のアプローチですか？実際の遅延を計算に入れる必要がありますか？もしそうなら、どうすればいいですか？私はいくつかの実験を行いましたが、ジッターは悪化しました。

ラグは絶えず変化しているため、ジッタがあります。つまり、サーバーはtimeBetweenTicksティックごとに更新を送信しますが、クライアントは可変時間後に更新を受信します。その時間はおそらくtimeBetweenTicks良好な接続では近いでしょうが、正確に等しくはありません（さらに、サーバーとクライアントでサーバーの遅延と異なるクロック速度があるかもしれません）。

したがって、正確に指定された時間に更新を受信することに依存している場合、実際の更新の少し前/後に常に宛先に到着します。したがって、ジッタ。

ジッタを減らす簡単なアプローチは、「ゴムバンディング」を使用することです。これは、Martinが別の答えで提案していることです。基本的に、更新を受け取っても、すぐにオブジェクトの位置を変更するわけではありません。代わりに、クライアントの位置とサーバーの位置がわずかに異なる場合は、クライアントの位置の補間を開始し、特定の時間（たとえば、次の更新の途中）後にクライアントとサーバーの位置が収束するようにします。

セットアップのジッタを減らす別のアイデア：「現在の」座標と「次の」座標の両方を送信するため、オブジェクトの速度を計算できます。次に、更新が遅れる場合、オブジェクトをその宛先（つまり「次の」位置）で停止せずに、同じ速度で移動し続けます。オブジェクトの速度が急激に変化しない場合、これによりクライアントのモーションの滑らかさが大幅に向上します。

私はこの問題を以前に解決し、「ネットワークシャドウ」と呼ぶアプローチである程度成功しました。これが他の人がすることなのかどうかはわかりませんが、私にとっては常に機能しています。

ネットワーク全体で同期されている各エンティティには、目に見えないネットワークシャドウエンティティがあります。更新がネットワークから届くと、ネットワークのあるべき位置にシャドウを直接テレポートし、時間の経過とともにローカルの可視エンティティをシャドウに向かってゆっくりと補間します。

私は以前の回答にこのアプローチに関する多くの詳細をここに含めました

非常にスムーズな結果が得られる、わずかに異なるアプローチを詳しく説明した記事を書きました。http：//www.gabrielgambetta.com/fpm3.html