相互に通信する必要がある複数のゲームサーバーに最適なアーキテクチャは何ですか？

Question

ゲームは、低グラフィック（SVG）戦略ゲームです。 各サーバーは、プレーヤーを持つゲームドメインを表します。 プレーヤーは（ゲーム内で）ドメインからドメインに移動したり、「外交メッセンジャー」を送信したりできるため、すべてのサーバーが相互に通信できる必要があります。など。

このアイデアを選んだのは、世界地図を際限なく拡大することができ、サードパーティが自分のゲームサーバーに接続して、世界をさらに拡大できるからです。 1つのサーバー（およびそのバックアップ）に障害が発生しても、ゲームは引き続き実行されます（実際の分散環境）。

私たちはまだ始まったばかりです。このような世界を発展させるのに役立つプラットフォームを教えてください。

Answer 1

XMPP（以前はJabberとして知られていました）は、開始するのに適した場所です。

Answer 2

これの多くは、サーバー間で共有するデータの量に依存します。各サーバーで独自のドメインを処理する必要がありますが、アカウントデータベースについてはどうですか、誰がどの情報を所有しているかについてのデータ、ドメインのトポグラフィーは、これらのデータが中央および/または分散され、それらをどのように同期させますか？そのため、ゲームの仕組みとは別に、サーバーが通信する必要があるメタデータの別のセットがあります。ゲームデータについては、おそらくイベント、データオブジェクト、およびデータの所有権と制御に関する情報を渡すでしょう。さらに、ドメインの時刻を同期させるために、ゲーム内のクロックメタデータが必要です。

おそらく、メタデータ、要求、応答メッセージの優先順位が異なる非同期キューのシステムを使用します。メッセージの交換に加えてXMPPのようなプロトコルを使用すると、プレゼンス情報、認証、暗号化などの利点が得られます。しかし、最初は、配信プロトコル自体は、メッセージの構造やデータの交換ほど重要ではありません。基本的に、配信プロトコルは交換可能です。

例： 1人のプレイヤーがドメインAからドメインBにゲームユニットXを送信します。ドメインAサーバーはイベント付きのメッセージをドメインBサーバーに送信します。イベントのキューの処理中、Bはメッセージを受信し、ユニットXに関するデータとユニットXのデータを制御/変更する許可を求めるリクエストをAのリクエストキューに送信します。リクエストキューは優先度が高く、ドメインAの他のイベントの前に処理されます。ドメインAは、要求されたデータと制御トークンを最高の優先度でドメインB応答キューに送信します。一方、ドメインBサーバーは、セッションで待機していない3つの他のイベントを既に処理しています。

• 注： Aは、この時点でユニットXに関するデータを廃止、バージョン化、または削除する必要があります。ドメインCからデータを要求する場合、今後この要求をサーバーBに転送する必要があります。
• 注：上記の例は、ユニットXに関するデータを対応するイベントとともに直接送信するように最適化できますが、説明のために簡単な例が必要でした。

重要なことは、データカプセル化プロトコル、おそらくXMLスキーマを設計する必要があることです。イベント処理のプロトコル。イベント、許可された応答、エラーメッセージ、回復のリスト。これらはすべてゲーム固有です。

Answer 3

ErlangとCouchDBを真剣に検討するか、Google AppEngineの下に実装します。

Answer 4

真に分散されている場合、中央サーバーの計画はないと推測しています。つまり、あなたが本当に探しているのは、さまざまなサーバー間の通信メカニズムです。 RESTとXML-RPCはどちらも、サーバーが相互に通信してユーザーが相互に移動する必要があることを通信するための非常にシンプルなメカニズムです。

Danielおそらく何らかの種類のWebアプリサーバー）。

開発の観点から、Webアプリの開発に強い言語/フレームワークはすべて機能するはずです。 Ruby on Rails、Python on Django、多数のフレームワークとJava、またはCake w / PHP（ick）でも開発作業に使用できます。

過去にこのようなことを検討していましたが、さまざまなサーバーの検査の問題（つまり、壊れているか悪意のあるサーバーをどのように処理し、プレイヤーが同時に同じピースを他の2つまたは3つのサーバーに移動できるか） ）、ドロップアウトしたサーバー（最後にそこに存在したプレイヤーに何が起こるか）などの処理は、非常に難しいように見えました。

Answer 5

最初に答える質問は、ゲームがリアルタイムであるかイベント駆動であるか、そしてクライアントがブラウザであるかどうかです。イベントドリブンのように聞こえますが、サーバーは結果をプレーンHTMLクライアントに効果的にプッシュできず、Javaアプレット、埋め込みFlashムービーなどにしかプッシュできないことに注意してください。カスタムクライアントがある場合は、HTTPを使用する必要はありませんサーバー上の-styleシステム、つまりサーバー-＆gt;サーバーとサーバー-＆gt;クライアントの通信は同じ方法で実行できます。

Answer 6

「金利管理」をご覧ください。 P2Pゲームに関する論文では、本当に興味深いアプローチに直面します。 Google Schoolarは本当に良い論文を提示します。

ただし、分散アプリケーションの開発は、単純な単一サーバーのアプローチよりもはるかに複雑です。