Unity3Dのコンポーネント間のメッセージシステムまたはソフトリンク

はじめに

この記事では、Unity3Dでゲームを開発する際のメッセージシステムに基づいたゲームロジックのコンポーネントの「ソフトコミュニケーション」の可能性の実装に関連するトピックについて説明します。



大部分の場合、エンジンが基本的な形で提供するツールでは、ゲームのコンポーネント間でデータ交換システムを完全に実装するには不十分であることは周知の事実です。 誰もが始める最も原始的なバージョンでは、オブジェクトのインスタンスを通じて情報を取得します。 このインスタンスは、シーンオブジェクトへの参照から関数の検索まで、さまざまな方法で取得できます。 これは便利ではなく、コードの柔軟性が失われ、プログラマーは「オブジェクトがシーンから消えた」から「オブジェクトが非アクティブになる」まで、多くの非標準のロジック動作を強制することになります。 とりわけ、記述されたコードの速度が低下する可能性があります。



問題の解決方法を検討する前に、その前提と基本的な用語について詳しく説明します。これについては以下で説明します。 そもそも、ソフトリンクとはどういう意味ですか。 この場合、ゲームロジックのコンポーネント間でデータが交換されるため、これらのコンポーネントは互いについてまったく何も知りません。 これに基づいて、シーンオブジェクトへの参照、または名前またはタイプによるシーン内のオブジェクトの検索は、「ハードリンク」を提供します。 これらの接続が連鎖して並んでいる場合、ロジックの動作を変更する必要がある場合、プログラマはすべてを再構成する必要があります。 推測するのは難しくないので、柔軟性はここでは臭いがしません。 もちろん、自動的にリンクを埋めるエディター拡張機能を作成できますが、これは別の問題、ゲームロジックのコンポーネントテストを解決しません。



上記の記述をより明確にするために、簡単な例を考えてみましょう。 球体ゲームのロジックには、武器、敵、弾丸など、いくつかの要素があります。 武器を発射した後、次の情報を取得する必要があります：弾丸が敵に当たったかどうか、当たった場合、それが敵にどれだけのダメージを与えたか、ダメージを与えた場合、敵が死んだかどうか。 さらに、この情報の一部を他のコンポーネント（たとえば、与えられたダメージの量、敵が持っている健康の量、武器の弾薬の量を表示するグラフィカルインターフェイスなど）に転送する必要があります。 これには、ショット、ヒット、アニメーションなどの対応するエフェクトの表示も含まれます。...関係と送信データの数を想像することは難しくありません。 ただし、これは「ハードリンク」に実装できます。ただし、弾丸のロジックをテストする必要がある場合、武器や敵がまだない場合、またはインターフェイスのロジックをテストできる場合はどうなりますが、武器のロジックまたは弾丸ではなく敵であるか、弾丸をロケット弾に置き換えたいと考えていました。 このような問題の解決策は、「ソフトコミュニケーション」システムを作成する必要性を決定したことです。これにより、存在しない場合でもさまざまなコンポーネントを簡単にシミュレートし、関連するコードを変更せずにそれらを変更できます。



「ソフトコミュニケーション」の実装の基本原則について詳しく説明します。 前述のように、2つのコンポーネントを「ソフトに」接続するには、一方から他方にデータを転送する必要があります。これにより、コンポーネントが互いについて何も知らないようになります。 これを確実にするために、リクエストではなく（オブジェクトのインスタンスを手に持って）データを受信する必要がありますが、通知メカニズムを使用します。 実際、これは、オブジェクト/コンポーネントでイベントが発生したときに、このオブジェクトにその状態を問い合わせず、オブジェクト自体が変更が発生したことを通知することを意味します。 そのような通知のセットはインターフェースを形成し（C＃のインターフェースと混同しないでください）、ゲームロジックがオブジェクトに関するデータを受信するのを助けます。 これは次のように視覚化できます。







したがって、通知インターフェイスを介してシステムのどのコンポーネントもゲームロジックのオブジェクトに関する必要なデータを受信できますが、オブジェクト自体の存在はそれに関連付けられたコンポーネントをテストするために必要ではありませんが、インターフェイスを実装し、それを作業インスタンスに置き換えるだけです。



上記のメカニズムを実装する方法、およびそれらの長所と短所をより詳細に検討してみましょう。

UnityEvents / UnityActionメッセージングシステム

このシステムは比較的最近登場しました（Unity3Dエンジンのバージョン5）。 このリンクでは、簡単なメッセージングシステムの実装方法の例を見つけることができます。



この方法を使用する長所：

• 組み込みのUnity機能。

短所：

• Unityに組み込まれた機能（常にネイティブシステムが優れているとは限りません）。
• UnityActionを使用しているため（これは回避できますが）、パラメーターの数に制限があります（最大4つ）ため、柔軟性がありません。
• コードの多くの場所でタイプ、ハンドラーなどを変更する必要があるため、メッセージのパラメーターを変更するのが難しいため、柔軟性がありません。
• C＃にイベント/デリゲートがある場合に使用する理由は明確ではありません。

イベント/デリゲートのクラシカルC＃システム

通知ベースのコンポーネント通信を実装する最も簡単で効果的な方法は、C＃言語の一部であるイベント/デリゲートペアを使用することです（詳細については、habrまたはmsdnの記事を参照してください）。



イベント/デリゲートベースのメッセージングシステムを実装するためのさまざまなオプションがあり、その一部はインターネット上にあります。 私の意見では、最も便利なシステムの例を挙げますが、最初に、イベントの使用に関連する重要な詳細について言及します。 イベントにサブスクライバがない場合、このイベントが呼び出されるとエラーが発生するため、使用する前にnullチェックが必要です。 これは完全に便利というわけではありません。 もちろん、nullチェックが実行されるイベントごとにラッパーを作成できますが、これはさらに不便です。 実装に移りましょう。









例からわかるように、サブスクリプションはOnEnableメソッドで発生し、この場合もOnDisableでのサブスクライブ解除は必須です。そうしないと、オブジェクトがゲームから削除された場合にメモリリークとnull参照例外が保証されます。 サブスクリプション自体は必要なときにいつでも実行できます。OnEnableでのみこれを行う必要はありません。



このアプローチを使用すると、実際のGameLogicObjectロジックがなくても、 GUILogicクラスの動作を問題なくテストできることに気付くのは簡単です。 通知インターフェイスを使用し、 GameLogicObject.StartEvent （）の形式の呼び出しを使用するシミュレーターを作成するだけです。



この実装の利点は何ですか：

• C＃言語の標準メカニズム。タンバリンと踊らずに100％クロスプラットフォームであるため。
• システム実装の単純さ（コードへの追加投資なし）。

短所：

• メモリを監視する必要があります（通知からサブスクライブ解除）。 大量のコードを使用すると、1つのイベントのサブスクリプションを解除してから、長期間バグをキャッチするのを忘れがちです。
• シーンオブジェクトが一時的に非アクティブ化されている場合、イベントのサブスクライブを解除する必要があります。そうでない場合は、ハンドラーが呼び出されます。
• コードの多くの場所でタイプ、ハンドラー、呼び出しなどを変更する必要があるため、メッセージパラメーターの変更が難しいため、柔軟性がありません。
• イベントには購読者がいない場合があることに注意してください。

文字列の識別を備えた反射メッセージシステム

システムとその実装の説明に進む前に、その作成を推進した前提について詳しく説明します。 私のアプリケーションでこれらのことを考える前に、上記のイベント/デリゲートベースのシステムを使用しました。 私が当時開発しなければならなかったプロジェクトは比較的単純で、実装の速度、テストでのバグの最小化、ゲームロジックの開発段階における人的要因の最大値の例外が必要でした。 これに基づいて、コンポーネント間のデータ交換に関するいくつかの要件が生まれました。

• イベントの自動サブスクリプション。
• メモリを監視する必要はありません（システムの自動クリーニング）。
• 加入者を監視する必要はありません。そうでない場合でもシステムは動作するはずです。

いくつかの考えの結果は、クラス/コンポーネントメソッドの属性を通じてリフレクションを使用するというアイデアの誕生でした。





GlobalMessanger.MessageHandler-メソッドがイベントハンドラーであることを通知する属性。 このメソッドが処理するイベントのタイプを判別するには、2つの方法があります（実際にはさらに多くの方法があります）。

1. 属性パラメーターでイベントのタイプを指定します。

    [GlobalMessanger.MessageHandler("CustomEvent")]
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. メソッド名にプレフィックス「On」（またはその他）を付けたイベントタイプを使用します。 私はこの特定のメソッドを使用します。100％の場合、混乱しないように、メソッドの名前がそのようになっているからです。

自動的にサブスクライブするには、再度、2つの方法があります。

1. オブジェクト上のすべてのコンポーネントを検索するスクリプトを使用し、リフレクションを介して、属性が含まれるメソッドを探します。 このスクリプトを手動で追加しないようにするには、必要なすべてのコンポーネントに配置するだけで十分です。

    [RequireComponent(typeof(AutoSubsciber))]
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   個人的には、この方法は体を動かす必要があるため、2番目の方法よりも便利ではありません。
   
   
2. MonoBehaviourクラスのラッパーを作成します。
   
   
   
   
   CustomBehaviour

    public class CustomBehaviour : MonoBehaviour { private BindingFlags m_bingingFlags = BindingFlags.Public | BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.FlattenHierarchy; protected void Subscribe(string methodName) { var method = this.GetType().GetMethod(methodName, m_bingingFlags); GlobalMessanger.Instance.RegisterMessageHandler(this, method); } protected void Unsubscribe(string methodName) { var method = this.GetType().GetMethod(methodName, m_bingingFlags); GlobalMessanger.Instance.UnregisterMessageHandler(this, method); } protected virtual void Awake() { var methods = this.GetType().GetMethods(m_bingingFlags); foreach(MethodInfo mi in methods) { if(mi.GetCustomAttributes(typeof(GlobalMessanger.MessageHandler), true).Length != 0) { GlobalMessanger.Instance.RegisterMessageHandler(this, mi); } } } }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

ご覧のとおり、このラッパーには、イベントのサブスクライブとサブスクライブ解除を可能にする2つのメソッドが含まれています（イベントのタイプはメソッド名から取得されます）。 ロジックの進行に合わせてイベントをサブスクライブする必要がある場合に必要です。 自動サブスクリプションはAwakeメソッドで実行されます。 イベントの登録解除は自動的に実行されますが、それについては後で詳しく説明します。





GlobalMessangerクラスは、Unityシングルトンに基づいてアクセスされる通常のUnityコンポーネントです。 同時に、このコンポーネント用に別のシーンオブジェクトが作成されます。このオブジェクトは内部にのみ存在し、シーンがアンロードされると削除されます。 イベントは文字列に基づいて識別されるため、イベントとサブスクライバーに関する情報をハッシュテーブルに保存することにしました。







ご覧のとおり、イベントが呼び出されると、オブジェクトの存在とオブジェクトのアクティビティがチェックされます。 最初のケースでは、削除されたオブジェクトはサブスクライバーから削除されます; 2番目のケースでは、イベント処理メソッドを呼び出すときに無視されます。 したがって、リモートオブジェクトからのイベントのサブスクライブ解除を監視する必要はなく、すべてが自動的に行われます。 この場合、オブジェクトが一時的に非アクティブ化された場合、イベントからサブスクライブ解除して再サブスクライブするだけでなく、呼び出し時に、イベントのサブスクライバーの存在は必要ありません。





上記のシステムは特別なものではなく、啓示をもたらさないことは容易にわかりますが、シンプルで便利であり、比較的小さなプロジェクトに適しています。





イベント/デリゲートに比べてコードがどれだけ削減されているかがすぐにわかると思います。



この実装の利点は何ですか：

• イベントの自動サブスクリプション。
• イベントの購読解除を追跡する必要はありません（手動購読の場合でも）。
• 比較的単純な実装。
• 属性により、コードを簡単に読み取ることができ、誰がイベントハンドラーであり、どのハンドラーであるかを簡単に確認できます。
• イベント/デリゲートに比べて少ないコード
• イベントに購読者がいないと考える必要はありません。

短所：

• 非常に大きなプロジェクトでは、イベントのサブスクライブ解除は遅延モードで発生するため、おそらく余分なメモリを消費しますが、イベント/デリゲートのセクションで示した方法と同様に、手動でイベントをサブスクライブ解除することで簡単に解決できます。
• イベント名をより美しくしたい場合は、多くの場所で変更する必要があるため、文字列へのバインド。
• パラメーターとイベントデータの種類に柔軟性はありません。変更にはコードに対する多くのアクションが必要です。
• リフレクションの使用により、クロスプラットフォームの問題が発生する可能性があります。

データ型の識別を備えたリフレクションメッセージシステム

前のセクションでは、システムはイベント/デリゲートと比較して（私の意見では）より便利であると説明されましたが、コードの柔軟性に大きく影響するいくつかの欠点がまだあるため、次のステップはこれらの要因を考慮した開発でした。



そのため、以前のシステムのすべての利点を維持する必要がありますが、ゲームロジックの変更に対する柔軟性と耐性を高める必要があります。 主な問題はイベントの名前と送信されたパラメータの変更であるため、それらによってイベントを正確に識別するというアイデアが生まれました。 実際、これは、コンポーネントで発生するイベントは、送信するデータのみによって特徴付けられることを意味します。 多くのコンポーネントがそのようなデータをロジックで送信できるため、単純に標準型（int、floatなど）に添付することはできないため、論理ステップは、便利で読みやすく、明確に解釈できるラッパーを作成することでしたイベント。





ご覧のとおり、イベントには属性があります。 これにより、イベントにサブスクライバーが必要な場合にデバッグ情報を取得する機会が与えられますが、何らかの理由でコードに含まれていません。



以前にGlobalMessangerクラスの一部であったCallイベント（およびそのオーバーロード）を呼び出すメソッドは静的になり、 GEvents.BaseEventに配置され、イベントのタイプを記述するクラスのインスタンスを引数として受け取ります。





イベントのサブスクライブおよびサブスクライブ解除は、メソッドの属性を介して以前と同じ方法で実行されますが、イベントのタイプの識別は文字列値（メソッド名または属性パラメーター）ではなく、メソッドパラメーターのタイプ（この例ではStartEventクラス）によって行われますChangeHealthEventおよびDeathEvent）。





したがって、上記の実装を使用すると、大幅なコストをかけずにイベントで送信データを変更できるため、新しいパラメーターのハンドラーの本体を変更するだけで十分であるため、コードの柔軟性を最大限に高めました。 イベントの名前（クラス名）を変更する場合、コンパイラは古いバージョンが使用されている場所を通知します。 この場合、ハンドラーメソッドの名前を変更する必要は完全になくなります。

まとめ

この記事では、主観に基づいて、通知に基づいてコンポーネント間でデータ交換システムを構築する方法をすべて説明しようとしました。 これらの方法はすべて、単純なモバイルプロジェクトから複雑なPCまで、さまざまなプロジェクトやさまざまな複雑さで使用されています。 プロジェクトで使用するシステムはユーザー次第です。



PS：この記事では、SendMessage関数に基づいたメッセージシステムの構築について、意図的に説明し始めませんでした。他のシステムと比較すると、利便性だけでなく、速度の面でも批判に耐えられないからです。