Unity3Dでスクリプト間の相互作用を整理する方法

エントリー

平均的なUnity3Dプロジェクトでさえ、非常に迅速に多種多様なスクリプトで満たされ、これらのスクリプトが相互にどのように相互作用するかという疑問が生じます。
この記事では、このような相互作用を単純なものから高度なものまで体系化するためのいくつかの異なるアプローチを提供し、各アプローチがもたらす問題を説明し、これらの問題を解決する方法を提案します。

アプローチ1. Unity3Dエディターによる割り当て

プロジェクトに2つのスクリプトがあるとします。 最初のきしみはゲーム内のポイントのスコアリングを担当し、2番目のきしみはゲーム画面で得点したポイントの数を表示するユーザーインターフェイスを担当します。
両方のスクリプトマネージャー、ScoresManagerとHUDManagerを呼び出します。
それでは、スクリーンメニューを担当するマネージャーは、ポイントの獲得を担当するマネージャーから現在のポイント数をどのように受け取ることができますか？
シーンのオブジェクトの階層（階層）には2つのオブジェクトがあり、1つにScoresManagerスクリプトが割り当てられ、もう1つにHUDManagerスクリプトが割り当てられていると想定されています。
1つのアプローチには、次の原則が含まれます。
UIManagerスクリプトで、ScoresManagerタイプの変数を定義します。

public class HUDManager : MonoBehaviour { public ScoresManager ScoresManager; } 

ただし、ScoresManager変数はクラスのインスタンスで初期化する必要があります。 これを行うには、オブジェクト階層でHUDManagerスクリプトが割り当てられているオブジェクトを選択します。オブジェクト設定では、値NoneのScoresManager変数が表示されます。



次に、階層ウィンドウから、ScoresManagerスクリプトを含むオブジェクトをNoneが書き込まれている領域にドラッグし、宣言された変数に割り当てます。



その後、HUDManagerコードからScoresManagerスクリプトにアクセスする機会があります。

 public class HUDManager : MonoBehaviour { public ScoresManager ScoresManager; public void Update () { ShowScores(ScoresManager.Scores); } } 

シンプルですが、ゲームはポイントを獲得するだけでなく、HUDはプレーヤーの現在の生活、利用可能なプレーヤーアクションのメニュー、レベル情報などを表示できます。 ゲームには、互いに情報を受信する必要のある数十から数百の異なるスクリプトを含めることができます。
1つのスクリプトで別のスクリプトからデータを取得するには、1つのスクリプトで変数を記述し、エディターを使用して変数を手動で割り当て（ドラッグアンドドロップ）する必要があります。 。
何かをリファクタリングしたい場合は、スクリプトの名前を変更すると、名前が変更されたスクリプトに関連付けられたオブジェクトの階層内のすべての古い初期化がリセットされ、再度割り当てる必要があります。
同時に、そのようなメカニズムは、プレハブ（テンプレートからのオブジェクトの動的作成）では機能しません。 プレハブがオブジェクトの階層にあるマネージャーにアクセスする必要がある場合、階層からプレハブ自体に要素を割り当てることはできませんが、最初にプレハブからオブジェクトを作成してから、プログラムでマネージャーインスタンスを新しく作成されたオブジェクトの変数に割り当てる必要があります。 不要な作業、不要なコード、追加の接続性。
次のアプローチは、これらすべての問題を解決します。

アプローチ2.シングルトン

ゲームの作成に使用される可能性のあるスクリプトの簡略化された分類を適用します。 最初のタイプのスクリプト：「scripts-managers」、2番目のタイプ：「scripts-game-objects」。
他のいくつかの主な違いは、「スクリプトマネージャー」は常にゲーム内で単一のインスタンスを持ちますが、「スクリプトゲームオブジェクト」は複数のインスタンスを持つことができることです。

例

原則として、単一のコピーには、ユーザーインターフェイスの一般的なロジック、音楽の再生、レベル完了条件の監視、タスクシステムの管理、特殊効果の表示などを担当するスクリプトがあります。
同時に、ゲームオブジェクトのスクリプトは多数のインスタンスに存在します。「Angry Birds」の各鳥は、固有の状態を持つ鳥スクリプトのインスタンスによって制御されます。 戦略のどのユニットについても、ユニットスクリプトのインスタンスが作成され、その中には現在のライフ数、フィールド上の位置、個人的な目標が含まれます。 5つの異なるアイコンの動作は、この動作を担当する同じスクリプトの異なるインスタンスによって提供されます。
前のステップの例では、HUDManagerおよびScoresManagerスクリプトは常に単一のインスタンスに存在します。 相互作用のために、「シングルトン」パターン（シングルトン、別名ローン）を適用します。
ScoresManagerクラスでは、ScoresManager型の静的プロパティを記述します。このプロパティには、ポイントマネージャーの単一のインスタンスが格納されます。

 public class ScoresManager : MonoBehaviour { public static ScoresManager Instance { get; private set; } public int Scores; } 

Unity3D環境を作成するクラスのインスタンスでInstanceプロパティを初期化することは残ります。 ScoresManagerはMonoBehaviourの継承者であるため、シーン内のすべてのアクティブなスクリプトのライフサイクルに参加し、スクリプトの初期化中にAwakeメソッドが呼び出されます。 このメソッドでは、Instanceプロパティの初期化コードを配置します。

 public class ScoresManager : MonoBehaviour { public static ScoresManager Instance { get; private set; } public int Scores; public void Awake() { Instance = this; } } 

その後、次のように他のスクリプトからScoresManagerを使用できます。

 public class HUDManager : MonoBehaviour { public void Update () { ShowScores(ScoresManager.Instance.Scores); } } 

これで、HUDManagerがScoresManagerタイプのフィールドを記述してUnity3Dエディターで割り当てる必要がなくなり、「スクリプトマネージャー」は、Awake関数で初期化される静的インスタンスプロパティを介して自身へのアクセスを提供できます。

長所

-スクリプトフィールドを説明し、Unity3Dエディターで割り当てる必要はありません。
-コードを安全にリファクタリングできます。何かが落ちた場合は、コンパイラが通知します。
-Instanceプロパティを介して、プレハブから他の「スクリプトマネージャー」にアクセスできるようになりました。

短所

-このアプローチでは、単一のコピーに存在する「スクリプトマネージャー」のみにアクセスできます。
-強いつながり。
最後の「マイナス」でより詳細に説明します。
キャラクター（ユニット）がいて、これらのキャラクターが死ぬ（ダイ）ことができるゲームを開発しましょう。
どこかに、キャラクターが死んでいるかどうかを確認するコードの一部があります。

 public class Unit : MonoBehaviour { public int LifePoints; public void TakeDamage(int damage) { LifePoints -= damage; if (LifePoints <= 0) Die(); } } 

ゲームはキャラクターの死にどのように対応できますか？ 多くの異なる反応！ いくつかのオプションを紹介します。
-キャラクターをゲームシーンから削除して、キャラクターが登場しないようにする必要があります。
-ゲームでは、死んだキャラクターごとにポイントが付与されます。それらを獲得し、画面上の値を更新する必要があります。
-特別なパネルには、ゲーム内のすべてのキャラクターが表示され、特定のキャラクターを選択できます。 キャラクターが死んだとき、パネルを更新するか、パネルからキャラクターを削除するか、パネルが死んでいることを表示する必要があります。
-キャラクターの死の効果音を再生する必要があります。
-キャラクターの死の視覚効果（爆発、血しぶき）を再生する必要があります。
-ゲームのアチーブメントシステムには、常にキルされたキャラクターの総数をカウントするアチーブメントがあります。 死んだばかりのキャラクターをカウンターに追加する必要があります。
-ゲーム分析システムは、キャラクターの死の事実を外部サーバーに送信します。この事実は、プレイヤーの進行状況を追跡するために重要です。
上記のすべてを考慮すると、Die関数は次のようになります。

 private void Die() { DeleteFromScene(); ScoresManager.Instance.OnUnitDied(this); LevelConditionManager.Instance.OnUnitDied(this); UnitsPanel.Instance.RemoveUnit(this); SoundsManager.Instance.PlayUnitDieSound(); EffectsManager.Instance.PlaySmallExplosion(); AchivementsManager.Instance.OnUnitDied(this); AnaliticsManager.Instance.SendUnitDiedEvent(this); } 

彼の死後のキャラクターは、この悲しい事実に興味を持っているすべてのコンポーネントに送信する必要があり、これらのコンポーネントの存在を知り、彼らが彼に興味を持っていることを知っている必要があります。 小さなユニットには知識が多すぎますか？
ゲームは論理的に非常に関連性の高い構造であるため、他のコンポーネントで発生するイベントは3番目の関心事であり、このユニットは特別なものではありません。
そのようなイベントの例（決してすべてではない）：
-レベルを渡すための条件は、得点、1000ポイントを獲得したポイントの数に依存します-レベルを渡しました（LevelConditionManagerはScoresManagerに関連付けられています）。
-500ポイントを集めると、レベルを渡す重要な段階に到達します。楽しいメロディと視覚効果を再生する必要があります（ScoresManagerはEffectsManagerとSoundsManagerに関連付けられています）。
-キャラクターが健康を回復したら、キャラクターのパネルでキャラクターの写真に癒し効果をかける必要があります（UnitsPanelはEffectsManagerに関連付けられています）。
-など。
このような接続の結果、次のような写真になります。誰もがすべてのことを知っています。



キャラクターの死を伴う例は少し誇張されており、死（または他のイベント）を6つの異なるコンポーネントに報告する必要はあまりありません。 しかし、オプションは、ゲーム内のあるイベントで、イベントが発生した機能がこの2〜3個のコンポーネントについて通知するときに、コード全体に渡って見つかることです。
次のアプローチは、この問題を解決しようとします。

アプローチ3. World Aether（イベントアグリゲーター）

特別なコンポーネント「EventAggregator」を導入します。その主な機能は、ゲームで発生するイベントのリストを保存することです。
ゲーム内のイベントは、他のコンポーネントに自分自身にサブスクライブし、このイベントの発生の事実を公開する機会を提供する機能です。 イベント機能の実装は、開発者にとって好みに応じて行うことができます。標準言語ソリューションを使用するか、独自の実装を作成できます。
過去の例のイベントの単純な実装例（ユニットの死について）：

 public class UnitDiedEvent { private readonly List<Action<Unit>> _callbacks = new List<Action<Unit>>(); public void Subscribe(Action<Unit> callback) { _callbacks.Add(callback); } public void Publish(Unit unit) { foreach (Action<Unit> callback in _callbacks) callback(unit); } } 

このイベントを「EventAggregator」に追加します。

 public class EventAggregator { public static UnitDiedEvent UnitDied; } 

これで、前の8行の例のDie関数が単一行関数に変換されます。 関心のあるすべてのコンポーネントに対してユニットが死亡したことを報告する必要はありません。 イベントの事実を公開するだけです。

 private void Die() { EventAggregator.UnitDied.Publish(this); } 

また、このイベントに関心のあるコンポーネントは、次のように応答できます（たとえば、得点の数を担当するマネージャー）。

 public class ScoresManager : MonoBehaviour { public int Scores; public void Awake() { EventAggregator.UnitDied.Subscribe(OnUnitDied); } private void OnUnitDied(Unit unit) { Scores += CalculateScores(unit); } } 

Awake関数では、マネージャーはイベントにサブスクライブし、このイベントの処理を担当するデリゲートを渡します。 イベントハンドラー自体は、死亡したユニットのインスタンスをパラメーターとして受け取り、このユニットのタイプに応じてポイント数を追加します。
同様に、ユニットの死亡イベントに関心がある他のすべてのコンポーネントは、イベントが発生したときにサブスクライブして処理できます。
その結果、各コンポーネントが互いを知っている場合、コンポーネント間の接続の図は、コンポーネントがゲームで発生するイベント（それらが関心のあるイベントについてのみ）を知っているときに図に変わりますが、これらのイベントがどこから来たかは気にしません。 新しいグラフは次のようになります。



私は別の解釈が大好きです。「EventAggregator」長方形がすべての方向に伸び、それ自体の内側にある他のすべての長方形をキャプチャして、世界の境界になったと想像してください。 私の頭の中で、この図では、EventAggregatorはまったくありません。 「EventAggregator」は単なるゲームの世界であり、一種の「ゲームブロードキャスト」であり、ゲームのさまざまな部分が「Hey people！ そのような部隊は死にました！」そして誰もが放送を聞いており、聞いた出来事のどれかが彼らに興味があるなら、彼らはそれに反応します。 したがって、接続はなく、各コンポーネントは独立しています。
私がコンポーネントであり、何らかのイベントの発行を担当している場合、私はこれが死んだこと、これがレベルを獲得したこと、シェルが戦車に当たったことを叫んでいます。 そして、誰かがそれを気にするかどうかは気にしません。 おそらくこのイベントを誰も聞いていないか、他の何百ものオブジェクトがサブスクライブされている可能性があります。 私は、イベントの著者として、1グラムについては気にしません。それらについては何も知りませんし、知りたくありません。
このアプローチにより、古い機能を変更せずに新しい機能を簡単に導入できます。 完成したゲームにアチーブメントシステムを追加することにしたとします。 達成システムの新しいコンポーネントを作成し、関心のあるすべてのイベントにサブスクライブします。 他のコードの変更はありません。 他のコンポーネントに目を通す必要はありません。それらからアチーブメントシステムを呼び出して、彼女に言ってください、私のイベントをカウントしてください。 さらに、世界でイベントを公開するすべての人は、達成システムについても、その存在の事実についても何も知りません。

発言

他のコードは変わらないと言って、もちろん私は少し不誠実です。 アチーブメントシステムは、以前はゲームに公開されていなかったイベントに関心があることが判明する場合があります。 この場合、どの新しいイベントをゲームに追加し、誰がそれらを公開するかを決定する必要があります。 しかし、理想的なゲームでは、考えられるすべてのイベントがすでにそこにあり、エーテルはそれらでいっぱいになります。

長所

-コンポーネントは接続されていません。イベントを公開するだけで十分であり、興味のある人は関係ありません。
-コンポーネントは接続されていません。必要なイベントをサブスクライブするだけです。
-既存の機能を変更せずに個々のモジュールを追加できます。

短所

-新しいイベントを絶えず説明し、世界に追加する必要があります。
-機能原子性の違反。

最後のマイナスを詳細に検討する

MethodAメソッドが呼び出されるObjectAオブジェクトがあるとします。 MethodAメソッドは3つのステップで構成され、これらのステップを順次実行する他の3つのメソッド（MethodA1、MethodA2、およびMethodA3）自体を呼び出します。 2番目のメソッドMethodA2では、イベントが公開されます。 そして、ここで次のことが起こります：このイベントにサブスクライブしているすべての人は、それを処理し始め、独自の何らかのロジックを実行します。 このロジックでは、他のイベントの発行も発生する可能性があり、その処理は新しいイベントの発行などにもつながる可能性があります。 場合によっては、出版物や反応のツリーが非常に大きくなることがあります。 このような長いチェーンは、デバッグが非常に困難です。
ただし、ここで発生する可能性のある最悪の問題は、チェーンのブランチの1つが「ObjectA」に戻り、他のMethodBメソッドを呼び出してイベントの処理を開始する場合です。 MethodAメソッドは、2番目のステップで中断され、無効な状態が含まれているため、MethodAメソッドはまだすべてのステップを完了していないことがわかります（ステップ1および2では、オブジェクトの状態を変更しましたが、ステップ3からの最後の変更はまだ完了していません完了）と同時に、同じオブジェクトで「MethodB」の実行が開始され、この無効な状態になります。 そのような状況はエラーを引き起こし、キャッチするのが非常に難しく、ロジックがこれを行う必要がなく、回避したい追加の複雑さを導入する場合、メソッド呼び出しとイベントの発行の順序を制御する必要があるという事実につながります。

解決策

説明した問題を解決することは難しくありません。イベントに遅延反応の機能を追加するだけです。 このような機能の簡単な実装として、発生したイベントを追加するリポジトリを作成できます。 イベントが発生しても、すぐに実行するのではなく、単に自宅のどこかに保存します。 また、ゲーム内の一部のコンポーネントの機能実行の切り替え時に（たとえば、Updateメソッドで）、発生したイベントの存在を確認し、そのようなイベントがある場合は処理を実行します。
したがって、MethodAメソッドの実行中、その中断は発生せず、すべての関係者は公開されたイベントを特別なリポジトリに自分自身に書き留めます。 そして、キューが関心のあるサブスクライバーに到達した後にのみ、ストレージからイベントを取得して処理します。 この時点で、MethodA全体が完了し、ObjectAは有効な状態になります。

おわりに

コンピューターゲームは、互いに密接に相互作用する多数のコンポーネントを持つ複雑な構造です。 この相互作用を整理するための多くのメカニズムを考えることができますが、私はイベントに基づいて説明したメカニズムを好みます。 誰かがそれを気に入ってくれて、私の記事が明確になり、役に立つことを願っています。