MechWarrior Onlineでの武器の遅れの補償

ネットワーク遅延（ラグ）は、マルチプレイヤーゲームで考慮する必要がある現実です。 インターネット経由で送信されたメッセージは、宛先に到達するまでに時間がかかります。 ルートとその長さによっては、これらのメッセージの送信にはかなり時間がかかる場合があります。 これは、特にFPSなどの動的なクライアントサーバーゲームでは、ゲームプロセスに悪影響を与える可能性があります。 非常に単純なタスクのように思える（ターゲットにヒットしようとして撮影する）ことは、すべてのプレイヤーにスムーズなゲームプレイを作成するのを非常に難しくします。 マルチプレイヤーゲームの作成は難しいと言う必要はないと思います。開発者が解決しなければならない多くの問題があります。 この記事では、MechWarrior Onlineの武器システムがラグをどのように処理するかを説明します。



ラグの問題を解決するための戦略の1つは、距離を短くし、プレーヤーとゲームサーバー間のルートを改善して、ラグが目立たなくなるようにすることです。 これは、地域サーバーのシステムを作成し、プレイヤーをより近いサーバーにのみ接続することで実現できます。 または、サーバーへの最適な送信のために、特定のネットワークを通るルートに沿ったゲームトラフィックの送信を保証することが可能です。 残念ながら、この方法はコストが高いため常に使用できるとは限らず、限られたデータ量で使用できます。 ただし、この場合でも、遠隔地にいるプレーヤーやインターネット接続の質が低いプレーヤーには常に機能するとは限りません。 MechWarrior Online（MWO）は同様にこの問題に取り組み、地域の専用サーバーを使用してプレーヤーの遅延を最小限に抑えます。 しかし、これはほとんどのプレーヤーにとって十分ではないことが多く、他のことをする必要があります。

クライアント側の予測

クライアントサーバーマルチプレイヤーゲームの議論で「クライアント側の予測」という表現を聞いたことがあるかもしれません。 これは、特にダイナミックゲームでスムーズなゲームプレイを確保するための重要な概念です。 これがないと、わずかな遅れでも非常に目立って迷惑になります。 クライアント側での予測の考え方は単純です。サーバーがアクションの結果をクライアントに送信するのを待つのではなく、クライアントはこのアクションの結果を、あたかもすぐに起こっているかのように予測します。 たとえば、プレーヤーが前進したい場合、すぐにクライアント側でプレーヤーの移動を開始してから、サーバーに移動要求を送信します。 プレーヤーの観点からは、彼はすぐに移動するように見えますが、実際にはサーバーに対してはまだ移動していません。 ゲームクライアントの予測が常に正しい場合、プレーヤーはこれをラグがないと認識します。 もちろん、予測が常に正しいとは限らず、この問題は何らかの形で解決する必要がありますが、この記事では対処しません。 MWOは、クライアント側の予測に大きく依存しています。 移動と武器システムの両方-プレイヤーが毛皮を動かしたり、武器を撃とうとすると、ゲームはすぐに反応します。

遅れ補償

これで、プレーヤーの行動にすぐに応答し、遅れの感覚を排除するクライアントができました。 ただし、もう1つ問題があります。 プレイヤーのアクションに対する明らかな即時の反応にもかかわらず、ゲームの世界はスローダウンでそれらに反応します。 遅延の可視性を削除しただけですが、サーバーから受信した情報にはまだ遅延が伴います。 つまり、プレーヤーが見る目標は、実際にはサーバーの別の場所にあります。 さらに悪いことに、プレーヤーがターゲットを撃ち、サーバーがシューティングリクエストを受け取ると、ターゲットは元の位置からさらに移動します。 情報を受信して​​サーバーにリクエストを送信するのに必要な時間は、送信および確認、またはpingの時間と呼ばれます。 プレーヤーのレイテンシがゼロでない場合、ラグを補正しないと、プレーヤーはターゲットに到達するためにターゲットを撃たなければなりません。 pingが高いほど、リードはより遠くにあるはずです。 プレイヤーがどれほど迷惑になるか想像できます。 次の画像で状況を説明できます。





遅れているときにプレーヤーに見えるもの





遅れているときにサーバーが見るもの



プレーヤーの観点から見ると、彼はターゲットを完全に攻撃しますが、サーバーはプレーヤーが完全に過去を撃っているのを見ます。 この問題を解決するには、何らかの方法でプレーヤーの遅れを補う必要があります。



今、あなたは質問をすることができます：なぜこの問題を解決するのですか？ クライアントがすべてを予測した場合、クライアントはプレイヤーがターゲットをヒットしたかどうかをサーバーに伝えることができますか？ 最も簡単な答えはイエスです。このオプションは可能です。 ただし、大きな欠陥があります。 ゲームクライアントがサーバーに何かを報告できる場合、不正行為の可能性があります。 コンピューターでプレイする場合、ゲームクライアントは簡単に変更でき、cな詐欺師は、標的から遠く離れていてもまったく見えなくても、詐欺師が望むときにヒットに関するメッセージを送信するようにゲームクライアントを変更します。 したがって、そのような権利をクライアントに譲渡することは、特に敵への損害に関しては、非常に危険な命題です。 マルチプレイヤーゲームが、コンソールなど、ゲームクライアントに何らかの「保護」を提供するプラットフォームを対象としている場合、これは完全に受け入れられるソリューションです。 しかし、PCの世界では、クライアントにゲームの状態を制御できれば、ほぼ確実にクライアントが有利に使用されます。 戦闘でチートする方法はたくさんありますが、この記事ではそれらについても検討しません。 私たちにとって最も安全なソリューションは、サーバーを完全に制御することです。これがMWOで実装されているアプローチです。



MWOには2つのカテゴリの武器があり、各ラグは独自の方法で補正する必要があります。 武器は、直射武器（レーザーや機関銃など）と砲兵武器（ロケットや弾道武器など）に分けられます。 簡単な武器での作業ははるかに簡単なので、始めましょう。

遅延補償付きの直線武器

まっすぐな腕は即座に撃ち、射撃の時点で目標に到達します。 これは、ゲームワールドの現在の状態でラインを再キャストまたはトレースして、武器のインパクトポイントを決定することによって提供されます。 したがって、ラグを補正するには、ラインをトレースする必要があります。 サーバーがターゲットの以前の位置と方向を保存している場合、プレーヤーのpingデータを使用して、プレーヤーのショット時のターゲットの位置を特定できます。 この場所は、下の画像の青い毛皮で示されています。 シューティングプレーヤーの画面の位置に合わせます。 MWOは、この青い毛皮の位置をターゲットの「巻き戻し」位置と呼びます。 サーバーはターゲットの場所を認識したので、ターゲットをこのポイントに戻し、行をトレースしてヒットがあるかどうかを判断し、ターゲットをその開始点に配置します。 したがって、サーバーはゲームクライアントの予測を正確にします。





サーバーがターゲットの「巻き戻し」位置を認識する方法



MWOの場合、以前の位置と方向を維持するだけでは十分ではありません。 ファーの各コンポーネントは個別に損傷を受ける可能性があり、これは非常に重要なゲームメカニックなので、アニメーション状態も必要です。 また、サーバー上で記憶し、「巻き戻す」必要があります。 写真では、「過去」と「現在」の毛皮の動きのサイクルの違いとして見ることができます。 それで、私たちはまっすぐな腕で考え出しました。今、大砲の解決策を見つけましょう。

遅延補償付きの大砲

大砲の動作は、まっすぐな武器の動作とは大きく異なります。 シェルやロケットなどの幾何学的なオブジェクトを撃ち、これらのオブジェクトは空中を移動し、ターゲットと衝突するとダメージを与えます。 この場合、単純な「巻き戻し」は機能しません。 真っ直ぐな腕と同じアプローチを使用し、シェルが無限の速度で移動していると想定した場合、サーバーは、ターゲットが衝突前にすでに外れていたとしても、シェルがターゲットに即座に衝突したと誤って判断する可能性があります。 さらに悪いことに、プレイヤーは、目標に到達するまでに発射体がどこにあるかを計算しているため、積極的に積極的な大砲を撃ちます。 この方法を使用すると、完璧な「巻き戻し」を備えたサーバーに完全な目を持つプレイヤーは常に見逃してしまいます。 別のアプローチが必要です。





ゲームクライアントでの大砲の先制攻撃



サーバー上で発射物を早送りして 、クライアントが予測する位置を決定したいと思います。 クライアントの予測を正確にした場合、ゲームクライアントの遅延を補正します。 これを達成するために、発射体の「ライフ」のサイクルを2つの部分に分けます。



サーバーがシェルによるショットのリクエストを受信するまでに、プレーヤーが送信して確認する時間の半分が経過します。 ただし、サーバーによって処理される発射物は、サーバー世界の他のすべてと一致するためにping秒存在する必要があるため、サーバーはクライアントの送信と確認のためにクライアントの半分の時間である必要があることに注意する必要があります。 この間、発射物はすでにクライアントでターゲットに遭遇する可能性があり、サーバーはこれに応答する必要がありますが、今のところは心配する必要はありません。 発射体の寿命のこの最初の段階を「巻き戻し」期間と呼びましょう。 発射体の寿命のこの最初の部分以降はすべて、サーバーによる発射体のシミュレーションとクライアントによる発射体の動作の予測を同期する必要があるポイントになります。 このコンテキストでの同期は、発射物がクライアントとサーバーの同じポイントにある必要があることを意味しないことに注意することが重要です。 クライアントは、サーバーからの送信と確認のための半分の時間でなければなりません。 したがって、この場合、同期とは、発射物がクライアントとサーバーの両方の世界の他のオブジェクトと同じ場所にあることを意味します。 発射体の寿命のこの段階を同期期間と呼びます。 最初の部分の操作はもう少し複雑なので、2番目の部分から始めましょう。



発射体の物理は単純で、一定の速度で直線的に移動すると仮定します。 この場合、サーバーがショットのリクエストを受信すると、発射物は既にその速度にクライアントがゲームクライアントでpingを掛けたものに等しい距離を通過します。 たとえば、摩擦と重力を考慮して、発射体がより複雑な物理学を持っている場合、より複雑な式を使用して、発射体が移動した距離を計算することも可能です。





サーバー上の発射体の軌跡、上面図



「巻き戻し」期間を無視すると、サーバーは、通常の作成位置から離れた距離に発射体を作成するだけで、クライアントの予測を修正したり、クライアントと同期したりできます。 つまり、サーバーは武器の銃身から発射物を発射せず、代わりにそのパスに沿って適切な距離で発射します。 発射体がより複雑な物理学を持っている場合、サーバーは希望する速度と加速度を計算する必要があるかもしれません。発射体はパス上の対応する点でそれを持たなければなりません。 発射物が決定論的に移動すると仮定すると、クライアントとサーバー間で同期されるパスに沿って移動するはずです。 それは非常に簡単ですが、巻き戻し期間はどうですか？



「巻き戻し」期間の距離でシェルを常に作成した場合、シェルはターゲットまたは静的オブジェクトを通過する可能性があります。 ライントレースを使用して静的オブジェクトの通過を制限するのは非常に簡単ですが、ターゲットの移動はどうですか？ ターゲットが「巻き戻し」期間内にある場合、発射物は、クライアントの予測によると、リクエストがサーバーに到達する前にターゲットとすでに衝突している可能性があります。 これはシェルの本当の問題です-サーバーはクライアントの予測を実装するためにそのような状況を認識できなければなりません。



この問題を解決する1つの方法は、「巻き戻し」と「早送り」の特定のシミュレーションを組み合わせて反復することです。 発射物ショットのリクエストがサーバーに到達すると、ターゲットを「巻き戻し」、発射物を作成し、「巻き戻し」期間中に「早送り」で発射物とターゲットを循環させることができます。 前方の周期的な誤計算中にターゲットと発射物が衝突した場合、ターゲットにダメージを与え、通常は発射物の作成を回避できます。 衝突が検出されない場合、同期期間にシェルを作成できます。



残念ながら、このソリューションには他にもいくつかの問題があります。 1つ目は、各サイクルで衝突を継続的に検出する方法がない高速飛行シェルが、独自のサイクルでターゲットを貫通できることです。 2つ目は、このタイプのソリューションはサーバー上で使用するには非常にコストがかかることです。 反復回数は、巻き戻し期間の長さに関連しています。 そのため、プレイヤーがpingを増やした場合、発射物で各ショットを処理することは、より多くのリソースを消費します。 MWOには多くのシェルがあり、非常に高速で飛行します。 ここでは考慮しないこれらの理由およびその他の理由により、このような解決策は私たちに適していない。



非反復ソリューションを作成するには、まず問題を単純化するいくつかの仮定を立てましょう。 シェルについて次の仮定を行います。シェルはおおよそポイントと見なすことができるため、ライントレースを使用してその軌道を概算できます。 「巻き戻し」期間の軌跡は直線でかなりよく近似されています。 「巻き戻し」期間中、シェルの速度は一定であると想定することもできます。 MWOでは、弾道物理学はシェルに使用されるため、常に直線で移動するわけではありませんが、ベローズに関しては非常に小さく 、 非常に速く移動し、空中を移動するときに速度を低下させないため 、これらの仮定は私たちに適しています。 また、目標の移動に関して推測を行う必要があります。 サーバー上の「巻き戻し」位置と現在位置の間のターゲットの動きは、直線を使用してかなりうまく近似できると想定しています。 また、この期間中のターゲットの速度も一定であると想定しています。 このような仮定は、一部の動的ゲームでは非常に不便な場合がありますが、幸いなことに、MWOでは、メカがゆっくりとスムーズに回転、加速、および減速するため、これらの条件が適しています。



これらの仮定を受け入れて、問題を2つの部分に分けることができます。 最初の部分では、ターゲットとの衝突がまったく可能かどうかを知りたいです。 ターゲットとの衝突が可能な場合、計算を実行して、「巻き戻し」期間中に衝突が発生する時間を決定します。 2番目の部分では、この情報を使用して、変更されたping値で通常の「巻き戻し」直線射撃を実行し、ヒットがあったかどうかを判断します。



ヒットの可能性を確認するために、まず、プレイヤーの現在のpingと「巻き戻し」期間中の発射物の軌跡を表すベクトルに基づいて、「巻き戻された」ターゲットの位置を決定します。 これは、直線的な火を「巻き戻す」ときに行ったことと似ています。 これらの2つのオブジェクトがそれぞれのパスに沿って移動するときに交差するかどうかを調べたいと思います。 先に行った仮定により、この問題を単一の線の追跡に減らすことができ、静止した「巻き戻された」ターゲットに対する発射体の速度が決まります。 これは下の画像で見ることができます。





私たちの仮定を使用して、サーバーは左側の問題を右側の問題に減らすことができます。



この問題の解決策は、前述のオブジェクトを通過する問題の解決策に似ています。 発射体が1サイクルで初期位置から「巻き戻し」期間の終わりまでどのように移動するか想像できます。 開始点と終了点の間のこれらのオブジェクトの移動中の衝突の存在は、衝突検出の継続的なチェックによって実行されます。 このチェックは、通常のライントレースに完全に類似していないことに注意することも重要です。 私たちは意図的に残りの世界を無視し、「巻き戻された」ターゲットと修正された軌道のみを考慮します-これは非常に重要な詳細です。 残りの世界を無視しないと、衝突は不可能であるが、衝突は不可能であると報告する結果を誤って取得する可能性があります。 たとえば、プレーヤーが壁の隣に立っている場合、偽陰性の結果が得られる場合があります。 下の写真で見ることができます。





変更された軌道をチェックするときに、世界のオブジェクトが誤った結果につながる可能性のある状況



このチェックは衝突の可能性についてのみ通知することに注意してください。 衝突が発生することを保証するものではありません。 他の移動オブジェクトまたは静的オブジェクトが邪魔になる場合があります。 そのため、直射武器で行ったのと同様に、元の発射体の軌道に沿って何らかの「巻き戻し」チェックを実行する必要があります。 このチェックの最初の部分が成功すると、これに必要な情報が正確に得られます。 彼女は、衝突が発生したことを報告します。それは、ターゲットの「巻き戻された」位置から現在の位置までのパスに沿った特定の距離でパーセントで発生しました。 発射体とターゲットの両方が1つの時間間隔で移動するため、このパーセンテージは、衝突が発生する修正されたパスに沿ったパーセンテージに等しくなります-「ヒットタイム」と呼ばれることもあります。 ヒット時間を使用して、変更されたpingの値を計算できます。これにより、ターゲットがこの中間位置に「巻き戻されます」。





サーバー上のシェルの状態を巻き戻します。 黒い線は、「巻き戻し」期間中の元の火のベクトルです。 青い線は、衝突検出を継続的に確認するために変更された発射ベクトルです。 黒い毛皮-発射物によって発射されたときの毛皮ターゲットの現在の位置。 青い毛皮-プレイヤーのpingに基づく毛皮ターゲットの「巻き戻された」位置。 黄色の毛皮-「巻き戻し」の最終テストの潜在的な位置



この中央の位置は「巻き戻し」位置です。この位置に対して、直線射撃の「巻き戻し」を確認します。 変更されたping値を使用して直線射撃の定期的な「巻き戻し」チェックを実行し、実際にヒットしたかどうかを判断できます。 命中した場合、ターゲットに適切なダメージを与え、発射物を作成せずに行います。 ヒットがない場合、上記のように、同期期間に発射物を作成します。 上の画像の場合、この状況ではヒットがあります。

おわりに

遅れ補償武器は、MWOや他のマルチプレイヤーゲームが通常遭遇する複雑な問題の一例です。 この記事では、最小の部分のみを示しました。 爆発、トレーサー、遅延のあるプレーヤーとないプレーヤー間の「巻き戻し」がもたらす不整合、およびサーバーがいくつかの目的でこのすべての作業を効率的に実行する方法については説明しませんでした。 武器の遅れを補うだけでなく、クライアントの予測エラー、不正行為、帯域幅管理、サーバーパフォーマンス管理など、マルチプレイヤーゲームで対処しなければならない問題が数多くあります。 これで、マルチプレイヤーゲームの単純な要素のように見えるものを作成するためにどれだけの労力とスキルが費やされたかを理解できます。 この記事が、マルチプレイヤーゲームの開発がどれほど難しいかを明らかにし、次にお気に入りのオンラインゲームをプレイするときに、このすべての作業に感謝することを願っています。