UnityのMonoBehaviourクラスをシングルトン化する

何を隠そう、ここ2年ほど仕事でUnityを使っているオイラです。

UnityでC#のScriptを作成しようとすると、デフォルトでMonoBehaviourクラスを継承したクラスが作成される。このMonoBehaviourクラスはUnityとやり取りするための様々な機能がすでに実装されていてとても便利。ただ、個々のGameObjectが独立して動作させるような時には自由度が高くて良いんだけど、この自由度が逆に管理しづらいこともあるのです。
例えば、ゲーム全体を一元管理する情報を扱うような場合、あるいは外部のアプリケーションやKinectみたいなセンサーとやり取りするインターフェイスを作る場合、そのクラスのインスタンスは唯一にしておきたい。知らないうちに複数出来ちゃったら大混乱だ。

ということで、MonoBehaviourクラスの便利さを保ったままシングルトンにする方法を探したら、良い方法を見つけた。

Unity開発に関する50のTips　〜ベストプラクティス〜（翻訳）

以下の本文はここのサイトの翻訳です: The following text is a translation of the site here: このTipsはUnity Technologies社として公式に推薦するものではありませんが、個人的に有用だと思われたので翻訳したものです。あらかじ...

warapuri.com

２９、シングルトンは便利だ

こんな感じで自動的にシングルトンが作られるようにしておくといい。

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
   protected static T instance;
 
   /**
      Returns the instance of this singleton.
   */
   public static T Instance
   {
      get
      {
         if(instance == null)
         {
            instance = (T) FindObjectOfType(typeof(T));
 
            if (instance == null)
            {
               Debug.LogError("An instance of " + typeof(T) + 
                  " is needed in the scene, but there is none.");
            }
         }
 
         return instance;
      }
   }
}

シングルトンはParticleManager とか AudioManager とか GUIManager.とかマネージャーに役に立つ。

• マネージャーではない固有インスタンス（プレイヤーとか）にシングルトンを使うのは止めよう。（以下略）
• クラスの外側から利用されるために、staticなプロパティと関数を定義しておこう。こうしておくと、GameManager.Playerと書けるようになる（GameManager.Instance.playerという書き方ではなく）

あとはこれを継承して任意のクラスを作るだけ。例えばこんな感じ。

using UnityEngine;
 
public class GameManager : SingletonMonoBehaviour<GameManager> {
     
    public void Awake(){
        if(this != Instance){
            Destroy(this);
            return;
        }
 
        DontDestroyOnLoad(this.gameObject);//シーン遷移しても破棄されない設定
    }    
     
}

そして、同じような要件でシーン遷移後もMonoBehaviourクラスを破棄せずに存続させたい場合は、上記のようにAwake()メソッドでの初期化時に

 DontDestroyOnLoad(this.gameObject);

という記述を加えれば、Script(MonoBehaviourクラス)の親となるGameObjectがシーン遷移後も存続するようになる。

Unityは、ささっと動く物を作るには本当に便利だけど、ややカチッとしたものを作ろうとするとMonoBehaviourクラスの特殊さが壁になっちゃったりもする。
システム開発してた人間からすると、MVCにならない時点で頭を抱えちゃうんだけど、Unityに適した設計方法ってのをのんびり模索していきたい。上手く長所を活かせる方法が見つかるといいなぁ。

Also published on Medium.