シューターの射撃方法

[ ネットワークシューターの衝突を計算するための原則に関するArmin Ronacherの記事。 それは、技術的な性質というよりも調査と研究に近いものです。 以下、角括弧で翻訳者のメモ ]



今日、私は窓の外を見て、数ヶ月前に文字通り何も理解していなかった非常に複雑なトピックに関する知識を共有したいと思います。 なんで？ まあ、これを理解するのは素晴らしいことだと私には思えます。 そして、このトピックに飛び込む理由を誰かに与えることができます。



それでもなお、すべての研究にもかかわらず、戦場などの非常にダイナミックなゲームのメカニズムを明確に理解するのに十分なほど見つけられなかったため、究極の真実であるという主張を表明しません。 それでも、その多くは掘り下げるのが本当に困難でした。

少しのコンテキスト

Bad Company 2が出てから、そして今、Battlefield 3をリリースした後、私はこのシリーズのために恐ろしい時間を手放したことを認めなければなりません。 そして、役に立たないナンセンスに時間を費やしていることを理解したときはいつでも、少なくともこのナンセンスから将来使用できる何かを得ようとします。



そして、DICE開発者がフォーラム、ツイッター、redditで活発に利用できることは素晴らしいことであり、開発の経緯に関する情報をいつでも得ることができます。 さらに、これらのゲームは非常に人気があり、多くの人が実行可能ファイルを把握して、何がうまくいったのか、何が悪いのかを確認しようとします。



Battlefieldについては、ネットワーク部分がどのように機能するのか疑問に思いました。 主に、このゲームは以前にプレイしたものとはまったく異なる1つのことを行うためです。ここで発射される各弾丸には加速があり、重力の影響を非常に受けます。 もちろん、シェルの概念自体は新しいものではありませんが、非常にまれなゲームでシェルの応答時間補正を導入しようとします。 実際、これを行うバッドカンパニー2とバトルフィールド3以外の単一のゲームを思い出すことはできませんが、これはおそらく、この分野での私の知識の不足に影響されます。

くそ物理学。

問題1は、情報の転送速度です。 もちろん、理論上の限界は光の速度ですが、実際の限界ははるかに低いです。 銅とファイバーを使用して信号を送信しますが、それらの上にはネットワーク機器とおそらく他のものがあります。 そしてもちろん、これはすべて遅延に追加されます。



この状況から抜け出すには3つの方法があります。 1つ目-ゲームは遅延が無視できるほど小さいローカル（ローカル）ネットワークでのみ行われ、2つ目-この問題を単に無視して、プレイヤーが自分の「遅れ」に対処できるようにします。 3番目の解決策は、いくつかのトリッキーなトリックを使用して遅延を補正することです。



もちろん、最近では応答時間が大幅に短縮されていますが、現在は純粋に物理的な限界に近づいており、問題はまだ解決していません。 結局、私たちは以前より孤立していたという事実にもかかわらず、世界中の人々と交流しています。



だから、ゲームが行うことはすべて、プレイヤーに遅れがないと信じさせるトリックだけです。 ほとんどのゲームでは、150ミリ秒の遅延に気付くことすらありません（これは、ゲームで費やした合計時間と比較すると、まったく何もありません）。 おそらく、応答時間が長くなるにつれてパフォーマンスがどのように低下​​するかを感じるでしょうが、ある程度の経験がある場合にのみ、このパフォーマンスの低下をネットワーク遅延に結び付けることができます。

基本

最新のネットワークシューター（原則として）は2つの部分で構成されています。 クライアントとサーバーから。 ホストは、ハードコードされた速度（たとえば、1秒あたり20回のゲーム状況の再カウント）でゲームをシミュレートし、サーバーに変更があったことをすべてのクライアントに通知し、ハードコードされたリフレッシュレートで更新をゲームワールドに送信します。 そして、クライアントは単にこの情報を受け取り、サーバー上で発生するすべてを画面に描画します。



サーバーが1秒間に20回しかゲームの状況をカウントしない場合、最も簡単な解決策はクライアントを同じ20ヘルツにバインドすることです。 まあ、突然何らかの方法でFPSを上げる必要がある場合、通常は補間に頼ります。



サーバーが20ヘルツで実行され、再カウントごとにパケットがクライアントに送信されるとします。 また、クライアントは、着信パッケージごとに3つのフレームをレンダリングする必要があります。 補間のすべては、既存のデータに対してのみ操作できることです。 したがって、クライアントに60ヘルツがあると仮定すると、フレームごとに約16ミリ秒を取得し、クライアントがサーバーの再計算の間に状況を補間する場合、各パケットで補間のための経過時間が48ミリ秒になります。



[私が理解しているように、これは後処理が補間中に発生することを意味します。 パケットが到着し、それに基づいて、すでに通過した3つのフレームが実際に構築されます。 与えられた例では、これらの非常に48ミリ秒の遅れが常にあります。]



理論上の代替方法は、現在の（既知の）ポイントから未来への外挿ですが、これは非常にエラーが発生しやすく、従来の線形内挿よりも開発がはるかに困難です。



これらすべてにより、他のプレイヤーの反復的な動きをモデル化するための優れた基盤があります。 しかし、ローカルのプレーヤーで何をすべきか？ ローカルプレイヤーが移動を開始したい場合は、サーバーに意図を送信し、移動の開始（確認済み）のチームが戻るまで待機してから、実際に移動を開始する前に、非常に大きなラグが発生します。 これに対する解決策は、クライアント側の一種の「予測可能性」です。 コンピュータゲームでは、「推測航法」という用語はしばしばこの概念と呼ばれます。 プレイヤー自身に変化するだけの静的な世界では、クライアントはサーバーを単に無視して自分の動きを計算し、キーが押された瞬間に動きの開始をシミュレートできると言っても安全です。



また、クライアントとサーバーのシミュレーションが一致しなくなった場合、プレイヤーの短いテレポーテーションなどのアーティファクトを受け取ります。 なぜマッチングを停止できるのですか？ 通常、これは、クライアントが単に予測できなかった（サーバー上の）プレーヤーに何かが起こったときに起こります。 たとえば、プレーヤーが別のプレーヤーと衝突する場合があります。 または、彼が運転していない車両の上に立ちます。

タイムマシン。

上記の基本的な方法は、プレイヤーやロケットだけが動的であるQuakeやCounter-Strikeなどのゲームに適しています。 クライアントが何かが間違っていると予測した場合、サーバーはプレーヤーの位置に関する新しい情報を送信し続けるだけです。 また、クライアントがサーバーからのデータが自分の予測から大きく逸脱していることに気付いた場合、彼は単に微調整を行います。



そして、現在のシミュレーションの観点から、サーバーから送られてくるデータが「過去のもの」である場合、ゲームは単に変更をロールバックします。 原則として、サーバーからの最後のいくつかのメッセージをローカルバッファーに保存するため、ゲームは受信データに最も近いメッセージを見つけ、シミュレーションをロールバックし、現在の更新を既に修正された状態に適用するだけです。

当たりましたか？

動きがあれば、すべてがはっきりしますが、これまでのところはまったくありません。 たとえば、Quakeworldでは、プレーヤーの動きの遅れは「予測可能性」のために著しく補償されましたが、プレーヤーは自分で射撃の遅れを補償するために前方に撃たなければなりませんでした。 参照-シューティングゲームに100ミリ秒の遅れがあり、1秒あたり100従来ユニットの速度で移動している別のプレイヤーを撮影したい場合、プレイヤーは移動する前に10従来ユニットの地上のポイントを狙わなければなりません。 うるさい。



あなたが現代のシューティングゲームをプレイする場合-これはもはや問題ではありません。 それでは、どのように機能しますか？ 原則として-ほとんど同じです。 プレーヤーがショットで何かを打ったことを判断するために、クライアントはゴールとプレーヤーの意図をサーバーに送信します。 サーバーは時間差を考慮し、すでに計算された時間の「過去に戻る」と、射手が何かに侵入したかどうかをチェックします。 ヒットすると、ダメージがターゲットに「適用」されます。



ただし、このメソッドには2つのボタンがあります。 まず、この方法は無限に高速な武器（ヒットスキャン）でのみ機能します。この場合、実際には作成されず、時間と空間、実際には弾丸を耕し始めないためです。 2つ目-シューティングゲームの遅延がたとえば200ミリ秒だった場合、このショットを取得するはずだった人は、この200ミリ秒でカバーするために走ることができたはずです。 そして、射手は、いわば未来から過去への射撃という事実のために、走り込んでいたので、射撃時に矢がはっきりと見えていたので、プレイヤーは突然隠蔽のために死にました。



ラグを取り除くことはできず、他の場所に移動することしかできません。 そして、現代のゲームはこのマントラを使用し、シューターにラグの結果をまったく感じない機会を与えることにしました。 しかし、完全に同期されたゲームのこの幻想は、異常なことが起こるとすぐにバラバラになります（異なる「時間」のプレイヤーが一緒に走ったり、誰かがすでに隠れている間に弾丸を手に入れたりするなど）。

実際の弾丸。

バトルフィールドの最初の問題は、弾丸を作成することです。 Quakeなどのゲームでは、約16人のプレイヤーが試合に参加しています。 誰かが弾丸を手に入れたかどうかを確認しようとするたびに、サーバーはすべてのプレイヤーを正しい（クライアント遅延の観点から）位置に戻し、時間を補間し、誰かが弾丸を手に入れたかどうかを監視します。 非常に「マルチブレット」の武器を使用しても、特に少しのチートで複数のブレットを1つのネットワークパケットに詰め込める場合は特に問題はありません。 もちろん、昔ながらのヒットスキャンをシェルと交換するゲームもありましたが、遅延に対する補償を導入せず、シェルを比較的遅くしていました。 そして、これは大きなpingでゲームを非常に複雑にしました。 なんとか、大きなpingを使用して、遠くのサーバーで医療大砲を使用してTeam Fortress 2をプレイしてみてください。 =）を取得する方法を見てみましょう。



ただし、Battlefieldでは、撮影時に実際の弾丸を作成します。 各弾丸の寿命は約1.5秒で、狙撃ライフルから発射された弾丸の場合、最大5秒です。 武器の大部分がアサルトライフルであることを考えると、非常に多くのミスを伴う可能性がある毎分約700発の弾丸を手に入れることができます。 さらに、ここでのカードは非常に大きいため、弾丸のほとんどは、シーンから削除される前に割り当てられた時間全体（そして、これが思い出すように、1.5秒）飛びます。 そして最悪のことは、これらすべてを使用すると、最大64人のプレイヤーと多数の軍事装備に対処する必要があるということです。

これは膨大な数の動的オブジェクトであり、それぞれのステップごとに何かとの衝突をチェックする必要があります。 そして、そのような各チェックで、ゲームはすべてをテストされた各弾丸の適切な時間に戻す必要があり、それはショットの時間として記録されました。 そして、これはシミュレーションのすべてのステップで行われます。 ショットだけでなく。

テクニックと破壊性。

別の大きな戦場問題-破壊可能な環境-は、ゲーム設計の一部です。 ここの建物や装備は、プレイヤーと同じようにダメージを受ける可能性があります。 そして、何かが「撃たれた」かどうかを確認するためにタイムトラベルが必要な場合、プレイヤーだけでなく、戦場からすべての装備とすべての建物を後退させる必要があります。 確かに、[ 建物 ]の破壊についても同じことをすべきではないと思います。破壊によって弾丸に新たな障害が生じることはないからです。 砕石は簡単に撃ち落とすことができ、破壊の結果として新しい障害物が突然発生した場合、この破壊によって引き起こされた煙のために気付かない可能性が高いでしょう。



もう一つは、地球の破壊です。 このゲームでは、地面に穴を開けることができます。 しかし、フィールドに突然現れる実際の穴は、あらゆる種類の予測や補間に非常に破壊的な影響を及ぼします。 Battlefield 3ベータテスト中にマップに陥った兵士についてのレポートを送った多くのプレーヤーを思い出すことができます。リリースゲームで地球の破壊性を大幅に緩和することには驚くべきことはありません。

プロトコルを拡張します。

戦場での64人のプレイヤー、数十の装備、大量の破壊、ミサイル、弾丸、さまざまな方向に発砲する武器、そして悪魔は他に何を知っているか-大量のデータを送信します。 ただし、バトルフィールド3によって生成されたトラフィックを突然見ると、それほど高くないことがわかります。 ここでは、Haloで使用されているネットワークモデルに似たものが使用されていると考えています。これは、Tribesのモデルに基づいています。 Haloは、ネットワーク経由で送信されるすべてのオブジェクトの優先度が異なるなどのことを追加しました。 プレーヤーから遠く離れた位置にあるオブジェクトは、近くのオブジェクトよりも（クライアント上で）更新される頻度がはるかに低くなります。



私のコンピューターでは、64人のプレイヤーがいるサーバーでプレイすると、ゲームは両方向に約16kb / sを転送します。 そして、これはかなりの量です。

Haloのラグドールトリック

戦場には多くの物理的なオブジェクトがあり、それらがすべてネットワーク経由で送信されるとは思いません。 たとえば、ほとんどの場合、ラグドールは、クライアント間の物理の初期同期の段階でのみチャネルを占有しますが、これらは些細なことです。 いずれにせよ、あなたは死体を通して撃つことができるので、最大の問題はもはや問題ではありません。 しかし、別の問題があります-戦場では、倒れた仲間を復活させることができます。

次に例を示します。 一部の人々は、非常に正直に再生のメカニズムを使用していません。 少なくとも以下の真実なら。



一部のサイトからの情報によると（匿名のまま）、再生後のプレーヤーの位置は、再生中のサイトによって制御されます。 一般的に、これは理にかなっています。アニメートされた人は、いずれにせよ、彼の体がどこにあり、彼に何が起こるかを知らないからです。 そして、アニメーターの観点からは、新たにアニメーション化された人が、彼が復活した場所ではなく、他の場所（読んだ-彼が死んだ場所）で突然立ち上がったのを見るのは奇妙です。



しかし、Battlefieldがネットワークを介してラグドールを送信するかどうかにかかわらず、これはゲームデザインがネットワークメッセージにどのように影響し、ネットワークメッセージがゲームデザインにどのように影響するかという特殊で興味深いケースです。 この方法は、Haloで確実にうまく機能します。Haloでは、死体を復活させることができるBattlefieldとは異なり、死体は目的を果たしません。

Battlefield 3での衝突検出

そのため、Battlefield 3には実際の弾丸があり、これらの弾丸は応答時間を正しく補正しました。 自分が何かに夢中になっているのを見ると、本当に夢中になります。 さらに興味深いのは、ヒットがピクセルパーフェクトに非常に近いことです。 最初のショットでも100％の精度が得られないため、確実に言うのは困難です。 しかし、それは非常に近いようです。



問題は、Battlefield 3の衝突検出はサーバーではなくクライアントの責任であるということです。 UT99のZeroPing modとほぼ同じです。 バトルフィールド3のすべての銃によって引き起こされる困難を考えると、これはすべて理にかなっています。 クライアント側の衝突検出の利点は明らかです。安価で、100％正確で、何もしない自動遅延補正です。 ただし、これらの利点には大きな欠点が伴います。 このような再集計は簡単にだまされます。



Alan Curtzによれば、DICEは、「報告された」衝突があるかどうかを明確に答えるサーバーで簡単なチェックを実行することにより、クライアントによる衝突を検出した結果を補正します。 ベータテストの直後に「地図を殺す」ビデオが表示されなくなったので、彼らは本当に何かをしていると思います。 はい、PCの主な問題はエイムボットとESPハックです。したがって、言葉ではなく、実際に深刻なセキュリティ損失があるかどうかはまったくわかりません。



衝突が本物であることをどのように確認できますか？ プレーヤーから分岐する円錐を作成できます。 重力があるため、円錐は理想的な解決策ではありませんが、十分に近いものです。



[明らかに著者は念頭に置いていた-そして、ターゲットがこのコーンに落ちるかどうかを確認する]

独自のネットワークゲームを作成します

ネットワークゲームを作成するために知っておくべきことは何ですか？ これをいじるのに役立ついくつかの便利なものがインターネット上にあります。

- ゲームプログラマーとネットワークゲーム物理学の ためのネットワークに関するGlenn Fiedler ゲーム開発記事

-Gamasutraには、推測航法に関する1997年の記事があります。 彼女は素晴らしい紹介です。

-Fabien SanglardのQuakeエンジンコードレビューは、予測およびネットワークパーツを対象としています。 一般的に、Quakeエンジンは開始するのに最適な場所です。

-Valveの開発者向けWikiは素晴らしい情報リソースです。 遅延、予測、補間の補償に関する記事、およびゲームエンジンのネットワーク部分に関するYahn Bernierの非常に有用な記事などがあります。

-GDCリポジトリで「 最初にあなたを撃った 」のプレゼンテーション

-ベンガーニーによるロバストで効率的なネットワーキングに関するプレゼンテーション。



これが私が見ることができたすべてです。 このトピックに関する多くの文献があると確信していますが、まだ何もお勧めできません。



[ 許可を得て公開された翻訳。 タイプミス、句読点の問題、翻訳の欠陥が見つかった場合は、PMに送信してください 。