最終的なWebベースのゲームのエンジンは、Webサービスとして開始する必要がありますか？

私は最近、カードゲーム用のエンジンを書き始めることにしました。私は大規模な「カード」プレイヤーではありませんが、友人がゲームを紹介してくれました（デンマーク語のゲームのスピンです）。

ゲームを3つのセグメントで開発したいと思います。

1. 基本的なエンジン、カード/デッキ/ゲーム状態などを処理します
2. ユーザーインターフェイス（モバイル/デスクトップWebアプリの形式）
3. さまざまな戦略/困難などを伴う人工知能

これらは私の心の中で非常に異なるプロジェクトです...そして私はそれらがすべて長期的にどのように組み合わさるかを見るのに苦労しています。最初は、エンジンを使用してゲームを「プレイ」できるようにしたくもありません。エンジンは主に単体テストによってテストされます。クライアントが存在するまで、プレイテストは開始されません。したがって、ここにはクライアントとサーバーの関係のようなものがあります。

エンジンは非常に大きなパズルのピースです。私が知りたいのは、このエンジンの「パブリックAPI」をどのように開発するかです。

エンジンは非常に基本的なWebサービスであり、クエリを介してRESTful APIに状態を返すことができると考えていましたが、エンジン自体をWebアプリとして開発すると、プログラミングの決定に悪影響を及ぼす可能性があると心配しています。（たとえば、MVCマイクロフレームワークを選択した場合、このAPIは実際にはビューを備えていません... JSONを介してシリアル化されたオブジェクトを返すか、そのための何かです。MVCを次のようなサービスに使用するのは悪いことですか？この？ ）

私のもう1つのアイデアは、エンジンは単なるコンソールアプリであり、後でそれとWebアプリの間でデータをパイプ処理するためのある種のブリッジを作成することでした。（ブリッジは実際には何でもかまいません。つまり、Webサーバーとゲームエンジンの両方がIRCサーバーでアイドル状態になり、その状態をチャネルで共有できます。）

どのようなアプローチをとりますか（Webサービスとして開発するか、スタンドアロンアプリケーションとして開発して後でブリッジする）、そしてその理由は何ですか？

ありがとう、ロビー。

編集：これはゲーム開発に属していると思います。わかりやすくするために、カードゲームエンジンを作成します。エンジンのAPIを公開して、将来的にWebクライアントやAIクライアントと統合できるようにする最善の方法を見つけ出そうとしています。

私はここにもアカウントを持っていなかったので、どうも:)

Webサービスルートは、おそらく最良かつ最もスケーラブルです。

私も絶対に見ないNO JSONを返すようにMVCフレームワークを使用して問題を（asp.net MVCは、この時素晴らしいです）。コントローラーが最初はJSONしか返さない場合は、ビューなしで単体テストを実行できます。ゲームインターフェイスを追加する準備ができたら、ビューを追加できます。プレーンなhtml / cssまたはflash / silverlightの場合は、問題はありません。なぜなら、すでに述べたように、基盤となるエンジンはすでに構築されているためです。

開発環境やホスティング環境がどのように見えるかはわかりませんが、過度に設計することはありません。JSONを返す単純なPHPファイルのセットで十分です。あなたが作成しているゲームに精通していないので、どれほど複雑になるかわかりません。

私の意見では、ゲーム開発に不慣れで、自分でやる場合は、できるだけ早くプレイできるものを入手することを強くお勧めします。これは、ゲームを完成させ、磨く意欲を維持するのに役立つためです。良いレベルに。

ビューは、変更が発生したときに通知を受けるモデルに登録するエンティティです。

モデルがWebサーバーにある場合、HTTPはサーバーに通信を開始させる明示的な方法を実装していないため、問題があります。これを処理するためにwebsocketを使用できますが、「RESTfulness」の一部を犠牲にします... Web URLにモデルを識別させ、HTTPサーバープッシュを使用してビューに通知を送信させるのが良い解決策になると思います必要なときに。

実行中のゲームがあるとしましょう

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

あなたはURLを使うことができます

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

モデルを変更し、

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

通知を待つ。

Notifyは、モデルによってニュースを取得するために（しばらくの間）待機します。何かが発生した場合、メッセージが送信されます（どのデータが変更されたか、どのようなイベントが発生したかなど）。

クライアントは、/ games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notifyに対して長いajaxリクエストを実行し、ビューの更新と次の通知リクエストの再投稿の両方を行う通知コールバックを登録できます。

games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notifyがクライアントでタイムアウトになると、新しいリクエストが実行され、サーバーでタイムアウトになると、割り当てられたリソースが解放されます。

サーバー上に非常に一般的な通知システムを構築し、クライアント上に通知ライブラリを構築できるので、透過的な通知レイヤー上に一貫したMVCを構築できます。

テクノロジーを探している場合は、Couchdbサーバー上にゲームエンジンを構築することを検討できます。Couchdbは非リレーショナルREST DBMSであり、プロトコルとしてHTTPを使用し、ドキュメント形式としてJSONを使用します。また、バイナリまたはHTMLファイルを添付ファイルとしてPUTおよびGETできるため、DBMS（couchApp）のみを使用して完全なwebAppを作成できます。

とりわけデータベースの更新に対応できるようにするJavaScriptライブラリが存在します。couchdbAppは単なるデータベースなので、同期によってアプリケーションを別のサーバーにコピーできます。クライアントはアプリをローカルサーバーにコピーして、オフラインのLANで再生できます。