シームレスMMOサーバーアーキテクチャに関する情報


9

シームレスMMOサーバーで何か資料を探しています!「Massively Multiplayer Game Development」の本と「Game Programming Gems 5」にいくつかの記事があります。そのトピックについて誰かが経験したり、それについての記事を知っていますか?

「ハイレベルビュー」と実装に興味があります。これが修士論文のテーマになるかもしれませんが、実際に論文を書き始める前に、そのようなシステムを書くのがいかに難しいかを知りたいと思います。今のところ、どの言語を使用するか決めていません。JavaかScalaを考えています。Erlangを選択することもできますが、私はこれで作業したことがありません。

注:基本的な要件は移動です。他のゲームシステムはオプションであり、「ボーナスクレジット」を提供します。

ここで、「シームレスサーバー」とはどういう意味ですか。静的な境界を使用して、すべてのノードがゲームの世界の一部を制御するサーバークラスターを設定します。プレイヤーは、インスタンスを切り替えたり、「テレポーター」を打ったりすることなく、世界の一端から他の端に移動できるようになりました。WoWがそうだと思います。しかし、私のバックエンドでは、プレイヤーはあるサーバーから次のサーバーに移行します。


しばらく前に、各WoWサーバーには5つ以上のブレード(各大陸とデータベースに1つ)が含まれていることを読みました。かつてはダンジョンやバトルグラウンドとしても使用されていましたが、今ではそれらがレルム間の接続を可能にするために独自のクラスターに存在すると想定しています。要するに、大陸は1つのサーバー上に保持されます。大陸を変更しない限り、別のサーバーに移行する必要はありません。
レニエンシー

興味深いことに、どこで読んだか覚えていますか?私が言ったように、私はWoWをプレーすることはなく、大陸の大きさもわかりませんが、各大陸が1つの別々のサーバーでホストされているとは想像できません。
Lurca、2011

3
WoWサーバーの統計:サーバーブレードの総数は13,250、CPUコアの総数は75,000、112.5テラバイトのRAM(GDC Austin 09現在)。こちらをご覧ください。すべてが必ずしもWoWに専念しているわけではありませんが、かなり十分に近いです。

@ジョシュペトリー:ありがとう、この日の初めにこの記事を見つけました。しかし、私はまだシームレスまたは継続的なサーバーアーキテクチャに関するものを探しています。
ルルカ、2011

回答:


5

このようなシステムを管理する上での主な複雑さは、必要なシステムのシームレスさにあります。ジョシュが言ったように、あるサーバーから別のサーバーにエンティティを引き渡す問題を解決することは、パッケージの重要な部分です。

ただし、これが唯一の問題ではありません。複数のサーバーにまたがるエンティティが1つの操作の一部として相互作用する必要がある場合、同期の問題が発生し、各システムは処理を進めるために反対側からのデータを必要としますが、データが到着するまでに、すでに無効です。これを解決するには、片方がバックアウトした場合にロールバック機能を使用して操作を複数のメッセージに分解しますが、「Massively Multiplayer Game Development」の第3.1章からわかるように、これにより、必要なゲームロジックが大幅に複雑になります。これで。ScalaとErlangは、メッセージングシステムを正しくするのに役立ちます。これらは、10行の関数であったものを、追跡する必要のある多くの異なるメッセージと状態に分解するのに役立ちません。

明らかに、この問題はまったく新しいものではなく、リレーショナルデータベースはすべてのデータを一元的に保存し、複数のクライアントに必要に応じてクエリと変更を許可し、必要に応じてトランザクションをロールバックすることで、この種の問題をサポートします。これにより、正確性の要件のほとんどが得られますが、残念ながら、非現実的なパフォーマンスの問題が発生するだけでなく、ゲームロジックの実装が不便になります(ロジックの多くがデータベースストアドプロシージャで記述されているため)。特に、ほとんどのRDBMSが提供する信頼性要件をトレードオフする場合は、別の種類のデータベースが良い解決策になるかもしれません。

ほとんどのプロのゲームは、この問題を回避するだけでなく、すべてのプレーヤーを1台のサーバーに配置できるようにシャードのサイズを小さくし、世界を実際には相互作用しない部分に分割することで、この問題を回避しています(上記のコメントのWoWの例を参照)。 、または地理ではなく機能に基づいてゲームをサーバー全体に分散させることにより(たとえば、すべての戦闘は1つのサーバーで発生し、すべてのチャットは別のサーバーで発生します)、競合する「継ぎ目」がないようにします。


3

「ハイレベルビュー」と実装に興味があります。

実装は一般にかなり深く関与しており、おそらくここではそれらについてあまり話をしません。StackExchangeソフトウェアは、この種の複雑なディスカッションには適していません。言うまでもなく、誰かの時間を大幅に投資する必要があります。

そのようなシステムを書くのがどれほど難しいか知りたい

他のどのシステムよりも難しいことではありません。それは、要件やドライブする機能に依存します。ささいな実装を簡単に書くことができますが、ささいなことはもちろんはるかに難しくなります。より大きな問題の1つは、システムが実際に「大規模」レベルにスケーリングされているかどうかを判断するのに十分な実際のクライアントがおそらくないことです WoWおよび他のゲームが動作する。

MMOは魔法ではありません。彼らの技術のほとんどは、分離して特別なものではありません。単に、いくつかの小さくて単純な技術のビットが非常にインテリジェントに組み合わされて、共有された世界の状態の大規模な接続された並列シミュレーションを可能にします。

すべてのノードが静的な境界でゲームの世界の一部を制御するサーバークラスターを設定したいと思います。プレイヤーは、インスタンスを切り替えたり、「テレポーター」を打ったりすることなく、世界の一端から他の端に移動できるようになりました。

基本的にあなたが話しているのはシミュレーションのハンドオフです。これは非常に簡単に行うことができ、必ずしもMMO固有のテクノロジではありません(ピアツーピアゲームは、ホストの移行を実装するために同じ基本的なメカニズムをすべてサポートする傾向があります)。基本的な前提は、各サーバーに「その周りの」サーバーのトポロジー(具体的には、ワールドノードAのサーバーはシミュレーションに隣接するワールドノードのサーバーについて知っている必要がある)を理解することと、検討するバッファーを定義することです。隣接するサーバーに「近い」特定のシミュレートされたエンティティ。

エンティティが「クローズ」バッファに入ると、隣接するサーバーにもレポートを開始します。エンティティが実際のしきい値を超えると、エンティティの完全な状態と隣接サーバーがエンティティを引き継ぐことを示すメッセージを含むメッセージを隣接サーバーに送信します。もちろん、これは可能な限り信頼できるものにしたいでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.