Unite Europe 2016：レポートのレビュー「輝かしいScriptableObject革命におけるMonoBehavior専制政治の打倒」

最近、 Unite Europe 2016カンファレンスでアムステルダムを訪問しました。そこでは、多くの感情と興味深い経験を受け取りました。 この会議では、さまざまな方向とさまざまなレベルの複雑さに関する興味深いレポートがたくさんありました。 スピーチの1つのテーマは、「栄光のScriptableObject革命におけるMonoBehavior専制政治の打倒」であり、Unity TechnologiesのスペシャリストであるRichard Fine（ https://twitter.com/superpig / https://github.com/richard-fine ）彼はScriptableObjectについて詳しく話し、それをプロジェクトに適用する方法を例で示しました。



リチャードは彼の報告書で、次の問題に取り組んだ。

• MonoBehaviour （以下、単にMB）がひどいのはなぜですか 。
• ScriptableObject （以下SO と呼びます ）とは何ですか？なぜそれが優れているのですか。
• SOの使用方法。
• SOの使用パターン。
• デモプロジェクトPimp My Tanksの例でのSOの実演（この記事では説明しません。レビュー用にhttps://bitbucket.org/richardfine/scriptableobjectdemoを確認できます）。

次は、リチャードが話していたことを無料で翻訳/語り直し、さまざまな追加を加えたものです。

タイラニーMB

MB一般情報：

• ほとんどのスクリプトはMBとして書き込まれます。
• これらはGameObject （以降GOと呼びます ）に添付されます 。
• シーンやプレハブに住んでいます。
• エンジンからいくつかのコールバックを取得します（Start、Updateなど）。

欠点は何ですか？

• playmodを終了するとリセットされます。
• インスタンス化時に、完全なコピーが作成されます。
• インスタンスはシーン間で「手探り」するのに不便です。
• インスタンスは、プロジェクト間で「手探り」するのに不便です。
• 不正なVCSグラニュレーション （シーンオブジェクトのスクリプトを変更すると、シーン全体が変更され、競合が頻繁に発生するなど）。
• 一貫性なくカスタマイズされる場合があります。 シーンに複数の同一のオブジェクトがある場合、それらの1つのプロパティを誤って変更する可能性があります。これは、検出が容易ではなく、ゲームデザインの観点からは完全に正しくありません。すべてのゲームオブジェクトが同じである場合、それらのプロパティは同じである必要があるためです この動作が便利な場合は例外がありますが、これらはよりまれなケースです。
• 概念的には完全に適切ではありません：非常に多くの場合、空間内の特定の位置にあるコンポーネント/オブジェクトではなく、インスペクターでネイティブおよび自動シリアル化の可能性があるクリーンなデータで操作する必要があります）

MBの専制から逃れるにはどうすればよいですか？

純粋な静的C＃クラス？

• playmodを終了してもリセットされます。
• それらを手動でシリアル化する必要があります。
• このようなクラス内では、Unityオブジェクトを操作するのは不便です。
• 私は自分の検査官を書かなければなりません。

しかし、結局のところ、不便を避けるためにこの「箱から出してすぐに」提供するエンジンを具体的に使用します！



プレハブはどうですか？

ストレージとシーン間およびプロジェクト間の転送の問題を解決し、VCSグラニュレーションに違反しません。 しかし、このソリューションには欠点もあります。

• たとえば、誤ってインスタンス化/シーンへのドラッグを行うことにより、すべてを簡単に破壊できます。
• 追加のコンポーネント（AudioSourceなど）が存在する場合がありますが、データはそのようなものから分離する必要があるため、なぜ必要なのでしょう！
• 概念的には、それはまだ理想的な解決策ではなく、おそらく許容可能な解決策ですが、...

ここで救助に来ます

SOは、スクリプトのサンプルに関係なく送信される大量の情報を保存できるクラスです。 GOにアタッチされないオブジェクトを作成する必要がある場合、このクラスから継承できます。



100万の整数の配列を持つスクリプトを備えたプレハブがあると想像してください。 アレイは4メガバイトのメモリを占有し、プレハブに属します。 このプレハブのインスタンスを作成するたびに、この配列のインスタンスも作成されます。 10個のゲームオブジェクトを作成すると、これらの10個のインスタンスの配列が占有するメモリのサイズは40メガバイトになります。



SOを使用する場合、結果は完全に異なります。 Unityは、すべてのタイプのプリミティブ、文字列、配列、リスト、Vector3などの特定のタイプ、および定義可能なオブジェクトに関連するコピーとしてSerializable属性を持つカスタムクラスをシリアル化します。 つまり、100万個の整数の配列が宣言されたSOクラスのインスタンスを作成すると、この配列はサンプルとともに送信されます。 この場合、彼らは異なるデータを持っていると信じています。 SOフィールド、またはMonoBehaviour、Mesh、GameObjectなどのUnityEngine.Objectフィールドは、値とは異なり、リンクに保存されます。 100万個の整数を含むSOを参照するスクリプトがある場合、UnityはスクリプトデータにSOへの参照のみを保存します。 SOは配列を格納します。 4メガバイトのメモリを使用するSOクラスを参照する10のプレハブインスタンスは、上記の40の代わりに4メガバイトを占有します。 これは、スクリプト内の多数のオブジェクトや大量のデータに関して特に重要です。



だからそう：

• これはMBのようなものですが、コンポーネントではありません（MBからではなくSOからカスタムクラスを継承する必要があります）。
• GO /プレハブに取り付けることはできません。
• MBのように、インスペクターでシリアル化して検査できます。
• .assetファイルに配置できます（テクスチャ/マテリアルなどを配置することでカスタムアセットを作成できます）。
• 多型のいくつかの問題を解決します。 Unityのシリアル化コードを詳しく見ると、継承の際に、すべてのものが正しくシリアル化できるわけではないことがわかります。SOの場合、このような問題はありません。

SOが問題から私たちを救う方法：

• アセットに保存すると、プレイモードを終了する際のリセットが防止されます。
• インスタンス化中に参照することはできますが、コピーすることはできません（メモリ消費が減少し、インスタンス化の速度が向上します）。
• 他のアセットと同様に、シーン間で使用したり、「揺れ動く」ことができます。
• プロジェクト間で「手探り」する方が簡単です。1つのアセットファイルを転送するだけで、階層全体を掘り下げて依存関係を探す必要はありません。
• 理想的なVCS​​グラニュレーション（1ファイル-1オブジェクト）。
• 追加の不要な部分はありません（例：変換）。

しかし、SOも完璧ではありません。

• 3つのコールバックのみ：OnEnable / OnDisable、OnDestroy。 この問題は、MBをプロキシとして使用して解決できますが。
• 実際、一般的なデータは完全に一般的なものではありません。 特定のエンティティに対しては変更できません。特定のエンティティには長所と短所があり、選択したフローに依存します。

SOの使用方法

SOクラスは、値のコピーを避けてメモリ消費を削減する必要がある場合に使用する必要があります。 ただし、含めるデータセットを決定するためにも使用できます。 レベル設定、グローバルゲーム設定、キャラクター/敵/建物などの個別設定などの構成ファイルに最適です（たとえば、最大の健康状態、ダメージ、その他のパラメーターを保存できます）。 SOは、カスタムツール、レベルエディターなどの作成にも役立ちます。



SOインスタンスから、迅速かつ便利にカスタムアセットを作成、再利用、ネットワーク経由でロードすることができます。SOクラスの継承者を宣言する場合、 CreateAssetMenu属性でマークできます。これにより、Assets / Createコンテキストメニューにこのオブジェクトのアセット作成アイテムが追加されます。



設定を使用した簡単なスクリプトの例：

using UnityEngine; [CreateAssetMenu(fileName="EnemyData", menuName="Prefs/Characters/Enemy", order=1)] public class EnemyPrefs : ScriptableObject { public string objectName = "Enemy"; [Range(10f, 100f)] public float maxHP = 50f; [Range(1f, 10f)] public float maxDamage = 5f; public Vector3[] spawnPoints; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

資産の作成：







インスペクターでデータを使用してアセットをシリアル化する：







SOインスタンスを使用してインスペクターで作業している場合、リンクフィールドをダブルクリックしてSOのインスペクターを開くことができます。 また、カスタムエディターを作成してタイプのインスペクターのタイプを決定し、それが表すデータの管理に役立てることもできます。



SOインスタンスは、.assetファイルを参照せずに作成できます。プログラムで、 SriptableObject.CreateInstance<>を使用します。



SOライフタイム：

• 他のアセットと同じです。
• 永続的な場合（.assetファイル、AssetBundleなどに添付）：
  
  
  • SOはResources.UnloadUnusedAssetsを介してGCによってアンロードできます。
  • 他のスクリプトにリンクがある場合、メモリ内に存在し続けます。
  • 必要に応じて、リロードできます。
• 永続的でない場合（CreateInstance <>を使用して作成され、どの.assetにも関連付けられていない場合）：
  
  
  • アンロードするだけでなく、GCによって破棄することができます。
  • HideFlags.HideAndDontSaveを使用してメモリに残すことができます。

使用パターン

ほとんどの開発者はSOをデータコンテナーと見なしていますが、実際にはそれ以上のものです。 そのアプリケーションのいくつかのパターンを考えてみましょう。



データオブジェクトとテーブルのように：

• .assetファイルにバインドされたPlain-Old-Data（POD）クラス。
• インスペクターで編集し、VCSで単一のファイルとしてコミットできます。 たとえば、ゲームデザイナーは、シーンやプレハブに影響を与えずに設定やその他のデータを変更できます。これは非常に便利です。
• カスタムエディターを使用すると、インスペクターで設定を使用するときにさらに便利になります。
• SOを使用する場合、アプローチを選択する価値があります。エンティティごとに1つのオブジェクトを適用するか、テーブル/エンティティセットごとに1つのオブジェクトを適用します。 たとえば、ローカライズテーブルまたは構成ファイルを作成する場合、1つの共通オブジェクトで十分であり、異なるユニット用のテンプレートを作成する必要がある場合、それぞれに独自のテンプレートが必要です。
• 使用例：ローカリゼーションテーブル、インベントリアイテム、ユニットテンプレート、レベル構成など。上記のいずれも、空間内の位置、または何らかのロジックを必要としません。 これは、シーンやプレハブに影響を与えずに変更できる単なるデータであり、他のチームメンバーの作業を妨げることはありません。

例：

 class EnemyInfo : ScriptableObject { public int MaximumHealth; public int DamagePerMeleeHit; } class Enemy : MonoBehaviour { public EnemyInfo info; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

拡張可能なリストとして：

• .assetファイルにバインドされた、空のSOの形式。
• これらは、他のそのようなオブジェクトとの同等性のチェック、またはnullのチェックにのみ使用できます。
• Enumに似ていますが、コードを記述する代わりに、デザイナーがエディターで直接作成できます。
• 使用例：インベントリアイテム、イベントカテゴリ、損傷タイプ、ユニットタイプなど
• 必要に応じて、必要なプロパティを追加することで、データ/テーブルオブジェクトに簡単に拡張できます。

例：

 class AmmoType : ScriptableObject { } … if (inventory[weapon.ammoType] == 0) { PlayOutOfAmmoSound(); return; } … inventory[weapon.ammoType] -= 1; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デュアルシリアル化



前述のとおり、SOの利点の1つは、Unityシリアル化システムとの完全な互換性です。 この場合：

• SOはJsonUtilityと対話できます。
• その結果、Unityシリアライザーを使用して設計段階で作成されたアセットと、JsonUtilityを使用してプログラムで作成されたアセットの混合物を取得できます。
• 使用例：組み込みレベル（デザイン、Unityシリアライザーで保存）+ユーザーレベル（ランタイムで作成され、JsonUtilityを使用して保存）。 アーキテクチャの観点からは、なぜそのようなレベルが作成されたのかを心配する必要はありません。SOとしてメモリにロードし、普遍的に作業できます。
  
  
  
  例：
  
  
  
  

   [CreateAssetMenu] class LevelData : ScriptableObject { /*...*/ }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• メニューからエディターで直接作成したり、値を調整したりできます。
  
  
  
  

   LevelData LoadLevelFromFile(string path) { string json = File.ReadAllText(path); LevelData result = CreateInstance<>(LevelData); JsonUtility.FromJsonOverwrite(result, json); return result; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• このメソッドを使用すると、JSON（レベルの作成プロセスでローカルに作成された、またはサーバーから取得されたものなど）を含むテキストファイルを読み取り、SO

シングルトーンのように：

• SO +静的インスタンス変数（SOインスタンスが作成され、それへのリンクが静的変数に格納されます）。
• レベルのリロード後にインスタンスを復元するFindObjectWithType。
• 使用例：グローバルゲームの状態。

例：

 class GameState: ScriptableObject { public int lives, score; static GameState _instance; public GameState Instance { get { if (!_instance) _instance = FindObjectOfType<GameState>(); if (!_instance) _instance = CreateDefaultGameState(); return _instance; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

代理人として：

• メソッドを含むSO。
• MBはSOメソッドでそれ自体への参照を渡し、SOは必要に応じてMBを使用して作業を行います。
• これにより、埋め込み動作とカスタム動作を実装できます。
• 使用例：AIタイプ、さまざまなパワーアップ、バフ/デバフ。

例：

 abstaract class PowerupEffect : ScriptableObject { public abstract void ApplyTo(GameObject go); } class HealthBooster : PowerupEffect { public int Amount; public override void ApplyTo(GameObject go) { go.GetComponent<Health>().currentValue += Amount; } } class Powerup : MonoBehaviour { public PowerupEffect effect; public void OnTriggerEnter(Collider other) { effect.ApplyTo(other.gameObject); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、Powerup MBは、その作業をパターンであるPowerupEffect SOに委任します。

おわりに

上記を要約すると、SOには長所と短所があり、そのいくつかを以下に示します。



利点：

• JsonUtilityを使用して、エディターで視覚的に（たとえば、静的クラスとは異なり）完全にシリアル化されます。
• 変更は保存され、playmodの終了後に破棄されません。
• 他のスクリプト間を簡単に移動できます。
• 簡単に継承できます。
• インスペクターに配置されないため、ごみが出ません。
• オーバーヘッドがなく、MBよりも軽量です。
• それぞれGOにアタッチされず、オブジェクトが破棄されるときに削除されません。
• このシーン内の少なくとも1つのオブジェクトが参照するまで、シーンに保存できます。
• アセットに保存し、AssetDatabaseを使用して他のシーンで再利用したり、既にデプロイされたビルドのランタイムで再利用したりできます。

短所：

• シーンには表示されません-現在使用されているSOインスタンスの数が視覚的に不明であるため、デバッグが困難になる可能性があります。
• （シーン内で）それを参照する最後のオブジェクトを破壊すると、暗黙的に破壊する可能性があります。
• プレハブでの使用はそれほど便利ではありません。
• オブジェクトが誰に属しているのか、いつ破棄するのか、どの可視領域にあるのかは明らかではありません。
• SOはGOにアタッチされていないため、GetComponentsを介してリンクをすばやく取得する方法はありません。

SOは非常に重要なツールであり、MBを完全に置き換えることはできませんが、MBと組み合わせて使用​​できるため、専制政治を排除できます。 SOはすべてに使用されるべきではありませんが、より柔軟性があります。 表面的にSOに精通している人、またはまったく考えていない人よりもはるかに多く。 また、プロジェクトの優れたワークフローを構築したり、デザイナーにとって便利で便利なツールやテンプレートを作成したりする機会も提供します。



リチャードは演説の冒頭で、「MonoBehavior sucks」（MonoBehavior sucks :)）と述べました。 これに完全に同意することは困難です。何とかして、それなしではできない（MB）からです。 しかし、主なことは、いつでもどこでもそれを使用するべきではなく、強力な、柔軟で便利なScriptableObjectであるさまざまな選択肢があることを理解することです。 特定の条件下でのタスクに基づいて、これらまたは他の手段を正しく選択する必要があります。