🤙🏿 ♂️ 👩‍👧‍👧 独立した開発者が作成した1つのゲームの技術的な準備 😸 🛒 🦇

こんにちは、厳しいが公正なhabr！

私はあなたと一緒に私の親友と一緒に書かれたゲームを分析したいと思います。メカニックでは、ゲームとは、それぞれが1組のカードを持つ2人のプレイヤー間のリアルタイムの戦いです。そして、カードは順番に、すでに独立して敵のバンカーをひねり、同時に敵の兵士を崩している戦闘機を生成します。戦闘に加えて、ゲームにはマップのあるストアがあります。本部では、デッキを作成してキャラクターをダウンロードできます。クエストまたは実際の戦闘を実行できるアリーナ。さて、あなたはゲーム通貨を入手できる銀行です。私たちは独立した開発者であるため、リソースが限られており、多くのソリューションは理想的ではないことを思い出させてください。

ここでゲームを思いついたきっかけは次のとおりです： habrahabr.ru/post/142490

準備を始めましょう。

ソーシャルプラットフォーム

KISSの原則に従って、既製の承認メカニズムと幅広い配信の可能性があるため、すぐにソーシャルネットワーク向けのゲームを作成することにしました。一般的に、それらで聞かれる最も簡単な方法。 Vkontakteを選んだのは、若い視聴者と、このネットワークを私たちと一緒に使用した経験が多いためです。

ソーシャルネットワークとのすべてのやり取りは、グローブのようなソーシャルネットワークをさらに変更するために、シングルトンとは別のモジュールで実行されました。このために、各具体的なクラスが各ソーシャルネットワークに実装する必要がある単一のインターフェイスがあります。ゲームは、このインターフェイスを持つシングルトンを介してソーシャルネットワークと対話します。

フラッシュプラットフォーム

Vkontakteを選択すると、選択できる2つのテクノロジーがあります：flashとiframe（html + javascript）。正直なところ、私はhtmlゲームを消化していません。さらに、私は長年フラッシュ開発者でした。したがって、議論すらありませんでした。彼らはすぐにフラッシュを選択しました。

フレックス

フラッシュテクノロジーの内部には、純粋なアクションスクリプトで記述するか、フレックスフレームワークを使用するかという選択肢がありました。純粋なactionscriptはより高速なコードを提供しますが、flexはインターフェイスの迅速かつ柔軟な開発という利点があります。たとえば、flexウィンドウに統計ウィンドウを追加すると、純粋なactionscriptを使用するよりも速く、簡単で、信頼性が高くなります。ソロモンソリューションを選択しました。すべてのインターフェイスとゲーム環境はフレックスで行われ、バトル自体（ゲームのメインアクション）は純粋なアクションスクリプトで行われました。

彼らは3Dエンジンに目を向けず、複雑化しないことに決めましたが、もちろん非常に興味深いものです。

以下の情報は、フラッシュプレーヤー向けです。 （それはまさに派手主義者です。専門用語のフラッシャーは、公園のレインコートで裸で歩く男です...そして、あなたは知っています）。 Flashプレーヤーでない場合は、次のセクションに進むことができます。

flexでインターフェイスを構築するとき、すぐにスキンコンポーネントを作成しました。これを行うには、各コンポーネントがSkinnableComponentから継承する必要があります。

/** *  . * */ public class Card extends SkinnableComponent { /**    . */ private var _model:CardModel = new CardModel(); public function set model(value:CardModel):void { _model = value; modelChanged = true; this.invalidateProperties(); } public function get model():CardModel { return _model; } /** ,     .   .   commitProperties */ private var modelChanged:Boolean = false; [SkinPart(required="true")] /**  . */ public var nameLabel:Label; public function Card() { super(); } /** * @private */ override protected function partAdded(partName:String, instance:Object):void { super.partAdded(partName, instance); if (instance == nameLabel) { if(model) nameLabel.text = model.name; } } /** * @private */ override protected function commitProperties():void { super.commitProperties(); if(this.modelChanged) { if(model) nameLabel.text = model.name; } }

ここでは、次のコードに注意する必要があります。

 [SkinPart(required="true")] /**  . */ public var nameLabel:Label;

これは、特定のスキンにあるインターフェイス要素です。この事実は、SkinPartメタタグによって示されます。必須のメタタグパラメータは、この特定のコンポーネントをスキンに実装するか、省略できるかを示します。

スキンの要素を初期化するには、このメソッドを再定義する必要があります。その方法は、コードから明らかです。

 override protected function partAdded(partName:String, instance:Object):void

このメソッドをオーバーライドすることも理にかなっています：

 override protected function commitProperties():void

データを変更するときは、このメソッドのコンポーネントに新しいデータ値を割り当てるのが最適です。これにより、これらのコンポーネントのパフォーマンスが改善されます。実際、このメソッドは画面が再描画されたときにのみ呼び出されるため、リソースを大量に消費するコンポーネントの変更は実際に必要になるまで延期されます。

モデルにコンポーネントとは別にデータを保存します：

  /**    . */ private var _model:CardModel = new CardModel(); public function set model(value:CardModel):void { _model = value; modelChanged = true; this.invalidateProperties(); } public function get model():CardModel { return _model; }

データが変更された場合、保存するだけで、データモデルを変更済みとしてマークし、invalidateProperties（）メソッドを呼び出します。このメソッドは、データが変更されたため、commitProperties（）を呼び出す必要があることをflexに伝えます。自分でcommitProperties（）を呼び出すことはできません;私が言ったように、画面が再描画されるときに呼び出されます。

私たちのデータモデルは、モデルを記述するフィールドを持つ単なる構造です。

  /** *    . * */ public class CardModel { /**  . */ public var name:String = ""; }

スキンは次のようになります。

 <?xml version="1.0" encoding="utf-8"?> <s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx" xmlns:components="view.components.*"> <!-- host component --> <fx:Metadata> [HostComponent("view.components.Card")] </fx:Metadata> <s:Label id="nameLabel"/> </s:Skin>

ここでは、メタデータブロックに注意する必要があります。スキンの「ネイティブ」コンポーネントを示します。

コンポーネントをメカニズムとスキンに分離するスキームを使用して、バインド（バインディング）を拒否します。これは悪い習慣と見なされます。そして今、1つのコンポーネントに対して複数のプレゼンテーションオプションを用意し、それらをオンザフライで変更できます。また、デザインを完全に変更するまで、簡単に変更できます。

フラッシュXMLグラフィックス

私たちが使用した別のテクノロジーは、FXGまたはFlash XML Graphicsです。これは、XMLに基づいてアドビが開発したグラフィック用のベクター形式です。 mxmlでは便利です。この形式の画像があり、mxmlコードでは1つのタグで追加されます。さて、ベクターグラフィックスを使用すると、アプリケーションのサイズは3 MBになりました。真実は遅くなり、ろくでなし。速度を落とさないために、cashAsBitmap値をtrueに設定してすべてを停止しました。

建築

アーキテクチャを構築するとき、私たちは将来、ゲームクローンを迅速に作成するという目標を設定します。したがって、ゲームを次のレベルに分割しました。

コア
ロジック
データモデル
提出
スキン

カーネルはサーバーとの通信を引き継ぎます。ロジックはゲームの仕組みを保存します-クローンの基礎。モデルはデータを記述するだけで、それ以上のものはありません。表現は、インターフェースとインターフェースの仕組みのレベルです。そして、スキンはすでに目に見えるものです。

mvcアーキテクチャについてはここで確認しますが、開発を簡素化するためにこのアーキテクチャを実装する既製のフレームワーク（pureMVC、mate）は使用しませんでした。彼らは、論理と表現の分離の原則をイデオロギー的にのみ守ることにしました。

戦いの数学的モデル

ここで興味深い質問は、2つのクライアントのゲームワールドの同期です。結局のところ、私たちのゲームユニットはセルを回っていません。それらは平面上の実際の座標、異なるサイズを持ち、互いに衝突し、障害物を避けます。

同期のために、ゲームワールドのイベントの正確なシミュレーションを使用します。これは、2つのポイントによって実現されます。

任意の条件マット。整数データで記述されたパターン
20 msの固定間隔で時間を削減し、マットを再カウントします。モデルは+20ミリ秒のみ可能です。さらに必要な場合-マット。モデルは数回再集計されます。少ない場合、まったく再カウントされません。

マットこのモデルは、画面上での戦闘の表現とはまったく関係なく、独自に個別に機能します。したがって、他のテクノロジーについて、またクライアントに選択肢を与える準備ができたら、簡単に別のプレゼンテーションを行うことができます。たとえば、将来的にはstage3dを通じてスプライトグラフィックスを実行する予定です。

サーバー

サーバー部分をPHPで実行することにしました。実際、選択は次のとおりでした-ソケットまたはHTTPでクライアントサーバープロトコルを実装するため。そして、開発の速度とクライアントとの安定した作業の保証を優先して選択したので、クライアントを選択しました。つまり、PHP-なぜなら私たちはこの分野で豊富な経験を持っています。

サーバーからクライアントへ、およびクライアントから別のクライアントへのメッセージは、サーバーの定期的なポーリングのメカニズムを介して送信されます。オンラインゲームの成長に伴い、サーバーに大きな負荷がかかるため、別のサーバーですべてのポーリングメカニズムを選択しました。合計で、3種類のサーバーがあります。

メインサーバー。彼は私たちととても孤独です。すべてのプレイヤーのデータを保存し、このデータの変更を処理して（たとえば、ストアでゲームで何かを購入するとき）、ゲームに参加したプレイヤーをロビーおよびバトルサーバーに配布します。
ロビーサーバー。ゲームにログインする各プレイヤーには、利用可能なロビーサーバーのうち最も負荷の少ないサーバーが直ちに割り当てられます。それでも、各クライアントはすべてのロビーサーバーの完全なリストを受信し、ロビーサーバーの番号をすべてのサーバーに送信します。したがって、他のクライアントが私たち（クライアント）にメッセージを送信したい場合、バトルに参加するための招待状を言うと、彼のロビーサーバーから彼はどのサーバーにいるのかを知り、その後彼はロビーに具体的にメッセージを送信します。サーバー次に、ロビーサーバーを5秒ごとにポーリングするだけで、着信メッセージについて学習します。同様に、メインサーバーは必要なメッセージを任意のプレーヤーに送信できます。
バトルサーバーメインサーバーに2人のプレイヤーがお互いに戦闘に参加したい場合、それらには利用可能なバトルサーバーの中で最も負荷の少ないものが割り当てられます。次に、ロビーサーバーのメカニズムを介して、特定のバトルサーバー、既に作成されたバトルの鍵、その他すべてを示す、バトルに参加するための招待状が送信されます。このバトルサーバーでは、プレイヤーは既に2秒のポーリング頻度で静かに情報を交換しており、サーバーシステムの他の部分と干渉することはありません。

サーバーは、httpプロトコルを介して相互に通信します。ただし、微妙な点が1つあります。多くの場合、応答を待たずにhttp要求を送信することが使用されます。たとえば、バトルを作成するとき：一意のGUIDキーを作成し、選択したバトルサーバーにコマンドを送信してこのキーでバトルを作成します。答えを待たずに、同じキーで選択したバトルサーバーにプレイヤーのロビーサーバーに招待を送信します。、リクエストの処理を完了します。

このようなシステムのおかげで、ホット用のサーバープラットフォームのパフォーマンスを動的に変更することができます（メインサーバーを除く）。必要に応じて、追加のサーバーを単純に委託します。したがって、私たちは安価なVPSサーバーでホストされており、高価で強力なサーバーに前払いする必要はありません。さらに、有料のホスティング事業者は、VPSをオフにすることなく、VPSのパフォーマンスを向上させることができます。

メインサーバーのアカウントに：バトルサーバーとロビーサーバーからシステムを導入することにより、ほとんどの負荷を取り除き、最初に最も強力なVPSの1つで十分であり、それを実際のサーバーハードウェアに転送することを願っています。ゲームのサーバー部分をさらに最適化する必要がある場合は、統計収集キャンペーンを理解します。

MMOテクノロジー

私たちのゲームは、友人またはランダムな対戦相手とネットワークを介してプレイする能力を持っています。

友人との戦いは、戦いへの招待のメカニズムによって作成されます。私は友人に招待を投げることができ、彼はそれを受け入れるか拒否することができます。

ここで興味深いのは、今回は招待者自身のテーブル、逃した招待者のリスト、その他のがらくたを放棄することにしたことです。以前のプロジェクトですでにこれを食べていました。事実、それは単純なように見えますが、実際には膨大な数の予期しない状況があります。プレーヤーがオフラインの場合はどうなりますか？そして、それがオンラインのようなものであるが、インターネットが彼に向けられたばかりで、誰もまだそれを知らない場合は？そして、彼がアプリケーションを削除したが、データベースに残っていたとしたら？そして、彼がクリックして招待を受け入れたが、キャンセルして別のプレーヤーをすでに投げた場合はどうなりますか？そして、招待を投げてページを更新するとどうなりますか？まあ、など非常に多くの混乱があります。

そのため、すべてをシンプルにしました。プレーヤーのテーブルには、stateとenemyIdの2つのフィールドしかありません。状態は、プレーヤーが無料かどうか、招待を投げたかどうか、着信招待についてのメッセージが表示されるかどうか、戦闘中かどうかを決定します。相手Id-なぜ必要なのかは明らかだと思います。無料のプレイヤーにのみ招待を投げることができます。また、ブラウザページが突然リロードされた後でも、クライアントは戦闘への招待に関するすべてのダイアログをすばやく復元します。

ランダムな敵との戦いは、レーティングによる敵の選択を通じて実装されます。プレーヤーがリクエストを送信します。アプリケーションはデータベースに15秒間存在し、その後処理されます。処理は、10秒ごとに実行されるスクリプトを使用して行われます。このスクリプトは、最も近い評価を持つアプリケーションのペアを選択します。しかし、正確に最も近いわけではありません-特定の範囲のランダムで使用されます。そして、範囲は徐々に拡大しています。まず最初に、最も低い評価のアプリケーションが処理されます-新しく到着した顧客の可能な限り最高の処理を保証するために。なぜならアプリケーションは急速に分岐するため、このスクリプトは最適化を必要としません。したがって、ここではアルゴリズムについては説明しません。すべてがシンプルで線形です。

15秒の遅延が必要です。これがないと、2番目のアプリケーションごとに最初のアプリケーションとの戦いが開始され、評価は考慮されません。

結論として

申し訳ありませんが、写真、グラフ、表の欠如に対する罪深い頭であるハブラー、しかし私たちのゲームのすべての勇気はあなたの前にあります。可能であればアドバイスします。はい、言い忘れました。収益化についての次の記事とその費用を書き、最初の結果を示します。

独立した開発者が作成した1つのゲームの技術的な準備