2

ここが私が現在いる場所です。主要なコンポーネントを将来の作業に活用することを目的として、カード ゲームを設計しています。私を悩ませているのは、サーバーとクライアントの間に抽象化のレイヤーを作成することです。サーバーが起動すると、1 つ以上のクライアントが (ローカルまたはリモートで) 接続できるようになります。私はシック クライアントを設計していますが、友人が Web ベースのクライアントを検討しています。さまざまなクライアントが共通のサーバー コマンド セットを呼び出せるようにサーバーを設計したいと考えています。

そのため、最初に、ゲームのルールとプレイヤーのやり取りを管理する「サーバー」と、ローカル CLI の「クライアント」を作成したいと思います (便宜上、Ubuntu Linux を実行しています)。私は、将来のクライアントが CLI ベースまたはローカル マシン上にあることを強制せずに、2 つの部分がどのように相互作用するかを具体化しようとしています。

有益な次の 2 つの質問を見つけましたが、上記には完全には答えていません。

すぐにフル機能が必要というわけではありません。最終的なモックアップ コードが関係を適切に反映するように、抽象化の基本的なメカニズムを確立したいだけです。オールインワン アプリケーションとは異なる前提条件がクライアント/サーバー関係に関係しています。

どこから始めればよいですか？どのリソースをお勧めしますか?

免責事項: 私はさまざまな言語のコードと一般的なプログラミング/ロジックの概念に精通していますが、かなりの量のコードを実際に書いた経験はほとんどありません。このペット プロジェクトは、これを修正するための試みです。

また、すでに情報が出ていることは承知していますが、木よりも森が恋しいという印象が強いです。

4

3 に答える 3

2

RESTfulアーキテクチャについて読んでください。

ファットクライアントはRESTを使用できます。urllib2サーバーのRESTfulリクエストを行うために使用します。JSON表記でデータを交換できます。

WebクライアントはRESTを使用できます。単純なブラウザのHTTPリクエストを作成することも、JavascriptコンポーネントがJSONを使用してより高度なRESTリクエストを作成することもできます。

サーバーは、任意の単純なWSGIコンポーネントを使用して単純なWSGIアプリケーションとして構築できます。標準ライブラリに素敵なものがあるか、Werkzeugを使用できます。サーバーは単にREST要求を受け入れ、REST応答を行います。サーバーは、HTML（ブラウザーの場合）またはJSON（ファットクライアントまたはJavascriptクライアントの場合）で動作できます。

于 2009-08-18T00:35:39.720 に答える
2

すべてのサーバー/クライアントの相互作用をHTTPに基づいて行うことを検討します-おそらくJSONペイロードを使用します。これはサーバーが開始するインタラクション（「サーバープッシュ」）を直接許可しませんが、そのための（新しいがすでに伝統的な;-)回避策はAJAX-yです（XはXMLではなくJSONペイロードを提案するのでほとんど意味がありませんが1つ;-)-クライアントはサーバー上の特別なURLに対して（別のスレッドまたはその他の方法で）非同期要求を開始し、サーバーはそれらの要求に応答して（実際には）「プッシュ」を実行します。あなたの言うことから、このアプローチの制限は問題ではないように見えます。

このような用語でインタラクションを指定する主な利点は、プログラミング言語から完全に独立していることです。したがって、JavascriptのWebベースのクライアントは、PythonなどのCLIクライアントと同じように実行できます。サーバーは特別な場合としてローカルホスト上に存在できますが、HTTP URLはサーバーを実行しているホストを指定できるため、その制約はありません。などなど。

于 2009-08-18T00:39:44.183 に答える
2

まず第一に、クライアントの場所やタイプに関係なく、確立されたメッセージベースのインターフェイスを介して通信します。すべてのクライアントは、共通のリクエストとレスポンスのセットに基づいて動作し、サーバーはゲームの状態に応じた有効性に基づいてこれらを処理および拒否します。同じマシン上のローカル クライアントまたは HTTP 経由のリモート クライアントを処理しているかどうかは、抽象化の観点からはまったく問題ではありません。それらはすべて同じ一連の要求/応答を介して通信するためです。

結局のところ、あなたのプロトコルです。プロトコルは、クライアントが a) 効果的に参加し、b) 公平に参加できるように、クライアントとサーバーの間で明確に定義され、技術的に健全な言語である必要があります。このプロトコルは、クライアントが実行できるメッセージ (「移動」) と、サーバーがいつ、どのように反応するかを定義する必要があります。

ゲーム ロジックを開始する前に、プロトコルを完全に具体化して文書化する必要があります。この 2 つは本質的に接続されており、最初にプロトコルを完全に定義することで、多くの無駄な時間と労力を節約できます。

プロトコルは、クライアントとサーバー間の抽象化であり、両方の設計ドキュメントおよびプログラミング ガイドとしても機能します。

プロトコルの設計は、状態、状態遷移、および検証に関するものです。通常、ゲーム サーバーには、初期化、ロビー、ゲームプレイ、一時停止、リキャップ、ゲーム終了など、各ゲーム インスタンスのかなり一般的で一般的な状態のセットがあります。

これらの各状態には、関連する重要な状態データがあります。たとえば、サーバー側の「ロビー」状態には、各プレーヤーの既知の状態が含まれる場合があります...最後のメッセージまたは ping からの経過時間、プレーヤーが何をしているか (アバターの選択、設定の切り替え、冷蔵庫への移動)など）。コード内の状態データとサブ状態データを整理して管理することは重要です。

これらの状態を管理し、それぞれに関連するデータ要件を管理することは、作業量とプロジェクトの複雑さに直接関係するため、綿密に計画する必要があるプロセスです。もっと大きなものに。

また、あなたがゲームを持っていて、人々にプレイさせると、人々は不正行為をすることを心に留めておく必要があります. それは人生の事実です。これを最小限に抑えるには、プロトコルと状態管理を慎重に設計して、有効な状態遷移のみを許可する必要があります。単一のクライアント パケットを信頼しないでください。

クライアント/サーバーの状態の順列ごとに、有効なゲーム メッセージの限定されたセットを適用する必要があります。また、プレイヤーに何を許可するか、いつ許可するかについては十分に注意する必要があります。

プロジェクトの複雑さは一般に指数関数的であり、直線的ではありません。クライアント/サーバー ゲーム プログラミングは、通常、これを学習するための良い/苦痛な方法です。素晴らしい質問です。これがお役に立てば幸いです。幸運を祈ります。

于 2009-08-18T01:08:35.583 に答える