遅延を減らす、または偽装するためのさまざまな方法がありますが、これらの多くには欠点があり、すべてのケースに適用できるわけではありません。 ゲーム自体で同期が取れない場合、クライアントは遅延を減らすために地理的に近いサーバーでプレイすることを選択できるかもしれませんし、サーバーは結果として生じる問題に対処しなくて済むように、単に遅延の大きいクライアントを落とすことを選択できるかもしれません。 しかし、これらは最適解とは言えません。
多くの問題は、クライアントが自分自身の状態を追跡し、絶対的な状態をサーバーまたは他のクライアントに直接送信できるようにするだけで解決できます。 たとえば、クライアントは、プレイヤーのキャラクターがどの位置にいるのか、あるいはキャラクターが誰を撃ったのかを正確に述べることができます。 この解決策は有効で、ラグに関するほとんどの問題を解決することができます。 しかし、残念ながら、この解決策は、クライアントが誠実であるという前提に基づいています。 プレイヤーは、クライアントから直接、またはプロキシを介して間接的に、送信するデータを修正して、常に目標を達成できるようにすることができます。
クライアントサイド エディット
クライアントは通常、メインのゲーム ステートを定義することはできず、サーバーから受け取るため、クライアントサイドの補正の主なタスクは、仮想世界を可能な限り正確にレンダリングすることです。 更新が遅れたり、取りこぼしたりすることもあるため、クライアント側でゲームの流れを予測することが必要な場合もあります。 状態は離散的なステップで更新されるため、クライアントは利用可能なサンプルに基づいて動きを推定することができなければなりません。
外挿法は、将来のゲームの状態を推定しようとする試みです。
外挿は、将来のゲームの状態を推定しようとするもので、サーバーからのパケットを受信するとすぐに、オブジェクトの位置が新しい位置に更新されます。 次の更新を待って、現在の位置と更新時の動きに基づいて、次の位置が外挿されます。 基本的に、クライアントは動いているオブジェクトが同じ方向に継続すると仮定します。
補間の仕組みは、基本的にゲームの状態をバッファリングし、わずかな一定の遅延でゲームの状態をプレイヤーにレンダリングします。 サーバーからのパケットが到着すると、オブジェクトの位置をすぐに更新するのではなく、クライアントは、最後に知られた位置から始めて、位置の補間を開始します。 補間間隔を経て、オブジェクトは2つの位置の間をスムーズに移動するようにレンダリングされます。
両方の方法には利点と欠点があります。
- 補間によって、オブジェクトが有効な位置の間だけを移動することが保証され、一定の遅延と損失がない場合に良い結果が得られます。 ドロップされたパケットや順序を守らないパケットが補間バッファをオーバーフローした場合、クライアントは新しいパケットが到着するまでオブジェクトを位置に固定するか、代わりに外挿法にフォールバックする必要があります。
- 位置を外挿することの問題点はかなり明白で、将来を正確に予測することは不可能です。 動きが一定である場合にのみ、動きを正しくレンダリングしますが、これは常にそうではありません。 プレイヤーは速度と方向の両方をランダムに変更することがあります。 これにより、新しいアップデートが到着して推定位置が修正される際に、少量の「ワープ」が発生する可能性があります。また、実際には存在しない位置にプレイヤーがレンダリングされる可能性があるため、ヒット検出に問題が生じます。 最終的にはサーバーが弾薬、体力、位置などを追跡しますが、クライアントはプレイヤーの行動に基づいて新しいサーバー側のゲーム状態を予測することを許可される場合があります。例えば、サーバーがコマンドに応答する前にプレイヤーが移動を開始することができます。 このような変更は、通常の状況下では一般的に受け入れられ、遅延をほとんど透過的にします。 問題が発生するのは、遅延が大きい場合や損失が大きい場合で、クライアントの予測がサーバーによって非常に顕著に元に戻される場合です。
Server-sideEdit
クライアントとは異なり、サーバーは正確な現在のゲーム ステートを知っているので、予測は不要です。 サーバー側の遅延補正の主な目的は、クライアントのアクションの正確な効果を提供することです。 プレイヤーのコマンドが到着する頃には時間が経過しており、プレイヤーがコマンドを発行したときに見ていた世界の状態ではなくなっているからです。
Rewind timeEdit
この問題に対処する別の方法は、過去のゲーム状態を一定時間保存し、コマンドを処理するときにプレーヤーの場所を巻き戻すことです。 サーバーは、プレイヤーのレイテンシー (補間による固有の遅延を含む。上記参照) を使用して時間を適切な量だけ巻き戻し、ショットが発射されたときにシューティング クライアントが見たものを判断します。 これにより、通常、サーバーはクライアントがターゲットの昔の位置に射撃したのを見て、ヒットすることになります。
これは、プレイヤーが見ているものを直接狙うことができるWYSIWYGソリューションです。
これは、プレイヤーが見ているものを直接狙うことができる WYSIWYG のソリューションですが、その代償として、プレイヤーが攻撃を受けているときに、遅延の影響が悪化します：プレイヤー自身の遅延だけでなく、攻撃者の遅延も影響します。 多くの状況では、これは気になりませんが、隠れたばかりのプレイヤーは、自分の遅延が正当化されるよりも長い間、サーバーからダメージや死亡のメッセージを受信し続けていることに気づくでしょう。
巻き戻しから生じるデザイン上の問題の 1 つは、死んだプレイヤーの遅延したコマンドの巻き戻しを、そのプレイヤーがサーバー上で死んだ時点で停止するのか、それとも死んだ時点に「追いつく」まで実行し続けるのかということです。
巻き戻しは、1 人のプレイヤーの高い遅延が、低い遅延のプレイヤーのエクスペリエンスに悪影響を与えることを批判することができます。
クライアントを信頼する
クライアントがサーバーに何をしているかを伝え、サーバーが受信したデータを信頼することは可能です。 この方法は、不正行為の影響を受けやすいため、可能な限り回避されます。ネットワーク データを第 2 のコンピューターを介してルーティングすることは簡単なことであり、そのコンピューターに、捏造されたヒット メッセージを挿入したり、既存のメッセージを変更したりすることができます。
しかし、ゲームによっては、その規模の大きさゆえに、巻き戻しのような計算コストのかかる解決策が不可能なものもあります。たとえば、「バトルフィールド 3」では、クライアントがサーバーにヒットしたことを伝え、サーバーはその主張を受け入れる前に、もっともらしいかどうかの漠然としたテストを行うだけの「ハイブリッド ヒット検出」システムが使われています。
クライアントの結果を信頼することは、巻き戻しと同じ長所と短所があります。
クライアントに外挿する
あまり一般的ではないラグの解決策は、サーバー上で何もせず、各クライアントにそのレイテンシーをカバーするために外挿する (上記参照) ことです。
延長された外挿は、リモート プレイヤーが (脆弱ではありませんが) 本来見えないはずのものを見えるようにしてしまいます。
DesignEdit
ゲーム デザインによって、ラグの認識を減らすことは可能です。 テクニックとしては、クライアント側のアニメーションをアクションがすぐに起こったかのように再生したり、ホスト マシンの組み込みタイマーを減らしたり削除したり、ワープを隠すためにカメラのトランジションを使用したりします。