Pythonゲームプログラムの抽象化とクライアント/サーバーアーキテクチャの質問

Question

ここに私は現在いる。私は将来の仕事のために主要な構成要素を利用する目的でカードゲームをデザインしています。私をぶち壊している部分は、サーバーとクライアントの間に抽象化の層を作り出しています。サーバーが起動され、1つ以上のクライアントが（ローカルまたはリモートで）接続できます。私は太いクライアントを設計していますが、私の友人はウェブベースのクライアントを見ています。私は、さまざまなクライアントが共通のサーバーコマンドセットを呼び出すことができるようにサーバーを設計したいと考えています。

ゲームのルールとプレーヤーのやりとりを管理する 'サーバー'と、ローカルCLI（私は便宜上Ubuntu Linuxを実行しています）で 'クライアント'を作成したいと考えています。私は、将来のクライアントがCLIベースまたはローカルマシンであることを強制することなく、2つの部分がどのようにやり取りされるのかを明らかにしようとしています。

私は有益な以下の2つの質問を見つけましたが、上記にはあまり答えていません。

• Client Server programming in python?
• Evaluate my Python server structure

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

どこから始めますか？どのようなリソースをお勧めしますか？

免責事項： 私はさまざまな言語や一般的なプログラミング/ロジックの概念に精通していますが、相当量のコードを書くことはほとんどありません。このペットプロジェクトはこれを解決する試みです。

また、すでに情報があることは知っていますが、私は木の森が欠けているという強い印象を持っています。

Answer 1

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

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

WebクライアントはRESTを使用できます。シンプルなブラウザのHTTPリクエストを作成することができます.Javascriptコンポーネントは、JSONを使用してより洗練されたRESTリクエストを作成できます。

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

Answer 2

おそらくJSONペイロードを使用してHTTP上ですべてのサーバー/クライアントのやり取りを行うことを検討します。これはサーバーが開始した対話（「サーバープッシュ」）を直接許可するものではありませんが、AJAX-yの回避策（新しいものの、すでに伝統的な;-)回避策があります（XはJSONペイロード;-) - クライアントはサーバー上の特別なURLに対して非同期要求（別のスレッドなどを介して）を開始し、サーバーは（実際には）それらの要求に応答して「プッシュ」します。このアプローチの限界が問題ではないように思われるからです。

このような言葉で対話を指定する主な利点は、それらがプログラミング言語から完全に独立していることです.JavascriptのWebベースのクライアントはPythonなどのCLIと同じように動作します。もちろん、サーバーはlocalhost上に特別なケースとして存在することができますが、HTTP URLはサーバーを実行しているホストを指定できるため、サーバーの制約はありません。

Answer 3

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

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

ゲームロジックを始める前にプロトコルを完全に整理し、文書化しておく必要があります.2つのプロトコルは本質的に接続されているため、最初にプロトコルを競争力のある方法で定義するだけで無駄な時間と労力を大幅に節約できます。

は、クライアントとサーバー間の抽象化であるであり、両方の設計ドキュメントとプログラミングガイドとしても役立ちます。

プロトコル設計はすべて状態、状態遷移、および検証に関するものです。ゲームサーバは通常、ゲームインスタンスごとにかなり一般的な一連の状態を有する。ゲームの終了、リピート、ゲームの終了など。

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

これらの状態を管理し、それぞれの関連するデータ要件は、仕事量やプロジェクトの複雑さに直接関係しているため、絶妙な計画が必要です。これは非常に重要であり、より大きなものにステップアップするプロジェクト。

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

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

プロジェクトの複雑さは一般的に指数関数的で線形ではありません。クライアント/サーバーのゲームプログラミングは、これを学ぶのに良い/苦労します。素晴らしい質問。これが助けと幸運を願って！