Pomelaは、node.js用の高速でスケーラブルな分散型ゲームサーバーフレームワークです。オープンソースで、githubからダウンロードできます。 Pomeloは、モバイル、Web、ソーシャルゲームの構築に使用できるゲームサーバーフレームワークです。オンラインのマルチプレイヤーゲームにはこのフレームワークが必要です。
これはシングルプレイヤーゲームのフレームワークではありません。またリアルタイムのアプリケーションサーバーフレームワークのため、数百万人のユーザーをオンラインで保持するチャットのようなWebアプリケーションを開発できます。
Pomeloは単一のプロジェクトではありません。これは、C / cocos2d-x、iOS /アンドロイド、Web / javascript、unity3d、管理コンソールやコマンドラインなどのツールやAI、スケジュール、パス検索、AOIなどのライブラリやプラグインなど、すべてこのフレームワークに基づいて作られています。
これらのプロジェクトはすべてhttps://github.com/NetEase/pomeloで見ることができます
戦闘戦略ゲーム、音声とテキストを使用したモバイルチャットアプリケーションのようなオンラインゲームやリアルタイムアプリケーションの成功例も数多くあります。
なぜゲームサーバーはWebサーバーとしてスケーラブルではないのですか?
理由1:長い接続
ゲームサーバーは、100ミリ秒以内に非常に短い時間でプレーヤーに応答する必要があるため、長い接続が必要です。もう1つは、双方向メッセージフローの必要性です。サーバーに要求するだけでなく、メッセージをクライアントにプッシュバックする必要もあります。この問題は、長い接続を保持し、リアルタイムおよびネットワーク集約型アプリケーションを構築するのに最適なnode.jsの助けを借りて非常に簡単に解決できます。それ以外の場合、Socket.ioを使用している場合、1プロセスで25,000件の接続を保持できます。 Mqtt(マシンツーマシン(M2M)/「インターネットのもの」接続プロトコル)は、1プロセスで最大120,000の接続を保持できます。
理由2:ステートフル
第2の問題は解決するのが難しい。 Webアプリケーションは、ランダムなパーティションに依存するステートレスであり、要求は任意のサーバーにルーティングできます。しかし、ゲームは別の方法で設計されています。ゲームはエリアごとに分割されています。これは、プレーヤーのやりとりの大半が、1つのプロセスで制御できる1つのマップまたはエリアで行われることを意味します。この分割戦略のため、ステートフルな問題があります。クライアントからの要求は、固定サーバにルーティングする必要があり、ランダムサーバにルーティングする必要はありません。
この問題は技術レベルでは解決できません。それはゲームデザインに依存します。ゲームは、領域があまりにも込み入っていないように設計し、ゲーム要素をバランスのとれた方法で配布して、多くのオンラインプレーヤーが対話できるようにする必要があります。あまりにも多くの混雑したエリアでは、プロセスは多くのプレーヤーを保持することができません。
理由3:放送
プレイヤーがゲームエリアで何かを戦ったりすると、すべてのプレイヤーはそのプレイヤーを見る必要があります。そのためには、そのエリア内のすべてのプレイヤーにメッセージをブロードキャストする必要があります。 1人のプレイヤが存在する場合、ブロードキャストされるメッセージの数は2であり、すなわち、メッセージ・イン・アンド・メッセージ・アウトである。その地域に2人のプレイヤーがいる場合、すべてのプレイヤーに通知するために4つのメッセージを送信する必要があります。約4人のプレイヤーがいる場合は、すべてのプレーヤーに通知するためにネットワーク経由で16のメッセージを渡す必要があります。これは、プレイヤーとメッセージの関係が指数関数的であることを意味します。
10人のプレイヤーが100のメッセージを必要とする
100人のプレイヤーに10000件のメッセージが必要
1000人のプレイヤーには1000000件のメッセージが必要
何百万ものメッセージを処理することはできません。一度に1000人のプレーヤーをオンラインでサポートするには?
最初の戦略はAOI(Area of Interest)であり、メインプレーヤーを見て他のプレイヤーに何も送信する必要がないプレーヤーにメッセージをブロードキャストするアルゴリズムです。これにより、多くのネットワーク活動が節約されます。
第2の戦略は、分割されたプロセスと別々の負荷です。ゲームロジックとブロードキャストロジックという1つのプロセス内のすべてのロジックを持っていれば、すべてCPUとサーバーがダウンしてしまいます。したがって、プロセスは2つのロジックブロードキャストとゲームロジックに分割され、それぞれフロントエンド(コネクタ)とバックエンド(エリア)によって制御されます。フロントエンドの部分はステートレスなのでバックエンドのロジックはステートフルなので、何の問題もなく多くのプロセスを処理できるため、これは追加の利点です。
第3の戦略は、リアルタイムアプリケーションのようなpushSchedulerです。つまり、メッセージを直接送信することも、バッファを使用してメッセージの一部を送信して50msごとにフラッシュすることもできます。
理由4:ティック(ゲームループ)
ゲームループは、クライアント側とサーバー側の両方に存在します。それで、100ミリ秒ごとに目を覚ますと、1ダニごとに多くのことを更新しなければならないとします。例えば、プレイヤーが死んでいる場合は、そのプレイヤーをそのエリアから外して消滅させる必要があります。ゲームループが100msの場合、すべての更新プロセスは、はるかに少ないミリ秒か、最大40msかかります。だからこれを解決する方法。
実体番号は限定されるべきです。
アップデートアルゴリズム:AIに注意してください。 AIには時間がかかりません。
ガベージコレクションまたは完全なGCとメモリは、プロセスを分割することによって制限する必要があります。
分散アーキテクチャにより、他のリアルタイムWebフレームワークよりもpomeloのスケーラビリティが向上します。上記のすべての最適化を考慮して構築された堅牢なゲームサーバーです。したがって、他のゲームフレームワークよりもはるかに拡張性があります。