1

私は、一度に4人のプレイヤーがプレイできるトランプ (正確にはBridge ) に基づく Android ゲームに取り組んでいます。また、デバイスが接続される Web 経由で利用可能なサーバーがあり、サーバーはゲームの進行状況を追跡します。

私のゲームは、ゲーム エンジンを使用せずに UI を実現できるグラフィックに関しては非常に基本的なものです。

私は Android 用のゲーム (クライアント) をビルドすることになっていますが、他のモバイル プラットフォームやデスクトップに移植されたとしても、ゲームの将来の移植で再利用できるサーバーを開発したいと考えていました。

そこで、クライアントのプログラミング側が HTTP メソッドをサポートしている限り、どのクライアントでもサーバーを活用できるように、サーバー アーキテクチャの最初の候補としてRESTful Web サービスを用意することを考えました。

しかし、後で、ゲームセッション全体でデバイスとサーバーの間に永続的な接続が存在するため、リクエストが応答された後に接続が終了するようなサーバーを使用しても問題ないことに気付きました（真実）？

または、Java の方法を使用DatagramSocketしDatagramPacketてサーバーを構築しますか? （それはサーバーの再利用性を保証しますか？）

他の提案や推奨事項はありますか？

注: Java や Java でのネットワーク プログラミングは初めてではありませんが、Android 開発と RESTful サービスの作成は初めてです。

4

2 に答える 2

3

Android 向けに作成している間は、永続的な接続を計画しないでください。接続は非常に頻繁に切断されます (GSM から Wi-Fi に切り替えるなど、正当な理由があることがよくあります)。HTTP は優れた、人気があり、実証済みの選択肢です (スタックの下位レベルを邪魔することなく、ペイロードの処理に集中できます)。

ところで: このコンテキストで「RESTful Web サービス」と言うのは無意味です。必要なのは、ゲーム ロジックを一連のステートフル リソースとして構築するためのメンタル フレームワークではなく、データを提供してコマンドを受け入れる HTTP サーバーです。

于 2012-05-29T12:59:46.960 に答える
1

あなたのHTTPベースの計画はこの状況に適していると思います。接続の持続性の問題は、ブリッジのようなゆっくりと曲がるベースのゲームには関係ないと思います。

編集：tdregerが提案しているように、ほとんどすべてのAndroidドキュメントでは、HTML接続が最も回復力のあるソリューションであると思われるため、定期的な接続の失敗と別のチャネルを介した再確立を計画することをお勧めします。

クライアント側から独立させるというあなたの考えは正しく重要だと思います-この観点から、HTTPの考えは、他の言語（おそらくあなたが望むでしょう-Javascript）でクライアント側アプリケーションをコーディングするのがはるかに簡単になるという点で明らかにはるかに優れていますWebクライアントの場合はobjective-C、iOSアプリの場合はobjective-C）。

また、AndroidとappacheはこれらのHTTPのような接続を強力にサポートしているため、Androidの開発はより簡単になると思います。

于 2012-05-29T12:52:10.633 に答える