6

現在、リアルタイムのマルチプレイヤー ゲームを開発しており、さまざまなクラウドベースのホスティング ソリューションを評価しています。App Engine が自分のニーズに合っているかどうか確信が持てません。フィードバックをお寄せいただければ幸いです。

要するに、私はシステムが次のように機能することを望んでいます。プレイヤー A はラウンド n を計算し、そのラウンドの最後にゲームの状態からハッシュを生成します。次に、そのラウンドのコマンドとハッシュを http POST としてサーバーに送信します。プレーヤー B も同じことを並行して行います。

サーバーは、プレーヤーからの POST を処理している間、最初に受信したハッシュ コードを memcache に書き込みます。他のプレイヤーからのハッシュがまだ memcache にない場合は、待機し、memcache で他のプレイヤーのハッシュを定期的にチェックします。両方のハッシュが memcache にあるとすぐに、それらが等しいかどうかが比較されます。それらが等しい場合、サーバーは各プレーヤーのコマンドをそれぞれ別のプレーヤーに http 応答として送信します。

このようなラウンドは約 0.5 秒続く必要があります。つまり、1 プレーヤーあたり 1 秒あたり 2 つのリクエストです。

もちろん、この方法は、実行中のアプリケーションのインスタンスが少なくとも 2 つある場合にのみ機能します。これは、2 つの要求を並行して処理する必要があるためです。また、メモリ キャッシュはすべてのインスタンスで一貫性があり、信頼性が高く、すぐに更新される必要があります。

制限されたネットワーク内でゲームを実行できるようにするため、XMPP を使用できません。そのため、ポート 80 の http に制限する必要があります。

アプリの 2 つのインスタンスが常に実行されていることを強制する方法はありますか? デザインに明らかな欠陥はありますか? このようなアーキテクチャは App Engine で機能すると思いますか? そうでない場合、どのクラウドベースのソリューションを提案しますか?

4

1 に答える 1

13

これでうまくいくと思います。学習/テストするための重要な API は、おそらくChannel APIでしょう。これにより、クライアントとサーバー間のやり取りが可能になります。

次に心配する問題は、memcache です。一般的には信頼できますが、厳密には、memcached データはいつでも消える可能性があると想定する必要があります。

そのようなデータを失う危険を冒すことができないと判断した場合は、データストアにデータを永続化する必要があります。つまり、ターンごとに 2 つの移動を維持できることを確認するために実験する必要があります。これは可能だと思いますが、それほど簡単ではありません。3 秒ごとに 1 つの動きと言っていたら、「問題ありません」と言うでしょう。ただし、1 秒あたり 1 つのエンティティに対する複数の更新は、特にトランザクションの場合、1 秒あたりの書き込みの実際の制限にぶつかり始めます。

複数のインスタンスを実行しても問題ありません。必要に応じて、インスタンスをウォーム状態に保つために料金を支払うことができます。

于 2011-02-18T19:14:07.507 に答える