マルチプレイヤーリアルタイムAndroidゲームの最適なソリューション[終了]

私はAndroid（2-8プレイヤー）向けのマルチプレイヤーリアルタイムゲームを作成する予定で、マルチプレイヤー編成に最適なソリューションは次のとおりです。

1. PCにサーバー、モバイルにクライアントを作成します。すべての通信はサーバーを経由します（ClientA-> PC SERVER-> All Clients）

2. bluetoothを使用します。まだ使用していません。bluetoothでマルチプレーヤーを作成するのが難しいのかわかりません

3. いずれかのデバイスでサーバーを作成し、他のデバイスを接続します（ネットワーク経由ですが、NATを介したデバイスの問題を解決するのが難しいのかどうかはわかりません）

4. 他の解決策？

免責事項; 私はJavaとAndroidプラットフォームではあまり行っていません。

ただし、Windowsモバイルプラットフォームでの「.net」言語とWindowsプラットフォームの私のより広範な経験は、Bluetoothまたはネットワークデータ接続の作成と維持に必要なすべてのコードの75〜90％が維持されていることです。ハードウェアにアクセスする必要があるOSまたはライブラリでサポートされます。

これまでのところ、これはAndroidにも当てはまるようです。OSがBluetoothまたはインターネットを介してデータ接続を作成する方法を公開し、それぞれのハードウェアを有効/無効にします。

Bluetoothが実装のコストが最も低い（サーバーなし）ため、Bluetoothが推奨される接続方法になると思います。そして、よりローカルな集まり/ゲームを可能にします。Bluetoothはかなり簡単に使用できます。接続するデバイスが分かれば、通常のネットワークソケットと同様に機能します。

その他は、Bluetooth v2.0 / v2.1が現在大量のデータロードをサポートできないという点で正しいです。これは、v3.0以降の普及に伴って変化します。この制限を回避する方法があります。

とりあえず、シンプルなコンセプトですが、複雑な解決策があります。私はしばらくそれを使用しています、それはピアツーピアに似ていますが、同時にすべてのデバイスでゲームをホストすることを伴います。これにより、接続が一時的に失われたり、速度が低下したり、何らかの理由でプレーヤーが切断されたりしても、他のプレーヤーは影響を受けません。これにより、ドロップされたユーザーは、他のプレイヤーや自分のゲームをほとんどまたはまったく中断することなく、進行中のゲームに再び参加できます。

CON：各プレーヤーは実際には、ゲームの独自の多少ユニークなインスタンスを再生します。これは、他のプレーヤーとリンクして、ゲームが非常にずれるのを防ぎます。

CON：サポートするコードは広範囲で複雑になる可能性があり、達成したいことによっては頭を一周するのが難しい場合があります。

PRO：中央サーバーやデバイスは不要です！$$$の維持費は必要ありません。

PRO：プレーヤーが（再）参加したとき、またはゲームが初期化されたときにのみ、大量のデータ交換が発生します。-すべてのゲームが確実に生成され、すべてのプレイヤーが同じように進行するようにすることで、これを減らすこともできます。ネットワークの使用量が多いために発生するエネルギー消費を潜在的に削減します。

PRO：他のプレイヤーがいなくてもゲームを続行するために必要なすべてのデータがデバイスにすでにあるため、データの時間依存性が低くなります。許可あなたは、個々のユーザーのために実際のゲームの経験はなく、選手のグループに集中します。

これを利用する完全な詳細なゲームエンジンを実装する時間がありませんでした。私が作成したゲームは、モノポリーと非常にうまく機能しているように思われるUnoに似たゲームの再現に限定されていました。

最も簡単なのは、Unoをエミュレートしたものです。プレーヤーがすべてのゲームに勝ったことを確認するために、プレーヤーが勝った後、私は基本的に敗者のデッキを積み重ねました。95％以上、他の人とまったく同じゲームをプレイしていないとは言えませんでした。

マスターオブオリオンIIに似たゲームの作成を開始しましたが、ゲーム自体は自分でやるのは少しだけでした。

それはゲームに大きく依存しますが、数人前の友人や私も同じ問題について考えていました。私はまた長所と短所の気分です。

コンピュータベースのサーバー

長所

• 試行錯誤した
• スケーラブル

短所

• 同時に複数のゲームをホストできる「マルチサーバー」を作成する必要があります。これはおそらくあなたのAndroid携帯電話とは少し異なる技術を使用します。Javaは引き続き使用できますが、Androidパッケージは引き続き使用できますか？
• 実行と維持に費用がかかる可能性がある
• さまざまな理由により、ある日それを引き下げる可能性があります。ゲームを購入してから数か月後にサーバーがダウンした場合、ファンは満足しないかもしれません。

それらの1つを制御しているピアツーピア

長所

• 友人が必要なときに他の友人に参加できるアドホックサーバー
• ランニングコストがほとんどまたはまったくない
• サーバーコードはクライアントコードと混合されるため、別のサーバーアプリケーションを作成する必要はありません。

短所

• 単純な集中型ピアファインダーを記述する必要があります。（私は数百の簡単な行でphp + mysqlで私のものをしました）
• サーバーは電話で実行されています。電話が遅くなることがあります。すべてのターゲット電話でゲームをホストできますか？
• サーバーの電話が切断されるとどうなりますか？
• ハッカーが侵入するクライアントサーバーよりも簡単

bluetoothについては、上記のピアツーピアの方法に似ていると思います。また、NATに関して問題があるとは思いません。

編集：それはまた、あなたの経験に大きく依存します。最初にネットワークのコツをつかむために、いくつかの比較的小さなクライアント/サーバーゲームを書くことから始めます。はじめて間違えやすい難しいトピックです。私は3回目の試みで私のものを正しく得ました。既知のパターンに従い、自分で何かを作ろうとしないでください。

考慮すべき最大の考慮事項の1つは信頼性です。電話はあまり信頼できません。実際、8プレーヤーのゲームでは、誰かが切断する可能性が高いと想定する必要があります（着信、悪い受信、プレーヤーの終了...）

これを念頭に置いて、切断されたユーザーの影響を最小限に抑える必要があることを理解してください。2番目のオプションでは、電話をサーバーにしました。その電話がMIAになった場合、ゲームは実質的にすべてのプレーヤーに対して終了します。

Johnは、従来のクライアント<->サーバーアーキテクチャの長所と短所をカバーしました。これはおそらく、すべての人に信頼できるマルチプレイヤーエクスペリエンスを提供するための最も回復力のある方法です。

また、ロックステップシミュレーションに沿った手法を検討することもできます。これは、純粋にピアツーピアの方法で実装できます。一般的な考え方は、すべてのクライアントがシミュレーションステップごとに更新（一連のコマンドまたはその欠如）を送信することが期待されているということです。次のシミュレーションステップでは、各プレーヤーのコマンドがゲームロジックに適用されます。多くのRTSゲームは、この種のネットワークスキームを採用しています。

この手法は実装が困難な場合があり、デバッグが非常に困難な場合があります。従来のクライアントサーバーアーキテクチャよりも確かに困難です。また、プレイヤーの入力とゲームが入力に応答するタイミングとの間にずれがあることも意味します。ただし、1人のプレーヤーが脱落した場合、残りのプレーヤーは彼をゲームから除外して続行できます。また、他のスキームと比較して、ネットワークトラフィックが減少する可能性もあります。

このテクニックの詳細を知りたい場合は、このテーマに関する優れた記事から始めてください。それ以外の場合は、1台の電話がマルチプレイヤーセッションを担当するネットワークスキームを強く推奨せず、より単純なクライアント<->サーバーアーキテクチャを提案します。