🧒🏾 🎆 🧖🏼 Visual Scriptingイベントおよび応答システムまたはUnity3Dの作成 👋🏽 💇🏻 ⛵️

はじめに

前回の記事では、通知に基づいてゲームロジックのコンポーネント間で「ソフト」通信を提供し、サブスクライブする方法を説明しました。一般的な意味では、そのような通知は、変数の変更からより複雑なものへのコンポーネントの作業で発生する、必要なアクションまたはイベントに送信できます。ただし、特定のイベントでは、委任することは推奨されない一連のアクションを実行する必要があります。最も単純な例はサウンドデザインです。サウンドの伴奏を必要とするコンポーネントでイベントが発生しました。最も単純なバージョンでは、AudioSource.Play（）関数を呼び出しますが、もう少し複雑なものとして、サウンドシステムのラッパー関数を呼び出します。プロジェクトが小さく、チームに多くの役割を兼ね備えた人がほとんどいない場合、原則としてこれに問題はありませんが、複数のプログラマとサウンドデザイナーがいる大規模なプロジェクトの場合、特にサウンドのチューニングはプログラマに変わります悪夢。責任のあるスペシャリストが私たちではなくこれを行うとより正確になるので、コンテンツから抽象化してカスタマイズの観点から作業を少なくしようとするのは秘密ではありません。

上記の例は、音だけでなく、他の多くのものにも適用されます：アニメーション、エフェクト、GUI要素を使用したアクションなど。これらはすべて、比較的大きなプロジェクトでは大きな問題を表しています。仕事中に何度も出くわしましたが、コンテンツ管理はデザイナーから完全に切り離されていたため、基本的にすべての決定は仕事を促進することになりました。これは本質的に行き止まりのオプションです。結局、プログラマーの関与を最小限に抑えて、担当者がそのようなことを管理できるようなシステムを考案することが決定されました。この記事では、このシステムについて説明します。

イベントとフィードバック

ちょっとした紹介

プログラマーの観点から、ゲームプレイが何であるかは誰にも秘密ではないと思います。ただし、読者が私の視点を理解できるように説明します。

したがって、ゲームプロセスの実装用に記述するすべてのコードは、最初はコンポーネントのセットであり、各コンポーネントは、ゲームワールドで発生し、ゲームワールドまたは他のコンポーネントに影響を与える多数のイベントのジェネレータです。最も単純なバージョンでは、ロジックはソースの基準に従ってグループ化されたイベントに応じてコンポーネントに分割されます：キャラクター、対戦相手、インターフェイス、インターフェイスウィンドウなど。ただし、イベント自体はまだゲームプレイを形成していないため、イベントに応じて必要なアクション（応答）を実行する必要があります。たとえば、キャラクターが一歩踏み出し、対応するイベントを生成した場合、それに応じてサウンドを再生し、足の下からほこりの効果を再生し、カメラを振る必要があります。より複雑なバージョンでは、イベントに応じて実行されるアクションも新しいイベントを生成できます。これを「サウンドウェーブエフェクト」と呼びます。したがって、ゲームプロセスの「表面」は、一連のイベントと応答として形成されます。

ほとんどの場合、上記のメカニズムはコードで直接形成されますが、前述のように、多くのイベントは、ゲームのアニメーションと認識を提供するコンテンツに関連付けることができます（そして、アーティストとデザイナーが担当する部分）。間違ったプロジェクト管理プロセスとゲーム制作への間違ったアプローチにより、これらのタスクのほとんどはプログラマーを犠牲にして解決されます。アーティストは怠け者です-プログラマーは「ハック」を書いて、すべてがうまくいくでしょう。ロシアのゲーム開発者の誕生の時期には良かったのですが、品質、速度、柔軟性が必要になったので、私は別の方法に進むことにし、この方法はUnity Editorに接続されました

拡張機能

アーキテクチャに関するいくつかの言葉

以下は、イベントと応答のメカニズムを実装するために必要な基本要素を示す小さなブロック図です。これにより、設計者はゲームロジックの特定の要素を独自に構成できます。

したがって、システムの基本要素は、 EventPoint （コンポーネント内のイベントポイント）とAction （イベントへの応答）です。これらの各要素には、エディター拡張機能、この場合はカスタムインスペクターを使用して実装される特別なエディターを構成する必要があります（これについては、別のセクションで説明します）。

基本的なシナリオでは、各イベントポイントは1つの応答ではなく多数を生成でき、各応答はイベントジェネレーターであり、それらへのエントリポイントを含むこともできます。さらに、応答はUnity3Dエンジンの基本エンティティを処理できる必要があります。

上記に基づいて、最も簡単なオプションは、 ActionをMonoBehaviour の相続人にし、標準のUnity3Dメカニズムでシリアル化する必要があるパブリックフィールドの形でEventPointをコンポーネントロジックの一部にすることであると判断しました。

これらの要素について詳しく見てみましょう。

イベントポイント

[Serializable] public class EventPoint { public List<ActionBase> ActionsList = new List<ActionBase>(); public void Occurrence() { foreach (var action in ActionsList) { action.Execute(); } } }

コードからわかるように、すべてが非常に簡単です。 EventPointは基本的に、それに関連付けられた一連のアクションを格納するリストです。 Occurence関数を呼び出すと、コードにイベントポイントが入力されます。 ActionsListは、Unity3Dツールを使用してシリアル化できるようにパブリックフィールドになります。

コードで使用

 public class CustomComponent : MonoBehaviour { [HideInInspector] public EventPoint OnStart; void Start () { OnStart.Occurrence(); } }

前述のように、アクションはMonoBehaviourの相続人である必要があり、イベントのポイントはそれが引き起こす応答の種類を問わないため、このクラスを抽象としてラップします。

アクションベース

 public abstract class ActionBase : MonoBehaviour { public abstract void Execute(); }

控えめで原始的。イベントポイントを入力するときに応答ロジックをトリガーするには、 Execute関数が必要です。

これで、応答を実装できます（例-シーンオブジェクトのオン/オフ）

 public class ActionSetActive : ActionBase { public GameObject Target; public bool Value; public override void Execute() { Target.SetActive(Value); } }

システムの基礎が完全に単純であり、一般にプリミティブであることを認識することは難しくありません。すべての問題は、インスペクターに関連付けられたシステムの視覚部分の実装が原因です。詳細については、以下をご覧ください。

エディター

編集者の実装コードの分析に進む前に、私たちが何を目指しているかを視覚的に示し、それを実現する方法を検討します。以下は、イベントポイントとそれらへの応答を含む検査官の画像です。

順番に始めましょう：

コンポーネントのインスペクターオーバーライド。

柔軟性が必要なため、イベントポイントのインスペクターでエディターのオーバーライドを統合する方法は2つあります。

特定のプロパティタイプのインスペクターオーバーライド（この場合はEventPoint ）
コンポーネント全体のインスペクターをオーバーライドします（この場合、 MonoBehaviourの継承者 ）

一般に、両方のオプションが受け入れられます。インスペクターでコンポーネントのパブリックフィールドを表示するための望ましい順序を設定できるため、2番目のオプションを選択しました。

MonoBehaviourのすべての相続人のためのカスタムエディター

 [CustomEditor(typeof(MonoBehaviour), true)] public class CustomMonoBehaviour_Editor : Editor { //    }

応答の取得と一覧表示

システムをできるだけ柔軟にするために、実装したすべての応答（ ActionBaseから派生したクラス）をインスペクターに表示し、リストから簡単に選択してイベントポイントに追加する必要があります。

次のように実装されます

 void OnEnable() { var runtimeAssembly = Assembly.GetAssembly(typeof(ActionBase)); m_actionList.Clear(); foreach (var checkedType in runtimeAssembly.GetTypes()) { if (typeof(ActionBase).IsAssignableFrom(checkedType) && checkedType != typeof(ActionBase)) { m_actionList.Add(checkedType.FullName, checkedType); } } }

ご覧のとおり、ActionBaseからすべての子孫のリストを取得し、リスト自体からアセントを除外します。応答名はクラス名から取得されます。ここでは、より複雑な方法でクラス属性を介して名前を取得し、属性を介して短い説明を指定して応答することができます。クラスに詳細に名前を付けたので、私はより単純な方法を採用することにしました。

イベントポイントとコンポーネントのパブリックフィールドのリスト

イベントポイントのみを出力する方法を再定義する必要があるため、インスペクターの描画関数は次の形式を取ります。

インスペクターGUIレンダリング関数

 public override void OnInspectorGUI() { serializedObject.Update(); base.OnInspectorGUI(); //          FindAndEditEventPoint(target); //    serializedObject.ApplyModifiedProperties(); }

イベントポイントを見つけるための関数（EventPoints）

 void FindAndEditEventPoint(UnityEngine.Object editedObject) { var fields = editedObject.GetType().GetFields(); foreach (var fieldInfo in fields) { if (fieldInfo.FieldType == typeof(EventPoint)) { EventPointInspector(fieldInfo, editedObject); //   } } }

このコードを見たときに生じる主な疑問は、 SerializedPropertyではなく、リフレクションが使用される理由です。理由は簡単です。MonoBehaviourのすべての相続人に対してインスペクターを再定義するため、コンポーネントフィールドの名前とそれらの型の関係についてはわからないため、 serializedObject.FindProperty（）関数を使用できません。

次に、イベントポイントのインスペクターの即時レンダリングについて説明します。ここではすべてが非常に単純なので、コード全体を説明しません。FoldOutスタイルは、応答に関する情報の折りたたみと展開に使用されます。キーポイントについて説明しましょう。

EventPointインスタンスデータの取得

 var eventPoint = (EventPoint)eventPointField.GetValue(editedObject);

応答をリストし、それらをイベントポイントに追加する

 var selectIndex = EditorGUILayout.Popup(-1, actionNames.ToArray()); if (selectIndex >= 0) { var actionType = m_actionList[actionNames [selectIndex]]; var actionObject = (ActionBase)((target as Component).gameObject.AddComponent(actionType)); eventPoint.ActionsList.Add(actionObject); }

応答のインスペクター（アクション）

上記のコードからわかるように、応答はコンポーネントにオブジェクトとして追加されます。このようなアクションの結果、このクラスはインスペクターウィンドウに表示され、それに応じて処理されます（すべてのフィールドが表示されるなど）。パラメータの設定に関するすべての操作を1か所で行うため、これは便利ではありません。まず、Unityがインスペクターに応答クラスパラメーターを表示するのを無効にします。

これは、ActionBaseのすべての子孫のエディターをオーバーライドすることにより行われます。

 [CustomEditor(typeof(ActionBase), true)] public class ActionBase_Editor : Editor { public override void OnInspectorGUI() {} }

これで、イベントポイントに対して再定義したインスペクターで応答クラスのフィールドを表示できます（基本コード、スタイルの追加方法（FoldOut）、説明する必要はないと思います）

 var destroyingComponent = new List<ActionBase>(); for (var i = 0; i < eventPoint.ActionsList.Count; i++) { EditorGUILayout.BeginHorizontal(); ActionBaseInspector(eventPoint.ActionsList[i]); //     ,    if (GUILayout.Button("-", GUILayout.Width(25))) { destroyingComponent.Add(eventPoint.ActionsList[i]); } EditorGUILayout.EndHorizontal(); }

応答（アクション）の削除は次のとおりです

 foreach (ActionBase action in destroyingComponent) { RecursiveFindAndDeleteAction(action); eventPoint.ActionsList.Remove(action); GameObject.DestroyImmediate(action); } void RecursiveFindAndDeleteAction(object obj) { var fields = obj.GetType().GetFields(); var destroyingComponent = new List<ActionBase>(); foreach (var fieldInfo in fields) { if (fieldInfo.FieldType == typeof(EventPoint)) { var eventPoint = (EventPoint)fieldInfo.GetValue(obj); destroyingComponent.AddRange(eventPoint.ActionsList); eventPoint.ActionsList.Clear(); } } foreach (ActionBase action in destroyingComponent) { RecursiveFindAndDeleteAction(action); GameObject.DestroyImmediate(action); } }

システムはイベントと応答のチェーンの長さに制限はありませんが（これは可能ですが）、チェーンの開始または中間での応答の削除には、より低いすべての応答の削除が伴う必要があります。オブジェクトのコンポーネントを含むすべてのものを削除し、ベースレスポンスを削除します。

注：

ここに、私がまだ克服できない最も奇妙な瞬間があります：Unityがエディターを介してオブジェクトからコンポーネントを削除するためにDestroyImmediateを使用することを推奨しているにもかかわらず、エディターでMissingReferenceExceptionエラーが発生します。ただし、コードの正しい動作には影響しません。バグは私のものかUnityであり、私はまだそれを解明しようとしています。誰かが問題を知っているなら、コメントに書いてください。

応答を実装するクラスのフィールドの描画（アクション）

前述のように、フィールド名は使用できず、 serializedObjectは応答に使用できないため、コードでserializedObject.FindProperty（）を使用できません。したがって、 EventPointのように、リフレクションが使用され、これが最も不便ですシステム全体の瞬間。

応答のインスペクターを描く

 void ActionBaseInspector(ActionBase action) { var fields = action.GetType().GetFields(); EditorGUILayout.BeginVertical(); EditorGUILayout.Space(); EditorGUILayout.Space(); EditorGUILayout.Space(); foreach (FieldInfo fieldInfo in fields) { if (fieldInfo.FieldType == typeof(int)) { var value = (int)fieldInfo.GetValue(action); value = EditorGUILayout.IntField(fieldInfo.Name, value); fieldInfo.SetValue(action, value); } else if (fieldInfo.FieldType == typeof(float)) { var value = (float)fieldInfo.GetValue(action); value = EditorGUILayout.FloatField(fieldInfo.Name, value); fieldInfo.SetValue(action, value); } // ..   ,      } FindAndEditEventPoint(action); //        . EditorGUILayout.EndVertical(); }

ご覧のとおり、必要なすべてのフィールドタイプについて、ペンを使用してエディターの出力を決定する必要があります。一方で、これはブリキであり、他方で、フィールドエディターを再定義することができます。これは、たとえばサウンドに使用します。

まとめ

システム全体を見ると、複雑なことは何もありませんが、それがもたらす利点は単に匹敵するものではありません。時間とエネルギーの節約は巨大です。実際、プログラマーは、デザイナーからの要求に応じて、イベントポイントとその入り口を作成する必要があります。そして、いわゆる「手を洗う」と呼ばれるものももちろん、応答コードを記述する必要があります。ここではすべてが想像力によってのみ制限されます。大きな複雑なことをすることができ、小さな単音節をたくさんすることができます。

記事の冒頭で、イベント処理を他のコンポーネントに委任することは実用的ではないことを説明しましたが、実際、これにはパイプラインの観点から利点があります。メッセージシステム（前の記事を参照）を使用して、イベントポイントへの入力を作成できるようにするために、その処理に特化したコンポーネントを定義することができます。このようなコンポーネントを所定の場所に配置すると、設計者はオブジェクトの階層を精査する必要がなくなります。このアプローチは、たとえば、サラウンドサウンドの調整に使用できます。

前述のように、システムはイベントと応答の長いチェーンに限定されず、実際、デザイナーは動作の任意の大規模で複雑なロジック（ Visual Scriptingを参照）を作成できますが、実際には便利で読みにくいため、少なくともチェーンを制限することをお勧めします口頭手配。私たちの仕事の過程で、私のパートナーと私はそのようなチェーンを拡張バージョンで使用しました-そこで、編集のために別のウィンドウ（ EdtiorWindow ）を使用しました。ロジックに複雑な分岐を作成する必要が生じるまで、すべてが順調でした。この混乱でしばらくして理解することは、単に非現実的でした。それが私のシステムで、インスペクターに基づいた単純なソリューションの側面に行った理由です。

全体的なVisual Scriptingに関して、Unityコンポーネントを介したイベントと応答のアプローチおよびそれらの実装には独自の利点があり、最終的に、パートナーと私は、いくつかのプロジェクトでの作業の過程で、本格的なビジュアルロジックエディターを開発することにしました。これから出てきたのは別の記事のトピックであり、結論として、uGUIの例を使用して、説明したシステムの動作を示す短いビデオを提供したいと思います。

https://youtu.be/sfZ9Tf_EVYE

Visual Scriptingイベントおよび応答システムまたはUnity3Dの作成