Unity3Dでのシンプルな2Dゲームのアーキテクチャ。 計画、事実、エラー処理

最近、ホイッスリングカイトフレームワークチームが別のゲームをリリースしました。今回はUnity3Dで書かれたスネークです。 ほとんどのゲームプロジェクトのように、アプリケーションをどの程度詳細に設計する必要があるかを決定するとき、時間は重要な要素でした。 私たちの場合、理由は簡単です： 開発はメインの作業から自由時間で行われ、その後、設計への理想的なアプローチはリリースをもう1年延期します。 したがって、最初のモジュールへの分割を行った後、設計を完了して開発を開始しました。 カッターの下には、その由来と、私が自分で学んだいくつかのレッスンの説明があります。





注意写真！



すぐに免責事項を挿入したいと思います。以下で説明するものはすべて、イベントの回顧と、何がうまくいったのか、何が悪いのかを分析する試みです。 この記事は、議論の余地のない真実を述べているふりをしているのではなく、むしろ逆に「有害なアドバイス」であり、おそらく同じ間違いから誰かを救うでしょう。

機能性

最初に、実際にはアプリケーションについていくつかの言葉を使用します。これにより、設計および開発した内容が明確になります。 ヘビを作成するために、ヘビ、リンゴ、壁、そして先へ進むという無限の欲望しかなかった、古き良き古典ヘビを正確に再現しようとしました。 そのため、私たちは古典的なゲームプレイに焦点を合わせ、この段階ですべての追加機能を意図的に除外しました。



ヘビの主な利点の1つは、設定で見つけることができるさまざまな制御オプションです。 私たちはそれらすべてを提供しようとしました：

• 4つのボタン-新しい移動方向を設定します。
• 2つのボタン-現在の方向から左/右に曲がります。
• svaypy-指を正しい方向に動かしてください。

さらに2つ追加する予定です。

• ジャイロスコープ-デバイスの傾きが新しい方向を設定します。
• ジョイスティック-「バブル」-最初の接触点からの指の移動が新しい方向を設定します。

ゲームで入力された評価は、高得点表に記録されます。 記録は、Twitter、vkontakte、facebookなど、スマートフォンに接続されたSMS、メール、またはソーシャルネットワークを介して友人と共有できます。



私たちが作ったヘビの開発を開始するという決定は、2つの目標を追求しました。

• Androidに存在する「ヘビ」のほとんどを試したが、いくつかのチームメンバーがプレイしたいものを見つけられなかったため、この状況を修正することにしました。
• 私たちは最初にモバイル市場に参入し、Unity3Dエンジンを使用することに決めました。そのため、それに慣れるために意図的に単純なゲームを選択しました。

建築

ステージ1.コンセプト

アーキテクチャの最初の概念的なバージョンは、統一を選択する前から私たちによって作成されました。 以下の図に示されています。 このオプションでは、将来のアプリケーションのレイヤーを強調しました。

• 初期化レイヤー。
• インターフェース層。
• ロジックの層。
• コントローラー層;
• 制御層。

歴史的に、初期化レイヤーは最後に選択されましたが、アプリケーションでは最初に起動されるべきでした。 実際には、最初にオブジェクト自体にオブジェクトの初期化を設定しましたが、次にそれを集中的に割り当てることにしました。

インターフェース、ロジック、コントローラーのレイヤーは、ほぼ古典的なMVCパターンです。 同時に、インターフェイスの最大の滑らかさを保証するために、これらのレイヤーの処理を異なるストリームに分けたいという要望がありました。

制御層は個別に取り出されました。 さまざまな制御オプションが主な機能の1つであると判断したため、アプリケーションの残りの部分が選択したオプションに依存しないことを確認する必要がありました。

すべてのレイヤーは専用インターフェイスを介して相互に通信する必要があり、各レイヤーは独自のオブジェクトを含み、機能を実行しました。多くの場合、独自の処理フローが含まれていました。



良いアイデア：

• 初期化レイヤーのハイライト：以降のバージョンでは、これは失われ、アクションのシーケンスがかなり混乱する場合がありました。
• アプリケーションをモジュールに分割する正しい一般的な構造：将来、境界は異なり、カプセル化の概念はほとんど忘れられていました（猫で「バグがあります」という画像を与えることができます。

ミス：

• コントローラーとコントロールのレイヤーを分離：その後、MVCの観点からコントローラーは冗長性のために放棄されました。
• 高レベルの説明：どのコードを記述するかは明確ではありません。 これは純粋な失態とは言えませんが、 このアーキテクチャの作成時点では、エンジンはまだ選択されていませんでした。

次のステップはプラットフォームの選択でしたが、厳密に言えば、純粋なJavaでの統一と開発の間で選択が行われました。 他の既存のエンジンの大まかなレビューは、彼らの研究に熱意を喚起しませんでした。 私たちはかなり予想された結論に達しました。プラットフォームなしでヘビを書くのは簡単で、さらに面白そうに見えました-誰が自分の自転車を作りたくないのですか？ ただし、プラットフォームに慣れるために統一を選択しました。これは、ゲーム乙女の分野における事実上の標準のステータスに近いものです。 はい、Unityは3次元エンジンであるため（開発が開始された時点で、Unityはまだネイティブ2Dをサポートしていませんでした）、2次元のゲームを行いましたが、得られた経験はそれだけの価値がありました。

ステージ2.プロジェクト

プラットフォームを選択する際に、共同で設計ドキュメントを作成し、そのベースに基づいて、選択したプラットフォーム用にシャープ化された2番目のアーキテクチャプロジェクトを作成しました。



このアーキテクチャはいくつかの関連する図で構成されており、以下ではUML用語と呼んでいますが、もちろん、それらは完全にではなく、穏やかに置くために標準に従っています。



接続の本質（これは、アーキテクチャではなくシステムとして分類される可能性が高いことは明らかですが、記事の文脈では言及するしかありません：







ERD表記は、誰もが知っていると思います。 ゲームロジックのすべてのオブジェクトとそれらの間の論理的な接続を示します。 そのような各オブジェクトは、このオブジェクトの動作を保証する1つのクラスを生成します。



コンポーネント図と連携図。 彼らの認識のために、私は最初にいくつかの合意について説明します。



一般的なアーキテクチャ-一般的な概念的な性質であり、実際には、ステージ1の図の続きです。

• システムコンポーネント（四角形）;
• ストレージサブシステム（データベースシンボル、磁気ディスク）;
• メモ（黄色の「シート」）;
• 制御フロー（塗りつぶされた矢印）;
• データストリーム（破線の矢印）。

詳細チャートには以下が含まれます。

• コンポーネント、オブジェクト（長方形）;
• オブジェクト（六角形）によって処理されるイベント。
• イベント（楕円）によって実行されるアクション。

一般に、概念はあまり変わりません。初期化用の個別のコンポーネントもあり、2つのメインサブシステムが強調表示されます。

アプリケーションの起動後、初期化コンポーネントが最初に動作を開始します。ストレージから必要なすべてのデータを要求し、GUIサブシステムを開始します。



GUIサブシステムは、ユーザーにメインメニュー、設定、および記録を提供する必要があります。 ゲームの開始時に、制御は制御サブシステムに転送されます。



制御サブシステムは、ゲーム世界とのユーザーインタラクションを提供する必要があります。まず、ヘビによる直接制御です。



レコードを記録および共有するために個別に選択されたコンポーネント。



ゲームワールドは、ERDから取得したオブジェクトで構成されています。 重要な役割は、パーティとヘビによって演じられます。



パーティは、ヘビと現在のフルーツインスタンスへのリンクを保存し、ゲームオブジェクトとそれらの相互作用の初期化を提供します。

ヘビは主なゲームイベントを処理します。それは、自身の動き、果物を食べること、壁や尾との衝突です。

フルーツインスタンスは、自身のライフタイムを制御する責任があります。



良いアイデア：

• 2つの主要な独立したサブシステムの分離：これは開発時に考慮されず、当初は多数の余分なシーンが発生していました。

ミス：

• シーンの分離を考慮せず、ゲームシーンからストレージサブシステムを操作します。
• GUIサブシステムの実装方法とサブシステムの相互作用方法の質問には答えません。
• Partyオブジェクトは、MVCの観点からコントローラーの機能を引き継ぎました。

ステージ3.実際の結果

開発の開始後、誰もアーキテクチャを修正していません。 設計ドキュメントの対応するセクションに、これらのボトルネックやその他のボトルネックの実装方法に関する個別のメモを残しただけですが、主な目標はリリースをリリースすることでした。 さて、私たちはこの目標を達成し、リファクタリングのために座って、2番目のリリースの開発に備えました。 その瞬間、私はまず、ゲームを正直な2dに移行する必要があることを理解しました。そのサポートは団結して現れたばかりです。 また、得られた結果は、主に関数をオブジェクトとその相互作用で分割するという点で、理想とはほど遠いという理解もありました。そのため、私は2つのタスクを設定しました。

1. 一般的なクラス図を作成する
2. 主なアプリケーションシナリオのシーケンス図を作成します。

この情報に基づいて、変更する必要があるもののリストを取得する予定でした。 そのようなリバースエンジニアリングの結果を以下に示します。各セクションでは、まずこのセクションの内容を簡単に説明し、次に構築されたソリューションを示す1つ以上の図を示し、次に何がどのように行われたかを詳細に説明します。

作成されたクラスの概要

次の図は、ゲーム開発中に作成されたすべてのクラスを示しています。 メソッドの一部は、セマンティックの負荷を持たないか、言及する価値がないほど些細なダイアグラムに隠されています。 また、変数の名前（テクスチャなど）の下には、変数のブロック全体（この場合、さまざまなテクスチャ）もしばしばあります。







利用可能なすべてのクラスは、4つのパッケージに分けられます。

• Gamelogic -irgフィールドに存在するゲームオブジェクトのクラスをここに示します。 実際、これはゲームのコアによってはんだ付けされています。
• Gui-静的なユーザーインターフェイスの構築を担当するクラスは次のとおりです。メインメニュー、設定、レコード、プレイフィールドの上にあるボタン。ただし、ヘビを直接制御するためのボタンは除きます。
• コントローラーは、アプリケーションのハイライトです。さまざまな方法でヘビを制御するパッケージです。 各クラスには、インターフェイスボタンから回転計算ロジックまで、選択したコントロールスタイルに必要なすべてが含まれています。
• プロバイダー -このパッケージには、データの読み取りや保存、レコードを共有する機能、ロギング、分析などの機能を提供する補助クラスが含まれています。

ゲームロジックパッケージでは、中心的な場所はパーティークラスであり、これは1つのゲームパーティーです。 このクラスは、ゲームの開始と終了、レーティング、リンゴを食べるイベントとリンゴの寿命の満了、および他の多くの補助機能を調整します。 この記事の執筆中に、他のクラス（実際には蛇とりんご）からのメソッド呼び出しのみを残して、このクラスを実際に書き直しました。 これはカプセル化により適していますが、MVCの点ではこのクラスをコントローラーのようにしています。



2番目に重要なSnakeクラスには、依存するSnakechainオブジェクトの管理を含む、蛇の動きのロジックが含まれています。 制御コントローラーがコマンドを送信するのはこのクラスです。



ファクトリは、フルーツインスタンス（FruitInstance）を作成するために使用されます。 将来的には、さまざまな種類の果物の数を増やす予定です。



インターフェイスパッケージには、状況に応じて、ユーザーインターフェイスの表示と処理を担当する個別のクラスが含まれています。 また、デバイスの鉄ボタンを押すことも処理します。



コントローラーパッケージにはコントロールクラスが含まれています。 それらはスネークに追加され、コマンドパターンを使用してスネークオブジェクトと直接対話し、スネークは受信したコマンドを同じシーケンスで実行しますが、そのステップは個別に実行します。 これは、高速の連続コマンドを正しく処理するために行われました。たとえば、尾に沿って180度回転します。



プロバイダーを含むパッケージには、この記事で興味深いクラスが1つだけ含まれています。それはdataProviderです。 このクラスには、保存されたプロパティを操作するための標準メソッドの呼び出しのラッパーである静的関数のセットが含まれています。 設計の以前の両方の段階で、保存されたデータの操作は一度だけ行われるはずでした。それらをメモリにロードし、低速なメディアにアクセスしなくなりました。 このアプローチでは、Unityのシーンの独立性の問題を考慮していませんでした。その結果、メインメニューのシーンと競技場を切り替えるときに、必要なすべてのデータを再読み取りする必要がありました。

初期条件

以下は、ゲームを構成する2つのシーンの初期状態の説明です。メインメニューシーン（左下の図）と競技場のシーン（右下の図）です。 初期状態は、実行可能コードを実行する前にエディターに入力された内容によって決まります。 これらの状態から、ほとんどのシーケンス図が下から始まります。







メインメニューは、プレーヤーとGUIナビゲーターの2つのクラスによって作成され、シーン上の1つのオブジェクトとカメラにアタッチされます。 プレーヤーはプレーヤーに関するすべての基本情報をダウンロードする責任があり、GUInavigatorはインターフェースパッケージから目的の動作を開始し、インターフェース間のさらなる移行を提供します。



ゲームシーンには、さらに多くのオブジェクトが含まれています。 それらのほとんどは静的で、背景、競技場、壁などのヘビの世界を表しています。 追加のビヘイビアーは、カメラ（GUIナビゲーター、プレーヤー、パーティー、fruitfabric）とヘビの頭（Snake、Controllerselector）の2つのオブジェクトにのみ付加されます。 Controllerselectorは、プレーヤーの設定に応じてコントロールコントローラーを選択します。

アプリケーションの起動

次の図は、アプリケーションの起動手順を示しています（その部分では、開発者が制御します）。 保存された未完成のゲームがある場合、スクリプトからの別の方法とゲームのロードへの移行にのみ特に注意を払うことができます。







アプリケーションのロードは、アウェイクと開始の2つのイベントの処理で構成されます。 awakeイベントはプレーヤーオブジェクトによって処理されます。この時点で、DataProviderを呼び出してプレーヤーに関する情報をロードし、独自のメソッドを呼び出します。このメソッドは、現在の設定の適用、たとえばサウンドのミュートを行います。



Startイベントはもう少し複雑に処理されます。

1. initMainメソッドのGUIナビゲーターは、このシーンで必要なすべてのインターフェイスを開始します。各インターフェイスは非アクティブなサインを持ちます。
2. 次に、未完成のゲームが保存されたかどうかを確認します。 これは、たとえば、着信コールによってゲームが中断された場合に可能です。
3. 1. ゲームがある場合、ゲームシーンが読み込まれ、このシナリオは中断されます。
4. 従来、同時に開始されたインターフェイスのすべてのクラスに対して開始イベントが処理されます-追加の初期化がそれらに適用されます。これは、特定の各インターフェイスに個別に固有です（dataProviderを使用してハイスコアテーブルからデータをロードするハイスコアインターフェイスを含む）。
5. メインメニューインターフェイスにはアクティブフラグが割り当てられ、ユーザーに表示されます。

ゲームの発売

次に、ゲームを開始するときの手順を示すシーケンス図を考えます。 開始点は、ゲームにシーンをロードすることです。

この図では、保存されたゲームをロードするための代替シナリオを個別に注目する価値があります。これは、たとえば着信コールによってゲームが中断した場合に必要です。







トリガーする最初のイベントは、Awake for Playerオブジェクト（アプリケーションの起動と同様にすべての設定を読み込む）とSnake（Init（）メソッド-2つのセグメントから「デフォルト」でテールを初期化する）です。 次に、Startイベントがトリガーされてコントローラーが選択され（たとえば、FourButtonControllerが使用されます）、GUIが読み込まれ、ゲームが初期化されます。 このイベントの処理についてもう少し詳しく：

1. Startイベントのコントローラーセレクターは、プレーヤーの設定を確認し、必要なコントロールコントローラーを読み込みます。
2. initGameメソッドのGUIナビゲーターは、このシーンで必要なすべてのインターフェイスを開始します。各インターフェイスは非アクティブなサインを持ちます。 呼び出すメソッドの決定は、エディターで指定されたパラメーターに基づいて行われます。 アクティブなインターフェイスの初期化とアクティブ化は、アプリケーションの起動に似ています。
3. 次に、開始イベントはパーティーオブジェクトを処理します。 まず、保存されたゲームがあるかどうかをチェックします。
   
   
   1. ゲームがある場合、パーティーはdataProviderを呼び出して復元し、データを読み取った後、パーティーオブジェクトのRestorebackupメソッドを呼び出します。
   2. 次に、彼はSnakeオブジェクトの同様のメソッドを呼び出し、そのメソッドはすべてのリンクにチェーンされます。
   3. データの回復後、制御がパーティオブジェクトに戻され、一時停止してプレーヤーのアクションを待ちます。
   
   
   
4. ゲームがなかった場合、パーティーはフルーツファクトリーを呼び出してインスタンスを作成し、ゲームが開始されました。 ちなみに、この図は、パーティがフルーツのいくつかのパラメータを設定することも担当していることを示しています-これはもはや事実ではありません。

ゲームサイクル：ヘビの動き

ゲームロジックは、2つのイベントの処理に集中しています。更新は、moveheadメソッドによってスネークで処理されます。ここでは、スネークが移動し、セグメントの動きを制御します。 ontriggerenterでは、スネークヘッドと果物、壁、それ自体の尾との衝突処理が行われます。







衝突イベントをより詳細に分析します。

1. イベントが発生すると、最初に誰と遭遇したかがチェックされます。リンゴの場合はEatfruitメソッドが呼び出され、尾または壁の場合はKillmeが呼び出されます。 どちらの場合も、衝突情報はログにダンプされます。
2. Appleケース：
   
   
   1. ヘビはフラグを設定してリンクを追加し、パーティーオブジェクトのEatfruitメソッドを呼び出します。
   2. パーティーはパーティーの評価を上げ、独自のcreatefruitメソッドを呼び出します。このメソッドは、ゲームの開始時にも使用されました。
   3. このメソッドでは、現在のフルーツインスタンスが最初に削除され、次にファクトリへの呼び出しによって新しいインスタンスが作成されます。
   
   
   
3. 壁またはテールケース：
   
   
   1. ヘビは、Endgameメソッドでイベント処理をパーティーオブジェクトに渡します。
   2. パーティーは一時停止モードを設定し、インターフェイスナビゲーターを介して、パーティーの結果とともにプレーヤーを画面に表示します。
   
   
   

ヘビの動きは次のように実装されます。

1. 更新イベントでは、moveheadメソッドが呼び出されます
2. ここでヘビの速度がチェックされます：移行の瞬間が到着したかどうか
3. はいの場合、リンクを追加する必要があるというフラグがチェックされます
   
   
   1. 必要に応じて、ヘッドに続くリンクと同様のリンクが作成されます。
   2. 頭と1つの新しく作成されたリンクのみがシフトされます。
   
   
   
4. フラグがない場合は、調整メソッドを使用して、ヘッドが移動し、その後チェーンに沿ったすべてのリンクが移動します。

おわりに

多くのロジックがこの記事の範囲を超えて残っています。これは、内部分析と外部分析の両方のロギングです。 これは、2つのシーンに関連付けられたすべての機能をカプセル化するインターフェイスナビゲーターの機能です。 これは、デバイスでデータを操作し、広告やその他の多くの機能を表示しています。 誰かが興味を持っているなら、私はこれについて別々に書くことができます。



特定された主な問題：

• 3dを2dに置き換えます。 これは図からはわかりませんが、意図した目的でツールを使用することの好みの観点から明らかです。
• パーティーオブジェクトは機能が多すぎるため、リンゴとヘビの両方、およびゲームの完了処理を制御します。
• ゲームインターフェースは過負荷です-ゲーム内と衝突後の2つの状態に分割する必要があります。
• エンジンによって提供されないデバイス機能を操作するためのファサードはありません：私たちのケースでは、Androidの場合、オーバーライドされた振動メソッド、共有ボタンの実装（アプリケーションを選択するためのシステムウィンドウの呼び出し）、Googleアナリティクスへの呼び出しです。

上記に基づいて、将来のプロジェクトに対してどのような結論を導き出しましたか？

1. 真剣に取り組む前に、プラットフォームを知る必要があります。 これは一般的に明らかですが、繰り返しになりますが、経験がなくても誰かが次のキラートップMMOを立ち上げるのを助けてくれるかもしれません。
2. アプリケーションを（単純であっても）コンポーネントに分離するように設計する必要があります。 この段階での主なことは、対話とデータフローの数を最小限にすることです。
3. クラスの構造を考えると、オブジェクトがコンポーネントにどのように関係するのか、そしてそれらが実行する機能（機能のグループ）をすぐに考える必要があります。
4. 一方では、計画されたアーキテクチャと連絡を取り合う必要がありますが、他方では、新しい条件が発生した場合に変更する準備をする必要があります。

最適でない解決策が他にもある場合は、コメントで話し、喜んで話し合ってください。



念のため、最後に記事に関連するすべてのリンクを提供します。

• Unity3d
• ステージ1のアーキテクチャ図はyEdに描かれています。
• ステージ2のアーキテクチャ図は、 DrawExpress Liteの andoroidタブレットに描画されます。
• ステージ3アーキテクチャ図は、 Visual Paradigmで描画されます。
• 問題のアプリケーションはplay.googleで表示できます。
• 当社のウェブサイトで当社のチームの詳細をご覧いただけます。

PSこの記事の準備中に、見つかったエラーの一部は既に修正されており、おそらく新しいものが導入されました。 開発は止まりません。