App Engine + Twistedでのサイコロ戦争
8月以来、私の自由時間で、ダイスウォーズとして知られる世界で面白いリスクのようなおもちゃを開発しています。 日本の独創的なゲームデザイナーである伊藤太郎は、このゲームの素晴らしいルールを思いつき、それをフラッシュ （シングルプレイヤー）で作成し、ロシアではまだあまり知られていないこの主題について多くのバリエーションを生み出しました。
この記事では、3月に書いたリスクのようなゲームでの最初の失敗を分析し、App Engineをあらゆる場所で使用するというアイデアを放棄した理由を説明し、App Engine + Twistedから来たものを示します永続的な接続アプリには非常に役立つようです。 さらに、ActionScript 3での経験についてお話ししたいと思います。このテクノロジーに関する開発者のバックエンドのようなものです。また、ここで仲間や志を同じくする人々を探します。
この冬、App Engineを、サーバーからイベントを即座に受信するためのポーリングパターンを実装するアプリケーションサーバーとして使用するというアイデアを思いつきました。 つまり これは、1秒間にサーバーにリクエストを送信し、他のユーザーのアクション、チャットメッセージなどを受信するアプリケーションです。 例として、私は単純なリスク戦略を立て、 GoogleマップとそのJavaScript APIを使用することにしました。 そして、このゲームでは、2つの重要なミスを犯しました。
第一に、現時点ではJavaScriptのすべての魅力があるため、Flash / Silverlightを置き換えることはできず、多くの実装が困難です。 プログレッシブブラウザーは確かに多くの優れた機能をサポートしていますが、10年前と同様に、他のブラウザーとの互換性のためにif / switchを実行する必要があります。 さらに、たとえばキャンバスとGoogleマップを組み合わせるのは困難です。 これにより、ゲームで必要なさまざまなryushechekを作成することが難しくなります。
第二に、ポーリングの使用は悪いアイデアであることが判明しました。これはApp Engineに重い負荷をかけるためではなく、それを処理しますが、ポーリングは開発が難しいためです。
それ以来、Channel APIが登場しましたが、永続的な接続をサポートするサーバーを開発する際の柔軟性はまだありません。 プログラム内にロードしたすべてのオブジェクトを自由に操作し、ロジックに従ってサーバー間で負荷を分散する場合と、リクエストがどのサーバーから来たのかがわからず、毎回すべてのオブジェクトを再度リクエストする必要がある場合です。不要なオブジェクトを要求せず、memcacheのキャッシュを処理します。 今後、Googleがアプリケーションのインスタンス（インダクタンス）でより便利で柔軟な作業を導入することを願っています。
Flashを学習するためにいくつかのアプローチを取り、本を読み、Flash IDEを開き、これらのボタン、ウィンドウ、ヘルパーのすべてが不可解な拒絶を経験するたびに。 Flash IDEは、EclipseやVisual Studioなどの環境とはまったく異なるため、慎重に検討する必要があります。 解決策は簡単でした。 Flex SDK、mxmlcコンパイラがあり、それらを使用した開発は伝統的です。 VIM用のプラグインがあり、Actionscript 3は、最新のオブジェクト指向プログラミング言語です。 このような問題が発生している場合は、おそらくこの方法を試してください。
到着したばかりの回路を図に示します。 ゲームの仕組みは、クライアントからの永続的な接続を受け入れるデーモンを実行する別のLinuxサーバーに移動されました。 クライアントで永続的な接続を作成するには、Flashを使用します。Linuxサーバーのパワーが不足しているため、ゲームのスケーリングは非常に簡単です。 これはすべての場合に共通するソリューションではなく、異なるサーバー上のゲームオブジェクトを分離できることを前提としています。 私の場合、ゲームは異なる「部屋」で行われ、これらの部屋は異なるサーバーに配置できます。部屋内のすべてが1つのサーバーに自由に配置されます。
1億5億人が1つの場所でプレイし、動的に相互作用するスーパーグローバルゲームを作成する場合、おそらくこの場合、Channel APIはより柔軟なアプローチを提供できます。
私のスキームのApp Engineは、中央認証サーバーおよび統計サーバーになりました。 クライアントが認証のためにTwistedに接続すると、TwistedはApp Engineに要求を行い、それが主張するクライアントであるかどうかを確認します。 統計は、App Engineを使用するのに最適な領域です。
さまざまな認証のために、クラス図が図に示されているライブラリを作成しました。 エンドユーザー（エンドユーザー）アプリケーションは、ユーザーライブラリから継承されます。ユーザーライブラリは、さまざまな認証スキームを備えた構成を介して接続されます。
これはすべてApp Engineサーバーで行われ、クライアントがどこから来たTwistedサーバーにとっても問題ではありません。
現在、デザインとマーケティングに問題があります。 これらのいずれかを理解している場合、自由時間、何かをしたいという願望がありますが、誰に参加するかわからない場合、創造的なプロセスの喜びをあなたと共有したいと思います。私に個人的なメッセージまたはメールを書いてください。 自分の分野で専門家を見つけたいという願望、いつか強力な開発チームを作る機会は、私がこの記事を書いた目標の一部でした。
キューブゲームサイト
Facebookアプリ
お問い合わせ先
私の世界での応用
この記事では、3月に書いたリスクのようなゲームでの最初の失敗を分析し、App Engineをあらゆる場所で使用するというアイデアを放棄した理由を説明し、App Engine + Twistedから来たものを示します永続的な接続アプリには非常に役立つようです。 さらに、ActionScript 3での経験についてお話ししたいと思います。このテクノロジーに関する開発者のバックエンドのようなものです。また、ここで仲間や志を同じくする人々を探します。
最初のパンケーキ
この冬、App Engineを、サーバーからイベントを即座に受信するためのポーリングパターンを実装するアプリケーションサーバーとして使用するというアイデアを思いつきました。 つまり これは、1秒間にサーバーにリクエストを送信し、他のユーザーのアクション、チャットメッセージなどを受信するアプリケーションです。 例として、私は単純なリスク戦略を立て、 GoogleマップとそのJavaScript APIを使用することにしました。 そして、このゲームでは、2つの重要なミスを犯しました。
第一に、現時点ではJavaScriptのすべての魅力があるため、Flash / Silverlightを置き換えることはできず、多くの実装が困難です。 プログレッシブブラウザーは確かに多くの優れた機能をサポートしていますが、10年前と同様に、他のブラウザーとの互換性のためにif / switchを実行する必要があります。 さらに、たとえばキャンバスとGoogleマップを組み合わせるのは困難です。 これにより、ゲームで必要なさまざまなryushechekを作成することが難しくなります。
第二に、ポーリングの使用は悪いアイデアであることが判明しました。これはApp Engineに重い負荷をかけるためではなく、それを処理しますが、ポーリングは開発が難しいためです。
それ以来、Channel APIが登場しましたが、永続的な接続をサポートするサーバーを開発する際の柔軟性はまだありません。 プログラム内にロードしたすべてのオブジェクトを自由に操作し、ロジックに従ってサーバー間で負荷を分散する場合と、リクエストがどのサーバーから来たのかがわからず、毎回すべてのオブジェクトを再度リクエストする必要がある場合です。不要なオブジェクトを要求せず、memcacheのキャッシュを処理します。 今後、Googleがアプリケーションのインスタンス（インダクタンス）でより便利で柔軟な作業を導入することを願っています。
VIMファン向けのActionscript 3
Flashを学習するためにいくつかのアプローチを取り、本を読み、Flash IDEを開き、これらのボタン、ウィンドウ、ヘルパーのすべてが不可解な拒絶を経験するたびに。 Flash IDEは、EclipseやVisual Studioなどの環境とはまったく異なるため、慎重に検討する必要があります。 解決策は簡単でした。 Flex SDK、mxmlcコンパイラがあり、それらを使用した開発は伝統的です。 VIM用のプラグインがあり、Actionscript 3は、最新のオブジェクト指向プログラミング言語です。 このような問題が発生している場合は、おそらくこの方法を試してください。
App Engine +ツイスト
到着したばかりの回路を図に示します。 ゲームの仕組みは、クライアントからの永続的な接続を受け入れるデーモンを実行する別のLinuxサーバーに移動されました。 クライアントで永続的な接続を作成するには、Flashを使用します。Linuxサーバーのパワーが不足しているため、ゲームのスケーリングは非常に簡単です。 これはすべての場合に共通するソリューションではなく、異なるサーバー上のゲームオブジェクトを分離できることを前提としています。 私の場合、ゲームは異なる「部屋」で行われ、これらの部屋は異なるサーバーに配置できます。部屋内のすべてが1つのサーバーに自由に配置されます。
1億5億人が1つの場所でプレイし、動的に相互作用するスーパーグローバルゲームを作成する場合、おそらくこの場合、Channel APIはより柔軟なアプローチを提供できます。
私のスキームのApp Engineは、中央認証サーバーおよび統計サーバーになりました。 クライアントが認証のためにTwistedに接続すると、TwistedはApp Engineに要求を行い、それが主張するクライアントであるかどうかを確認します。 統計は、App Engineを使用するのに最適な領域です。
認証ライブラリ
さまざまな認証のために、クラス図が図に示されているライブラリを作成しました。 エンドユーザー（エンドユーザー）アプリケーションは、ユーザーライブラリから継承されます。ユーザーライブラリは、さまざまな認証スキームを備えた構成を介して接続されます。
これはすべてApp Engineサーバーで行われ、クライアントがどこから来たTwistedサーバーにとっても問題ではありません。
仲間を探しています
現在、デザインとマーケティングに問題があります。 これらのいずれかを理解している場合、自由時間、何かをしたいという願望がありますが、誰に参加するかわからない場合、創造的なプロセスの喜びをあなたと共有したいと思います。私に個人的なメッセージまたはメールを書いてください。 自分の分野で専門家を見つけたいという願望、いつか強力な開発チームを作る機会は、私がこの記事を書いた目標の一部でした。
参照資料
キューブゲームサイト
Facebookアプリ
お問い合わせ先
私の世界での応用
All Articles