最高のピアツーピアゲームアーキテクチャ


10

ゲームクライアントが次のような設定を検討します。

  1. コンピューティングリソースが非常に小さい(モバイルデバイス、スマートフォン)
  2. すべてが共通のルーター(LAN、ホットスポットなど)に接続されている

ユーザーは、外部サーバーなしでマルチプレイヤーゲームをプレイしたいと考えています。

1つの解決策は、1台の電話で信頼できるサーバーをホストすることです。この場合、このサーバーもクライアントになります。ポイント1を考慮すると、電話のコンピューティングリソースが十分でないため、このソリューションは受け入れられません。

そのため、ゲームのシミュレーション負荷をクライアント間で分散するピアツーピアアーキテクチャを設計したいと考えています。ポイント2のため、システムは最適化に関して複雑である必要はありません。レイテンシーは非常に低くなります。各クライアントは、自分自身と彼の直接の環境に関するデータの信頼できるソース(たとえば、弾丸)になることができます。

そのようなアーキテクチャを設計するための最良のアプローチは何でしょうか?そのようなLANレベルのピアツーピアプロトコルの既知の例はありますか?

ノート:

ここではいくつかの問題に対処していますが、そこにリストされている概念は、私には高レベルです。

安全保障

信頼できるサーバーが1つもないことはセキュリティの問題であることはわかっていますが、この場合はクライアントを信頼してもかまいません。

編集:

私は言及するのを忘れていました:かなりテンポの速いゲーム(シューティングゲーム)になります。

また、私はGaffer on Gamesでネットワーキングアーキテクチャについてすでに読みました

回答:


10

見てみましょう。この記事エイジオブエンパイアIIのネットワークアーキテクチャについてを。

彼らは、16 MBのRAMと28.8 kB / sのモデム接続を備えたPentium 90で優れたマルチプレイヤーゲームを作成することに成功しました。彼らは、各プレイヤーに独自のシミュレーションを実行させることでこれを行いましたが、コマンドを同期させました。

彼らはそこにいくつかの巧妙なトリックを持っています、私はそれを強くお勧めします。


5

私は、アドホックネットワークとワイヤレスホットスポットの両方で機能する商用PSPレーシングゲームでこれを行いました。(または、必要に応じて、インターネット上の静的サーバーに)

ポイント2のため、システムは最適化に関して複雑である必要はありません

私の経験では、これは正しくありません。ワイヤレスデバイス(特に小型のポータブルデバイス)は、有線ネットワーク接続を備えたコンピューターのようなものではありません。スマートフォンやワイヤレスゲームコンソールは、ゲームの目的で低速のネットワークインターフェイスを持つ傾向があります。

誤解しないでください。それらのスループットは通常良好です(つまり、1秒あたりのデータ量です。映画のストリーミングなどに最適です)。特定のパケットの配信のレイテンシは非常に悪くなる可能性があります。非常に変動しやすいため、個々のパケットが配信されるまでにかかる時間を推定することも困難です。信号が互いに干渉し始めるため、より多くのワイヤレスデバイスが1つの一般的な領域にまとめられているため、この変動はさらに悪化します。この結果、送信する必要があるパケットの数を減らすためにかなりの時間を費やしたので、パケットの衝突が少なくなります。(これは、デバイスがアドホックネットワークを介して直接互いに通信するのではなく、受電ネットワークのホットスポットが関係している場合の問題の多少は少ないことに注意してください)

この種の最適化の例として、私たちのレースゲームは信号機のある世界で行われました。それらの何千もの。また、ネットワークセッションのすべてのプレーヤー間で信号が同期していることを確認する必要がありました。どのライトがどの状態にあるかを知らせるためにパケットを送信するのではなく、すべての信号機に静的なスケジュールを定義し、すべてのクライアントが現在の「ゲーム時間」に同意するようにしました。彼らはすべてゲーム時間を知っており、すべての信号機の状態はゲーム時間から判断できるため、実際に特別なデータを送信することなく、すべての状態データを同期しました。この1つの変更により、ネットワークパフォーマンスに大きな違いが生じました。

とはいえ、複数のワイヤレスデバイス間で信頼できるクロック同期を確立することは(パケット損失が原因でping時間が大きく変動するため)、大きな課題でした。あなたが興味を持っているなら、それについてもっと話して幸せです。

各クライアントは、自分自身と彼の直接の環境に関するデータの信頼できるソース(たとえば、弾丸)になることができます。

これは私たちがやったことであり、私たちの状況(車)でうまく機能しました。もちろん、問題のある部分は、オブジェクトがプレーヤー「b」よりもプレーヤー「a」に近づかなくなったときであり、そのため、その所有権は1つのプレーヤーから別のプレーヤーに移ります。

これは実際にはプレーヤー間の驚くほど複雑な交渉であり、ゲーム 'a'がゲーム 'b'に提案します。そして、ゲーム 'b'は、状況に対する独自の見解に基づいて、受け入れるか、または拒否することができます。「a」と「b」の間の知覚されたゲーム状態の違い、および要求と応答が送信されてから受信されるまでの時間の変化により、これは信頼性を得るために特に厄介な小さな交渉になり、簡単にゲームに変質する可能性があります「ホットポテト」。オブジェクトの所有権が複数のプレイヤー間で絶えず跳ね回ります。そして、ちゃんと動いても、ゲーム「c」の視点から見ると

私の直感は、この種の「オブジェクトの所有権」アプローチは、弾丸のような小さくて寿命の短いオブジェクトには扱いにくい可能性が高いということです。比較的長い間シミュレーションに住んでいたトラフィックカーやAIレーサーに使用しました。クライアントを信頼してもかまわない場合は、よりパフォーマンスの高いアプローチのように思われます。各プレーヤーのゲームに自分の位置と発射物を所有させ、そのプレーヤーが他の誰かの発射物に当たったときに宣言することになります。(「ゲームA」と同様に、私はプレーヤーAとプレーヤーAの発射物がどこにあるかを言う責任がありますが、プレーヤーBは私がプレーヤーBをヒットしたかどうかを言う責任があります)。優れた推測航法を使用すると、このようなシステムからかなり合理的な動作を得ることができるはずです。


1

ロックステップのピアツーピアアーキテクチャを使用することをお勧めします。

まず、ゲームの開始後にゲームフレームをカウントします。1つのクライアントが最初のフレームをレンダリングしてから、準備完了メッセージを他のクライアントに送信し、他のクライアントからの準備完了メッセージの受信を待ちます。

これで、すべてのクライアントが2番目のフレームに進むことができます。フレームをレンダリングし、コマンドを送受信し、世界を更新し、物理を更新し、その後、互いに準備ができたメッセージを送信します。

このソリューションはLANゲームに非常に適しており、すべてのクライアントが同期します。

このタイプのネットワーキングを使用すると、すべてのクライアントが同期していることを確認できるため、ニーズに合った最良の方法をテストできます。

1つ目の方法は、他のクライアントに入力を送信するだけで、各クライアントは、実行、発砲、衝突検出などをシミュレートします。2つ目の方法は、位置、回転、状態、アニメーションフレームなどのように、各クライアントが自分のキャラクターに関する情報を他のクライアントに送信するため、他のクライアントのみです。それらを計算してネットワーク経由で送信しますが、最初の方法の方が安全です。


1
この答えはゲームループに関するもののようです。OPが負荷分散システムについて尋ねていると思います。具体的には、クライアントが何をどのように通信するかをシミュレートします。もう少し詳しく説明してもらえますか?私もこの問題に興味があります。
Wackidev

このタイプのネットワーキングで@Wackidevを使用すると、すべてのクライアントが同期していることを確認できるため、ニーズに合った最良の方法をテストできます。1つ目の方法は、他のクライアントに入力を送信するだけで、各クライアントは、実行、発砲、衝突検出などをシミュレートします。2つ目の方法は、位置、回転、状態、アニメーションフレームなどのように、各クライアントが自分のキャラクターに関する情報を他のクライアントに送信するため、他のクライアントのみです。それらを計算してネットワーク経由で送信しますが、最初の方法の方が安全です。
kochol

だから、あなたの答えにそれを入れてください。今のところ、この質問に対する答えはないと思います。また、最初の重複するコメントを削除してください。ありがとう。アイデア自体に関して、あなたがリストした最初のオプションはシミュレーションが確定的であることを要求しませんか?
Wackidev
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.