説明が長くなってしまうことを前もってお詫びします。これはほとんどすべてが関連していると思うので、もっと簡潔にする方法がわかりません。ごめん！
Twisted を使用して Python でゲーム サーバーを設計しています (これはアーキテクチャの問題であるため、おそらく関係ありません)。
一般的な考え方は、プレイヤーが接続してロビーに配置されるというものです。その後、試合 (たとえば、デスマッチやチーム デスマッチ) のキューに入れることができ、試合が見つかると、そのゲームに配置されます。ゲームが終了すると、それらはロビーに戻されます。
分散システムがいかに複雑であるかを認識しているので、可能な限り単純化しようとしました。私が思いついたアイデアは、プレイヤーに関するすべての情報をオブジェクトに抽象化することでした。すべてのゲーム ロジックは GameHandler に実装されます。プレイヤーが接続すると、Lobby(GameHandler) インスタンスに割り当てられます。彼らが試合に参加すると、たとえば Deathmatch(GameHandler) インスタンス (サーバーのマップ: gamehandler に保持される) に再割り当てされます。
その時点で、プレイヤーが試合に追加されると、プレイヤーが実際に接続しているサーバーがリバース プロキシとして機能します (私はクライアントを作成していないため、変更することはできません。 -negotiation) を実行し、プレイヤーに関する情報をマッチ サーバーに送信します。次に、インスタンス マップを使用して、そのプレーヤーからのすべてのトラフィックは、そのプレーヤーがいるゲーム インスタンスを参照せずにルーティングされます。ID システムを使用すると、その逆も同様です。サーバーはすべてギガビット LAN でデータを転送できるはずなので、これは問題ではないと思います。
ゲームが終了すると、プレイヤーを転送したすべての Lobby サーバー (リバース プロキシ) に通知するだけで、プレイヤーは Lobby インスタンスに戻されます。
つまり、バックエンド サーバーを追加してリソースをスケールアウトしたり、リバース プロキシ ロビー専用サーバーを追加してネットワーク リンクをスケールアウトしたり、個々のノードをスケールアップしたりできます。また、バックエンド サーバーをバックエンドにすることを強制する技術的な制限もありません。すべてのサーバーが Lobby インスタンスを持つことができますが、ゲームはネットワーク全体に分散できます。
さて、ここまでは順調です (理論的には、主要なポイントを事前に解決したいので、まだディストリビューションの実装を開始していません) が、1 つの大きな疑問が残ります。
すべてのノードが知る必要があるメタ情報を制御するにはどうすればよいですか?
例えば：
- クライアントが接続する前に、サーバー リストを表示するためにオンラインになっているプレイヤーの数は?
- マッチメイキングは P2P 方式で実装されていますか (問題があれば、Microsoft の TrueSkill アルゴリズムを使用する予定です)、それともそのためだけに (またはメタ情報のために) サーバー全体を委任する必要がありますか?
- プレイヤーが一緒にキューに参加するパーティー システムはどうですか? グループ内のプレイヤーを追跡するサーバーはどれですか?
- 禁止されたプレーヤーなど、構成を管理するにはどうすればよいですか? すべての転送サーバーは、それらについて知る必要があります。
- プレーヤーが接続しているロビー インスタンスがたまたま満杯だった場合、満杯ではない別のロビー インスタンスを見つけてそこに接続できるようにするにはどうすればよいですか? これは最初のポイントに戻ります。ノードがネットワーク状態を簡単に照会できる方法が必要です。
P2P ソリューション、またはこの種のことを処理するためのプライマリ サーバーを実装できます。私の主な懸念は、プライマリ コントロール サーバーを追加すると単一障害点が追加されることです (これは避けたいと思います)。すべてのノードでデータをキャッシュするかなりの量のリソース。
質問は次のとおりです。私の設計はまともですか?メタ情報の問題に対するこれら 2 つの解決策の長所と短所は何だと思いますか? より良い第 3 の解決策はありますか? 何が一番いいと思いますか?
よろしくお願いします。