コンポーネント指向プログラミングアプローチの紹介

Unityエンジン自体（以下Unity）は、他の多くのゲームエンジンと同様に、コンポーネント指向プログラミング（以下CPCと呼びます）に最も適合しています。これは、動作パターンがエンジンのアーキテクチャの基本パターンの1つであり、Decouple Patterns分類の「コンポーネント」パターンであるためです。 したがって、Unityでビジネスロジックを実装するための基本単位であるコンポーネントです。 この記事では、UnityでCPCを使用する方法について説明します。



一般に、CPCは、脆弱な基本クラスとして知られる問題の場所を排除したOOPの原則の開発と考えることができます。 同様に、CPCの開発はサービス指向プログラミングと考えることができます。 しかし、トピックに戻ります。 KOP-KOPomにすぐに注意する必要がありますが、GRASP、SOLIDなどの原則を決して忘れないでください。



コンポーネントをMonoBehaviourから継承したクラスと呼びます。 ここでは、基本クラス自体の名前が非常に適切に選択されており、この動作が明確になり、.monoプラットフォームによって実行されることがわかります。 しかし、MONOは1つ、* 1つ*の動作であると仮定すると非常に便利です。 そして、コンポーネントを開発する際に最初に注意する必要があるのは、1つのコンポーネント-1つの動作です。 SOLIDの唯一の責任原則と、GRASPが動作しているクラス内のメソッドの高度な結合。



それでは、GRASPに注目しましょう。 プログラミングは、特定の実装（低結合）ではなく、抽象化のレベルでなければなりません。 そして、一見シンプルなゲームプレイでさえ、インターフェースのUML図の作成が必要です。 なんで？ 不要ではない、「ヤグニ」（あなたはそれを必要としません）の原則は忘れられないです。 正当化されれば冗長ではありません。 誰がゲームを思いつきますか？ ゲームデザイナー、民間人の外観のこれらの陰湿な人々。 そして、彼らが何も変えないということは起こりません。 したがって、変更に備える必要がありますが、多くの場合、ゲームロジックを拡張する準備が必要です。 さらに、これらのすべての変更はすぐには行われませんが、開発者自身がこれを行う理由をすでに忘れており、そうでない場合はそうではありません。 したがって、少なくとも抽象化されたUMLダイアグラムを常に実行する必要があります。これはプロジェクトのドキュメントです。 C＃コードを生成するために、Visual StudioでUML図を開発します。

それでは、ゲームの開発を始めましょう。 たとえば、タワーディフェンスのコアゲームプレイを作成します。 開発手順にはさまざまなアプローチがありますが、短縮版を使用します。

最初のステップ：問題の説明

ゲーム用に作成されたドキュメントのページ数に関係なく、主なものを常に強調できるはずです。 もちろん、ゲームプレイの大まかな説明は、ユースケースに分割する方が適切です。

プレイヤーは敵がハウスを破壊しないようにしなければなりません。 これを行うには、彼は範囲内の敵を破壊する塔を設定する必要があります。 同時に、1つのタワーが攻撃できる敵は1人だけです。 彼が死ぬか塔の範囲外に出ると、次に利用可能なものが選択されます。 敵は波のように見え、各波の数は増えます。 敵は出現地点から家への道に沿って移動します。 家に近づくと破壊され始めます。 家が破壊されると、ゲームオーバーです。

2番目のステップ：タスク分析

主なものの研究から始めましょう：塔、クリープ、家。 そのため、既に配置されたゲームオブジェクト（タワーと家）でシーンを作成すると、結果が得られます：クリープが表示され、家に移動し、塔の損傷による経路に沿って死に、それらが家に到達すると損傷を引き起こします。 死亡すると、クリープはシーンから消えます。 家が破壊されるか、すべてのクリープが破壊されると、ゲームオーバーです。



メインのゲームエンティティを選択し、それらのプロパティと動作を指定します。



1）タワー。 プロパティ：ダメージ、ショット間のクールダウン、ターゲット選択範囲、ターゲット選択ロジック。

動作：ターゲット選択とターゲット攻撃。

また、さまざまなゲームプレイでは、ダメージ、破壊の半径、ターゲット選択のロジックなど、さまざまな種類のタワーがあります。

2）クリープ。 プロパティ：HP、ダメージ、攻撃間のクールダウン、移動速度。

行動：家へのルートに沿って移動する。 近くに近づいたら、自宅で攻撃してください。 HP = 0の場合、殺されたと見なされます。

さまざまなタイプのクリープ-たとえば、HPによる。

3）家。 プロパティ：HP。

動作：HP = 0の場合、プレイヤーは負けます。

第三段階：分解

タスクを適切に分解することは非常に重要だと思います。 ほとんどの時間は、抽象化とそれらの間の論理的接続の研究に費やされるべきです。



まず、動作を要約して、どのコンポーネントが必要かを特定します。



1）ゲームには、ダメージ動作を行う2つのエンティティ、タワーとクリープがあります。 この動作をコンポーネントに分離します。インターフェースは次のとおりです。







待って、待って、誰かが言うでしょう：「カプセル化はどうですか？ 誰でもクールダウンとダメージを変更できるのですか？」いいえ、ゲームデザイナーだけが、コンポーネントのプロパティを直感的な方法で設定します。 したがって、すべてのプロパティはUIに情報を表示するだけで、設定する必要はありません。 さらに、Unityはインスペクターで指定されたget / setコンストラクトのプロパティを表示できません。また、[SerializeField]でマークされたフィールドを作成する必要があります。 そして当然、コードの他のクラスはプロパティの値を変更できません。



コンポーネントに戻りましょう。 誰かがこの動作の開始をトリガーして停止し、目標を示し、目標を変更します。 しかし、誰ですか？



2）ターゲット選択のロジックはタワーの種類によって異なり、タワーだけでなく、クリプトもこの動作を使用するため、2つの論理コンポーネントを区別する必要があります。



最初のものは物理学で動作し、クリープがコライダートリガーに入るとすぐにターゲットキューに追加され、ターゲットが増加したと思われるイベントを作成します。 クリープが影響を受ける領域を離れたらすぐに、このターゲットをキューから削除し、キューからクリープを削除するイベントを作成します。



もちろん、この行動は家にとって過剰です。家は決して逃げることはありません。 まあ。 このインターフェイスをITriggerの将来のコンポーネントと呼びます。 2つのUnityメソッド：OnTriggerEnter / OnTriggerExit。







2番目の論理コンポーネントはこれらのイベントに応答し、IDamageDealer自体を使用して、選択したターゲットにダメージを与え、ダメージを止めます。







しかし、2番目のコンポーネントでターゲットを選択する方法は、タワーのタイプと、それがクリープであるかどうかによって異なりますか？ 単純なオプションは、いくつかの汎用SelectTargetメソッド（ターゲット選択ロジックのタイプ（タワータイプ、クリープ））です。ターゲット選択ロジックのタイプに応じて、それを選択します。 しかし、特にコンポーネントに関しては、汎用性が常に良いとは限りません。 インターフェース分離の原則を思い起こさせます。普遍的なものよりも少し具体的である方が良いです。 したがって、1つのITargetSelectorインターフェイスによって結合された、異なるターゲット選択動作用の異なるコンポーネントがあります。







KeepSelector：ターゲットとして家を選択します。

SimpleCreepSelector：リストの最初のターゲットを選択します。

WeakCreepSelector：最も弱いターゲットを選択して追加します。



したがって、ターゲット選択のコアゲームプレイメカニクスを拡張するのは簡単です（メカニクスは基本的なものです。タワーの違いはそれだけです）。 ただし、継承を使用して別のオプションを実行できます。 タワーのデフォルトロジックを備えた基本コンポーネントTargetSelectorがあります。 そして、KeepSelectorクラスとWeakCreepSelectorは、ターゲットのリストに追加する方法（これが家かクリープかを確認するため）とターゲットを選択する方法をオーバーライドします。



3）ゲームには次の動作を持つ2つのエンティティがあります：ダメージを受けると、ヒットポイントの数は彼が死ぬまで減少します。







HP <= 0の状態を確認するだけでよいのにIsDeadが必要なのはなぜですか？ 現在の実装でも、2か所で、クリープが停止した場合に状態を確認する必要があります。 したがって、DRYの単純な原則（繰り返さないでください）に従って、ロジックを複製しません。 そのため、他の条件が追加された場合にロジックを変更する方が簡単です。



将来的に損傷を適用する方法を簡単に拡張するために、別の補助コンポーネントにこの動作を与えます。







したがって、ダメージを適用する方法を継承およびオーバーライドすることなく、将来的にIHittableとIDamageDealerの2つのコンポーネントを組み合わせることができます。 IDamageDealerを実装する他のコンポーネントを割り当てることにより、動作を拡張することも簡単です。



4）1つのエンティティに移動動作があります：IRouteFollower。 プロパティ：WayPoints []、Speed;



5）ここで、負けと勝ちのロジックを処理するコンポーネントを特定する必要があります。家でIsDeadをチェックし、波数を考慮してすべてのクリープをチェックします。







実装ロジックでは、開始時にcryptスポーンメソッドを呼び出し、更新では、スポーンされたクリープからどれくらいのクリープが死んでいるかを確認し、ウェーブの数と現在のウェーブを考慮して、スポーンまたはプレイヤーが勝ったと言います。 また、家が破壊されているかどうかを確認します。破壊されている場合、プレイヤーは負けています。

4番目のステップ：実装

これで、ゲームの最初のバージョンの実装を作成できます。 しかし、誰かが尋ねます：「タワーとクリープクラス自体はどこですか？」

Unityでは、視覚的に構成されたプレハブ（さまざまな種類のタワー、クリープ、ハウス）、および論理的に（つまり、コンポーネントを追加して）構成します。 また、コンポーネントのプロパティを構成する必要があるため、個別のクラスを作成する必要はありません。 しかし、（OnTriggerEnter / OnTriggerExitでの反応について）クリープとは何か、ホームは何かを理解する必要があります。 Unityにはこの目的のためのタグがあります。 1つのゲームオブジェクトだけが1つのタグを持つことができるのはいらいらしますが、これは普通のことです。ユニバーサルオブジェクトを作成しないでください。



UMLダイアグラムコードを生成し、ダミーのスケルトンを取得して実装を始めましょう。 次に、コンポーネントの動作の実装を作成します。 特定の実装よりも抽象化を使用するほうがよいことを忘れないでください。ただし、これにより接続性が向上します。 私の実装の例は、 https ： //github.com/sountex/COPTDにあります。



できた そして今、ゲームプレイを拡大する方法-例えば、経済を追加する？ 今、あなたは地下室を殺すためにお金を得る必要があり、それを塔の建設に費やします。 クリープ動作の1つを実装するクラスに新しいプロパティを急いで追加しないでください。 クラス単独の責任の原則を想起し、この新しい動作を新しいコンポーネントに分離します。 殺すために稼いだ金額のデータを保存する動作を含む新しいコンポーネントを作成することにより、再利用に適したより良いソリューションを作成します。 再利用について少し。 たとえば、RTSには、建物にダメージを与えて奪うユニットもあります。 コンポーネント指向のアプローチと抽象化のおかげで、作成されたすべてのコンポーネントは、異なるジャンルのゲームで簡単に使用できます。

次のステップ：テスト

コンポーネントのセットとしてのゲームオブジェクトの動作をテストするには、BDD（動作駆動開発）を使用するのが最も便利です。 また、個別の単体テストコンポーネントをテストします。 しかし、これは別の問題です。