ネットワーク遅延補償アルゴリズムを使用してモバイル シューティング ゲームの弾道計算の仕組みを強化した方法

こんにちは、私は Pixonic のサーバー開発者、Nikita Brizhak です。 今日はモバイルマルチプレイヤーにおけるラグの補正についてお話したいと思います。

サーバーラグの補償については、ロシア語を含む多くの記事が書かれています。 このテクノロジーは 90 年代後半からマルチプレイヤー FPS の作成に積極的に使用されてきたため、これは驚くべきことではありません。 たとえば、最初に使用したものの XNUMX つである QuakeWorld MOD を思い出すことができます。

モバイル マルチプレイヤー シューター Dino Squad でも使用しています。

この記事での私の目標は、すでに何千回も書かれていることを繰り返すことではなく、テクノロジー スタックとコア ゲームプレイ機能を考慮して、ゲームにラグ補正をどのように実装したかを説明することです。

私たちの大脳皮質とテクノロジーについて少しお話します。

Dino Squad はネットワーク モバイル PvP シューティング ゲームです。 プレイヤーはさまざまな武器を装備した恐竜を操作し、6対6のチームで戦います。

クライアントとサーバーは両方とも Unity に基づいています。 アーキテクチャはシューティングゲームにとって非常に古典的です。サーバーは権威主義的で、クライアント予測はクライアント上で機能します。 ゲーム シミュレーションは社内 ECS を使用して作成され、サーバーとクライアントの両方で使用されます。

ラグ補正について初めて聞いた場合は、この問題について簡単に説明します。

マルチプレイヤー FPS ゲームでは、通常、試合はリモート サーバー上でシミュレートされます。 プレイヤーは入力 (押されたキーに関する情報) をサーバーに送信し、それに応答してサーバーは、受信したデータを考慮して更新されたゲーム状態をプレイヤーに送信します。 このインタラクション スキームでは、前進キーを押してからプレイヤー キャラクターが画面上で移動する瞬間までの遅延は常に ping より大きくなります。

ローカル ネットワークでは、この遅延 (一般に入力ラグと呼ばれます) は目立たないかもしれませんが、インターネット経由でプレイする場合、キャラクターを制御するときに「氷の上を滑っている」ような感覚が生じます。 この問題はモバイル ネットワークにも二重に関係しており、プレーヤーの ping が 200 ミリ秒の場合でも依然として優れた接続とみなされます。 多くの場合、ping は 350、500、または 1000 ミリ秒になります。 そうなると、入力ラグのある高速シューティングゲームをプレイすることはほとんど不可能になります。

この問題の解決策は、クライアント側のシミュレーション予測です。 ここでは、サーバーからの応答を待たずに、クライアント自体が入力をプレイヤー キャラクターに適用します。 そして、答えを受け取ると、単純に結果を比較し、相手の位置を更新します。 この場合、キーを押してから結果が画面に表示されるまでの遅延は最小限です。

ここでのニュアンスを理解することが重要です。クライアントは常に最後の入力に従って自分自身を描画し、サーバーからのデータの以前の状態に従ってネットワーク遅延を伴って敵を描画します。 つまり、敵を撃つとき、プレイヤーは自分自身と比較して過去の敵を見ることになります。 クライアント予測の詳細 前に書きました.

したがって、クライアント予測は XNUMX つの問題を解決しますが、別の問題が発生します。プレイヤーが過去に敵がいた地点で射撃した場合、サーバー上で同じ地点で射撃すると、敵はその場所にいない可能性があります。 サーバー遅延補正は、この問題の解決を試みます。 武器が発砲されると、サーバーはプレイヤーが発砲時にローカルで見たゲーム状態を復元し、本当に敵に命中できたかどうかを確認します。 答えが「はい」の場合、その時点で敵がサーバー上にいない場合でも、ヒットはカウントされます。

この知識をもとに、私たちは Dino Squad でサーバーラグ補正の実装を開始しました。 まず第一に、クライアントが見たものをサーバー上で復元する方法を理解する必要がありました。 そして、具体的に何を復元する必要があるのでしょうか? 私たちのゲームでは、武器やアビリティからのヒットはレイキャストとオーバーレイ、つまり敵の物理的なコライダーとの相互作用を通じて計算されます。 したがって、プレイヤーがローカルで「見た」これらのコライダーの位置をサーバー上で再現する必要がありました。 当時は Unity バージョン 2018.x を使用していました。 そこでの物理 API は静的であり、物理世界は単一のコピーの中に存在します。 状態を保存して、箱から復元する方法はありません。 じゃあ何をすればいいの？

解決策は表面上にあり、そのすべての要素は他の問題を解決するためにすでに使用されていました。

1. 各クライアントについて、キーを押したときに対戦相手を見た時刻を知る必要があります。 この情報はすでに入力パッケージに書き込まれており、それを使用してクライアントの予測を調整しています。
2. ゲーム状態の履歴を保存できる必要があります。 その中で、私たちは対戦相手（したがって彼らの衝突者）の位置を保持します。 サーバー上にはすでに状態履歴があり、それを使用してビルドしました デルタ。 適切な時期を知ることで、歴史の中で適切な状態を簡単に見つけることができます。
3. 履歴からゲームの状態を取得したので、プレーヤーのデータを物理世界の状態と同期できるようにする必要があります。 既存のコライダー - 移動、不足しているコライダー - 作成、不要なコライダー - 破壊。 このロジックもすでに作成されており、いくつかの ECS システムで構成されています。 これを使用して、XNUMX つの Unity プロセスで複数のゲーム ルームを保持しました。 また、物理世界はプロセスごとに XNUMX つであるため、部屋間で再利用する必要がありました。 シミュレーションの各ティックの前に、物理世界の状態を「リセット」し、現在のルームのデータで再初期化し、賢いプーリング システムを通じて Unity ゲーム オブジェクトを可能な限り再利用しようとしました。 残っているのは、過去のゲーム状態に対して同じロジックを呼び出すことだけです。

これらすべての要素を組み合わせることで、物理世界の状態を適切な瞬間にロールバックできる「タイムマシン」が完成しました。 コードは単純であることがわかりました。

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

残っているのは、このマシンを使用してショットと能力を簡単に補う方法を見つけることだけでした。

最も単純なケースでは、メカニズムが XNUMX 回のヒットスキャンに基づいている場合、すべてが明確であるように見えます。プレイヤーは射撃する前に、物理世界を望ましい状態にロールバックし、レイキャストを実行し、ヒットまたはミスをカウントする必要があります。世界を初期状態に戻す。

しかし、Dino Squad にはそのようなメカニックはほとんどいません。 ゲーム内のほとんどの武器は発射体、つまりシミュレーション数ティック (場合によっては数十ティック) の間飛行する長寿命の弾丸を作成します。 彼らをどうするか、何時に飛行機に乗るべきか？

В 古代の記事 Half-Life ネットワーク スタックについて、Valve の担当者も同じ質問をしました。その答えは次のとおりでした。発射遅延の補正には問題があり、それは避けたほうがよいです。

私たちにはこのオプションはありませんでした。発射物ベースの武器はゲーム デザインの重要な特徴でした。 そこで、何かを考え出す必要がありました。 ブレーンストーミングを行った後、機能すると思われる XNUMX つのオプションを策定しました。

1. 発射物を、それを作成したプレイヤーの時間に関連付けます。 サーバー シミュレーションのティックごと、すべてのプレーヤーの弾丸ごとに、物理世界をクライアント状態にロールバックし、必要な計算を実行します。 このアプローチにより、サーバー上の負荷を分散し、発射体の飛行時間を予測できるようになりました。 敵の発射物を含むすべての発射物がクライアント上で予測されるため、予測可能性は私たちにとって特に重要でした。

この図では、ティック 30 のプレイヤーは、予測してミサイルを発射します。彼は、敵がどの方向に走っているかを確認し、ミサイルのおおよその速度を知っています。 ローカルでは、33 ティック目にターゲットに到達したことがわかります。 ラグ補正のおかげでサーバー上にも表示されます

2. 最初のオプションと同じようにすべてを行いますが、弾丸シミュレーションの XNUMX ティックを数えた後、停止せず、同じサーバー ティック内で飛行のシミュレーションを継続し、そのたびに時間をサーバーに近づけます。 XNUMX つずつティックしてコライダーの位置を更新します。 次の XNUMX つのいずれかが起こるまでこれを繰り返します。

• 弾丸の有効期限が切れました。 これは、計算が終了し、ミスまたはヒットをカウントできることを意味します。 そしてこれは、ショットが発射されたのと同じティックです。 私たちにとって、これはプラスでもありマイナスでもありました。 プラスの点は、射撃プレイヤーにとって、命中してから敵の体力が減少するまでの遅延が大幅に短縮されたためです。 欠点は、敵がプレイヤーに発砲したときにも同じ効果が観察されたことです。敵は遅いロケット弾を発砲しただけで、ダメージはすでにカウントされているように見えます。
• 弾丸はサーバー時間に達しました。 この場合、シミュレーションは遅延補正なしで次のサーバー ティックで続行されます。 遅い発射体の場合、理論的には、最初のオプションと比較して物理ロールバックの数を減らすことができます。 同時に、シミュレーションに対する不均一な負荷が増加しました。サーバーがアイドル状態であるか、サーバー XNUMX ティックで数個の弾丸に対して XNUMX のシミュレーション ティックを計算していました。

前の図と同じシナリオですが、31 番目のスキームに従って計算されます。 ミサイルは発射と同じティックでサーバー時間に「追いつき」、ヒットは次のティックでカウントされます。 この場合、XNUMX ティック目では、ラグ補正は適用されなくなります。

私たちの実装では、これら XNUMX つのアプローチの違いはわずか数行のコードであったため、両方を作成し、長い間並行して存在していました。 武器の仕組みと弾丸の速度に応じて、恐竜ごとに XNUMX つまたは別のオプションを選択しました。 ここでのターニングポイントとなったのが、「○○時間に何度も敵を攻撃すると○○ボーナスがもらえる」といった仕組みがゲーム内に登場したことだ。 プレイヤーが敵を攻撃する時間が重要な役割を果たすメカニズムは、XNUMX 番目のアプローチでは機能しませんでした。 したがって、最終的に最初のオプションを選択することになり、それがゲーム内のすべての武器とすべてのアクティブな能力に適用されるようになりました。

それとは別に、パフォーマンスの問題を提起する価値があります。 これだけで物事が遅くなるのではないかと思っているなら、私はこう答えます。 Unity は、コライダーの移動やオン/オフの切り替えが非常に遅いです。 Dino Squad では、「最悪の」場合、戦闘中に数百の発射体が同時に存在する可能性があります。 コライダーを移動して各発射体を個別にカウントするのは、手の届かない贅沢です。 したがって、物理的な「ロールバック」の数を最小限に抑えることが絶対に必要でした。 これを行うために、プレーヤーの時間を記録する別のコンポーネントを ECS に作成しました。 ラグ補正を必要とするすべてのエンティティ (発射物、能力など) に追加しました。 このようなエンティティの処理を開始する前に、この時点までにエンティティをクラスタ化して一緒に処理し、クラスタごとに物理世界を XNUMX 回ロールバックします。

この段階では、システムはほぼ動作するようになりました。 若干簡略化した形式のコード:

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

残っているのは詳細を設定することだけです。

1. 時間内での最大移動距離をどの程度制限するかを理解します。

モバイル ネットワークが貧弱な状況でもゲームにできるだけアクセスしやすいようにすることが重要だったので、マージンを 30 ティック (ティック レートは 20 Hz) としてストーリーを制限しました。 これにより、プレイヤーは非常に高い ping でも対戦相手を攻撃することができます。

2. どのオブジェクトを時間内に移動できるか、どのオブジェクトを移動できないかを判断します。

もちろん、私たちは敵を動かしています。 しかし、たとえば、設置可能なエネルギーシールドはそうではありません。 オンラインシューティングでよくあるように、防御力を優先した方が良いと判断しました。 プレイヤーが現在すでにシールドを配置している場合、ラグ補正された過去の弾丸がシールドを通過することはありません。

3. 噛みつきや尻尾攻撃など、恐竜の能力を補う必要があるかどうかを決定します。必要なものを決定し、弾丸と同じルールに従って処理します。

4. ラグ補正が実行されているプレーヤーのコライダーをどうするかを決定します。 良い意味で、プレイヤーの立場は過去に移るべきではありません。プレイヤーは、現在サーバーにいるのと同じ時間で自分自身を見る必要があります。 ただし、射撃プレイヤーのコライダーもロールバックします。これにはいくつかの理由があります。

まず、クラスタリングが改善されます。ping が近いすべてのプレーヤーに同じ物理状態を使用できます。

次に、すべてのレイキャストとオーバーラップでは、アビリティまたは発射物を所有するプレイヤーのコライダーを常に除外します。 Dino Squad では、プレイヤーは恐竜を操作します。恐竜は、シューティングゲームの基準からするとかなり非標準的な形状をしています。 たとえプレイヤーが異常な角度で射撃し、弾丸の軌道がプレイヤーの恐竜コライダーを通過したとしても、弾丸はそれを無視します。

第三に、ラグ補正が開始される前であっても、ECS からのデータを使用して恐竜の武器の位置や能力の適用点を計算します。

その結果、ラグが補正されたプレーヤーのコライダーの実際の位置は私たちにとって重要ではないため、より生産的であると同時により単純な方法を採用しました。

ネットワーク遅延は単純に除去することはできず、マスクすることしかできません。 他の偽装方法と同様、サーバーラグの補償にもトレードオフがあります。 撃たれるプレイヤーを犠牲にして、撃つプレイヤーのゲーム体験を向上させます。 しかし、Dino Squad にとって、ここでの選択は明白でした。

もちろん、プログラマーとゲーム デザイナーの両方にとって、サーバー コード全体の複雑さの増大によって、これらすべての代償も支払わなければなりませんでした。 以前のシミュレーションがシステムの単純な連続呼び出しであった場合、ラグ補正により、入れ子になったループと分岐がシミュレーションに表示されます。 また、操作を便利にするために多大な労力を費やしました。

2019 バージョン (おそらくそれより少し前) では、Unity は独立した物理シーンの完全なサポートを追加しました。 すべての部屋に共通する物理的な世界をすぐに削除したかったため、アップデートのほぼ直後にこれらをサーバーに実装しました。

各ゲーム ルームに独自の物理シーンを与えたため、シミュレーションを計算する前に隣接する部屋のデータからシーンを「クリア」する必要がなくなりました。 まず、生産性が大幅に向上しました。 第 XNUMX に、新しいゲーム要素を追加するときにプログラマーがシーン クリーンアップ コードでエラーを犯した場合に発生する、あらゆる種類のバグを取り除くことが可能になりました。 このようなエラーはデバッグが難しく、多くの場合、ある部屋のシーン内の物理オブジェクトの状態が別の部屋に「流れ込む」という結果になりました。

さらに、物理シーンを物理世界の歴史の保存に使用できるかどうかについていくつかの調査を行いました。 つまり、条件付きで、各部屋に 30 つのシーンではなく XNUMX のシーンを割り当て、それらから循環バッファーを作成し、そこにストーリーを保存します。 一般に、このオプションは機能することが判明しましたが、私たちはそれを実装しませんでした。生産性の大幅な向上は示されませんでしたが、かなり危険な変更が必要でした。 非常に多くのシーンで長時間作業する場合、サーバーがどのように動作するかを予測するのは困難でした。 したがって、私たちは次のルールに従いました。壊れていない場合は修正しないでください'。

出所： habr.com