ネットワークゲームでの遅延への対処

Question

ネットワークゲームを作ろうと考えています。私はこれについては少し初心者で、推測航法とネットワーク遅延に関する適切な計画をまとめる際にすでに多くの問題に遭遇しているため、このトピックに関する優れた文献をぜひ参照したいと思っています。私が考えた方法を記載します。

当初は、プレイヤーの入力をサーバーに送信し、そこでシミュレートし、ゲーム状態の変化をすべてのプレイヤーにブロードキャストするだけでした。これにより不正行為が困難になりましたが、自分のアクションの結果がすぐに表示されないため、遅延が大きい場合は制御が少し難しくなりました。

このガーマスートラの記事 には、帯域幅を節約し、クライアント上でもシミュレートすることでローカル入力がスムーズに見えるようにするソリューションがありますが、チート防止機能を無視しているようです。また、プレイヤーが岩などを押して環境を操作し始めたとき、何をすればよいのかわかりません。これらの以前は中立だったオブジェクトは、クライアントが PDU を送信する必要があるオブジェクト、またはおそらく複数のプレーヤーが一度に送信する必要のあるオブジェクトになることがあります。誰の PDU が勝つでしょうか?(推測バージョンと比較するために) 各プレイヤーによるオブジェクトの二重追跡はいつ停止されますか?天は二人のプレイヤーが相撲を取ることを禁じている（例：お互いに押し合い始めます）。

この gamedev.net ビット は、ガマスートラの解決策が不十分であることを示していますが、協力して岩を押す例を実際には修正しない別の方法を説明しています。私が見つけた他のほとんどのものは、シューティングゲームに特有のものです。SNES ゼルダのようなゲームに特化したもので、もう少し物理や運動量が関与するものを見てみたいと思っています。

• 注記：ここでは物理シミュレーションについて質問しているわけではありません。他のライブラリでそれがカバーされています。ネットワーク遅延にもかかわらず、ゲームをスムーズかつ反応性の高いものにするための戦略です。

Answer 1

Valve がソース エンジンでどのように実行するかを確認してください。 http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

一人称視点のシューティングゲームの場合は、おそらく次のような言及されているトピックのいくつかを詳しく調べる必要があります。予測、補償、補間。

Answer 2

見つけました このネットワーク物理学のブログ投稿 Glenn Fiedler 著、そしてさらにその下にある応答/ディスカッションは素晴らしいです。かなり長いですが、それだけの価値はあります。

要約すれば

最新のゲーム物理シミュレーション (すなわち、車両または剛体ダイナミクス)。したがって、サーバーは、サーバーが必要とする前にすべての受信パケットが JIT で到着するように、すべてのクライアントのレイテンシ + ジッター (時間) をサーバーよりも先に命令します。

また、あなたが求めている所有権の種類に対処する方法の概要も説明します。彼が GDC で見せたスライドは素晴らしいです。

浮気について

フィードラー氏自身（および他の人）は、このアルゴリズムはチート耐性があまり高くないことに悩まされていると述べています。本当じゃない。このアルゴリズムは、従来のクライアント/サーバー予測と比べて悪用が簡単でも困難でもありません (従来のクライアント/サーバー予測に関する記事を参照) @CDサンチェスの答え).

絶対に明確にしておきます:サーバーは、（従来の予測のように x ミリ秒遅れてではなく）ジャストインタイムでネットワークの物理的位置を受信するという理由だけで、不正行為が容易ではありません。クライアントはすべて、従来の予測とまったく同じ遅延で対戦相手の位置情報を受信するため、まったく影響を受けません。

どのアルゴリズムを選択しても、メジャーなタイトルをリリースする場合は、チート保護を追加することをお勧めします。もしそうであれば、暗号化を追加することをお勧めします 手先ボット （例えば XOR ストリーム暗号 ここで、「キーストリームは擬似乱数ジェネレーターによって生成されます」) と、クラックに対する単純な健全性チェックが行われます。一部の開発者は、バイナリが完全であることを確認する (クラックのリスクを軽減するため)、またはユーザーがデバッガを実行していないことを確認する (クラックが開発されるリスクを軽減するため) アルゴリズムを実装していますが、これらについては議論の余地があります。

数千人のプレイヤーだけがプレイする小規模なインディー ゲームを作成しているだけの場合は、1) 必要になるまで、チート対策アルゴリズムを実装する必要はありません。または 2) ユーザーベースが拡大する。

Answer 3

必須のサーバーと予測を行うリモート プレーヤーに基づいたマルチプレイヤー ヘビ ゲームを実装しました。(ほとんどの場合) 150 ミリ秒ごとに、サーバーは各リモート プレーヤーから送信されたすべての統合された動きを含むメッセージを送り返します。リモート クライアントの移動がサーバーに遅れて到着した場合、サーバーはそれらを破棄します。クライアントは最後の動きを再生します。

Answer 4

XNA Creator's Club Web サイトでネットワーク教育のトピックを確認してください。ネットワーク アーキテクチャ (ピアツーピアまたはクライアント/サーバー)、ネットワーク予測、およびその他のいくつかのトピック (もちろん XNA のコンテキストで) について詳しく説明します。これは、探している答えを見つけるのに役立つ場合があります。

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

Answer 5

エリア内の平均レイテンシに応じて、すべてのクライアントにレイテンシを課すことを試みることができます。そうすることで、クライアントはレイテンシの問題を回避することができ、ほとんどのプレイヤーにとって同様の操作感を得ることができます。

もちろん、全員に 500 ミリ秒の遅延を強制することを提案しているわけではありませんが、50 ミリ秒の人は、ゲームプレイをよりスムーズに見せるために、150 ミリ秒 (さらに 100 ミリ秒を追加) で問題ありません。

一言で言えば;プレイヤーが 3 人の場合:

• ジョン:30ミリ秒
• ポール:150ミリ秒
• エイミー:80ミリ秒

計算後、データをクライアントに同時に送信するのではなく、クライアントの待ち時間を考慮して、たとえば、ジョンより先にポールとエイミーに送信を開始します。

しかし、このアプローチは、ダイヤルアップ接続やワイヤレス ユーザーが全員に混乱をもたらす可能性がある極端な遅延状況では実行できません。しかし、それはアイデアです。