This approach involves creating a class that is globally accessible to the entire codebase at any time. The object stays alive from the moment the application starts, to the moment it is closed. Global manager classes are often frowned upon, since the name doesn't say much about what it's meant to do, and they can be difficult to debug since changes can occur from anywhere, at any point during runtime. In addition, it is probably the least robust approach when it comes to changing or replacing it at a future date. Despite all of these drawbacks, it is by far the easiest solution to implement, and so we will cover it first.

The Singleton design pattern is a common way of ensuring that we have a globally-accessible object, and that only one instance ever exists in memory. However, the way that Singletons are primarily used (note the qualifier) in Unity projects, can be easily replaced with a simple C# Static class without the need to implement private constructors, and the unnecessary property access of an Instance variable. Essentially, implementing a typical Singleton design pattern in C# just takes more code, and time, to achieve the same result as a static class.

A static class that functions in much the same way as our EnemyManagerComponent is used in the previous example can be defined as follows:

using System.Collections.Generic;

public static class EnemyManager {
  static List<GameObject> _enemies;

  public static void AddEnemy(GameObject enemy) {
    _enemies.Add (enemy);
  }

  public static void RollCall() {
    for(int i = 0; i < _enemies.Count; ++i) {
      Debug.Log (string.Format("Enemy "{0}" reporting in...", _enemies[i].name));
    }
  }
}

Note that every member and method has the static keyword attached, which implies that only one instance of this object will ever reside in memory. Static classes, by definition, do not allow any nonstatic instance members to be defined, as that would imply that we could somehow duplicate the object.

Static classes can be given a static constructor, which can be used to initialize member data. A static constructor can be defined like so, and it is called the moment the class is first accessed (either through a member variable or a member function):

static EnemyManager() {
  _enemies = new List<GameObject>();
}

This type of global class is generally considered to be a cleaner and easier-to-use version of the typical Singleton design pattern in the world of C# development.

The disadvantage of the static class approach is that they must inherit from the lowest form of class—Object. This means that static classes cannot inherit from MonoBehaviour and therefore we cannot make use of any of its Unity-related functionality, including the all-important event callbacks, as well as Coroutines. Also, since there's no object to select, we lose the ability to inspect the object's data at runtime through the Inspector. These are features that we may wish to make use of in our global Singleton classes.

A common solution to this problem is to implement a "Singleton as a Component" class that spawns a GameObject containing itself, and providing static methods to grant global access. Note that, in this case, we must essentially implement the typical Singleton design pattern, with private static instance variables, and a global Instance method for global access.

Here is the definition for a SingletonAsComponent class:

public class SingletonAsComponent<T> : MonoBehaviour where T : 
SingletonAsComponent<T> {
  
  private static T __Instance;
  
  protected static SingletonAsComponent<T> _Instance {
      get {
        if(!__Instance) {
              T [] managers = 
              GameObject.FindObjectsOfType(typeof(T)) as T[];
              if (managers != null) {
                  if(managers.Length == 1) {
                      __Instance = managers[0];
                      return __Instance;
                  } else if (managers.Length > 1) {
                      Debug.LogError("You have more than one " + 
                      typeof(T).Name + " in the scene. You only 
                      need 1, it's a singleton!");
                      for(int i = 0; i < managers.Length; ++i) {
                          T manager = managers[i];
                          Destroy(manager.gameObject);
                      }
                  }
              }

              GameObject go = new GameObject(typeof(T).Name, 
              typeof(T));
              __Instance = go.GetComponent<T>();
              DontDestroyOnLoad(__Instance.gameObject);
          }
          return __Instance;
      } 
      set {
          __Instance = value as T;
      }
  }
}

Since we wish this to be a global and persistent object, we need to call DontDestroyOnLoad() shortly after the GameObject is created. This is a special function that tells Unity that we wish the object to persist between Scenes for as long as the application is running. From that point onward, when a new scene is loaded, the object will not be destroyed and will retain all of its data.

This class definition assumes two things. Firstly, because it is using generics to define its behavior, it must be derived from in order to create a concrete class. Secondly, a method will be defined to assign the _Instance variable and cast it to/from the correct Type.

For example, the following is all that is needed to successfully generate a new SingletonAsComponent derived class called MySingletonComponent:

public class MySingletonComponent : SingletonAsComponent<MySingletonComponent> {
  public static MySingletonComponent Instance {
    get { return ((MySingletonComponent)_Instance); }
    set { _Instance = value; }
  }
}

This class can be used at runtime by having any other object access the Instance property at any time. If the Component does not already exist in our Scene, then the SingletonAsComponent base class will instantiate its own GameObject and attach an instance of the derived class to it as a Component. From that point forward, access through the Instance property will reference the Component that was created.

Proper cleanup of a Singleton Component can be a little convoluted because of how Unity tears down Scenes. An object's OnDestroy() method is called whenever it is destroyed during runtime. The same method is called during application shutdown, whereby every Component on every GameObject has its OnDestroy() method called by Unity. Application shutdown also takes place when we end Play Mode in the Editor and return to Edit Mode. However, destruction of objects occurs in a random order, and we cannot assume that the Singleton Component will be the last object destroyed.

Consequently, if any object attempts to do anything with the Singleton in the middle of their OnDestroy() method, then they will be calling the Instance property. If the Singleton has already been destroyed prior to this moment, then calling Instance during another object's destruction would create a new instance of the Singleton Component in the middle of application shutdown! This can corrupt our Scene files, as instances of our Singleton Components will be left behind in the Scene. If this happens, then Unity will throw the following error message at us:

The reason some objects may wish to call into our Singleton during destruction is that Singletons often make use of the Observer pattern. This design pattern allows other objects to register/deregister with them for certain tasks, similar to how Unity latches onto callback methods, but in a less automated fashion. We will see an example of this in the upcoming section A global messaging system. Objects that are registered with the system during construction will want to deregister with the system during their own shutdown, and the most convenient place to do this is within its OnDestroy() method. Consequently, such objects are likely to run into the aforementioned problem, where Singletons are accidentally created during application shutdown.

To solve this problem, we need to make three changes. Firstly, we need to add an additional flag to the Singleton Component, which keeps track of its active state, and disable it at the appropriate times. This includes the Singleton's own destruction, as well as application shutdown (OnApplicationQuit() is another useful Unity callback for MonoBehaviours, which is called during this time):

private bool _alive = true;
void OnDestroy() { _alive = false; }
void OnApplicationQuit() { _alive = false; }

Secondly, we should implement a way for external objects to verify the Singleton's current state:

public static bool IsAlive {
  get {
    if (__Instance == null)
      return false;
    return __Instance._alive;
  }
}

Finally, any object that attempts to call into the Singleton during its own OnDestroy() method, must first verify the state using the IsAlive property before calling Instance. For example:

public class SomeComponent : MonoBehaviour {
    void OnDestroy() {
    if (MySingletonComponent.IsAlive) {
        MySingletonComponent.Instance.SomeMethod();
    }
  }
}

This will ensure that nobody attempts to access Instance during destruction. If we don't follow this rule, then we will run into problems where instances of our Singleton object will be left behind in the Scene after returning to Edit Mode.

The irony of the Singleton Component approach is that we are using one of Unity's Find() methods to determine whether or not one of these Singleton Components already exists in the Scene before we attempt to assign the __Instance reference variable. Fortunately, this will only happen when the Singleton Component is first accessed, but it's possible that the initialization of the Singleton would not necessarily occur during Scene initialization and can therefore cost us a performance spike at a bad moment during gameplay, when this object is first instantiated and Find() gets called. The workaround for this is to have some god class confirm that the important Singletons are instantiated during Scene initialization by simply calling Instance on each one.

The downside to this approach is that if we later decide that we want more than one of these manager classes executing at once, or we wish to separate its behavior to be more modular, then there would be a lot of code that needs to change.

There are further alternatives that we can explore, such as making use of Unity's built-in bridge between script code and the Inspector interface.

Another approach to the problem of inter-object communication is to use Unity's built-in serialization systems. Software design purists tend to get a little combative about this feature, since it breaks encapsulation; it makes variables marked private act in a way that treats them as public. Even though the value only becomes public with respect to the Unity Inspector and nothing else, this is still enough to wave some red flags.

However, it is a very effective tool for improving development workflow. This is particularly true when artists, designers, and programmers are all tinkering with the same product, where each has wildly varying levels of computer science and software programming knowledge. Sometimes it's worth bending a few rules in the name of productivity.

Whenever we create a public variable, Unity automatically serializes and exposes the value in the Inspector interface when the Component is selected. However, public variables are dangerous from a software design perspective—these variables can be changed through code at any time, which can make it hard to keep track of the variable, and introduce a lot of unexpected bugs.

As an alternative, we can take any private or protected member variable of a class and expose it to the Unity Editor Inspector interface with the [SerializeField] attribute. This approach is preferred over public variables, as it gives us more control of the situation. This way, at least we know the variables cannot be changed at runtime via code outside the class (or derived class), and therefore maintain encapsulation from the perspective of script code.

For example, the following class exposes three private variables to the Inspector:

public class EnemySpawnerComponent : MonoBehaviour {

  [SerializeField] private int _numEnemies;
  [SerializeField] private GameObject _enemyPrefab;
  [SerializeField] private EnemyManagerComponent _enemyManager;

  void Start() {
    SpawnEnemies(_numEnemies);
  }

    void SpawnEnemies(int _numEnemies) {
      for(int i = 0; i < _numEnemies; ++i) {
        GameObject enemy = (GameObject)GameObject.Instantiate(_enemyPrefab, Vector3.zero, Quaternion.identity);
        _enemyManager.AddEnemy(enemy);
      }
    }
}

Looking at this Component in the Inspector view reveals three values, initially given default values of 0, or null, which can be modified through the Inspector interface:

We can drag and drop a Prefab reference from the Projects window into the Enemy Prefab field, or, if we felt so inclined, even a reference to another GameObject that is present in the Scene. Although, given that it's being used like a Prefab in the code, it would be unwise to do this, since we would be cloning a GameObject that might have already undergone changes in the Scene. Prefabs serve the purpose of a blueprint from which to instantiate new GameObjects and should be used as such.

The Enemy Manager field is interesting because it is a Component reference and not a GameObject reference. If a GameObject is dropped into this field, then it will refer to the Component on the given object, as opposed to the GameObject that we dragged and dropped into the field. If the given object does not have the expected Component, then nothing will be assigned.

The danger here is that since Prefabs are essentially GameObjects, Prefabs with the required Component can be assigned to these fields, even though we might not wish them to be. Unity loads Prefabs into memory much like GameObjects, and assumes they'll be used in Prefab-like ways; that is, treated as nothing more than blueprints to be instantiated from on an as-needed basis. However, they still count as data stored in memory and can therefore be edited on a whim, making them susceptible to changes that directly affect all future GameObjects instantiated from them.

To make matters worse, these changes become permanent even if they are made during Play Mode, since Prefabs occupy the same memory space whether Play Mode is active or not. This means that we can accidentally corrupt our Prefabs, if we assign them to the wrong fields. Consequently, this approach is a more team-friendly way of solving the original problem of inter-object communication, but it is not ideal due to all of the risks involved with team members accidentally breaking things or leaving null references in place.

It is also important to note that not all objects can be serialized by the Inspector view. Unity can serialize all primitive data types (ints, floats, strings, and bools), various built-in types such as (Vector3, Quaternion, and so on) enums, classes, and structs, as well as arrays and lists of other serializable types. However, it is unable to serialize static fields, read-only values, properties, and dictionaries.

The last solution we will look at will provide a way to hopefully get the best of both worlds by combining ease of implementation, ease of extension, and strict usage that avoids too much human error.

The final suggested approach to the problem of inter-object communication is to implement a global messaging system that any object can access and send messages through to any object that may be interested in listening to that specific type of message. Objects either send messages or listen for them, and the responsibility is on the listener to decide what messages it is interested in. The message sender can broadcast the message without caring at all who is listening. This approach is excellent for keeping our code modular and decoupled.

The kinds of message we wish to send can take many forms, such as including data values, references, instructions for listeners, and more, but they should all have a common, basic declaration that our messaging system can use to determine what the message is, and who it is intended for.

The following is a simple class definition for a Message object:

public class BaseMessage {
  public string name;
  public BaseMessage() { name = this.GetType().Name; }
}

The BaseMessage class's constructor caches the Type in a local string property to be used later for cataloguing and distribution purposes. Caching this value is important as each call to GetType().Name will result in a new string being allocated on the heap, and we want to minimize this as much as possible. Our custom messages must derive from this class, which allows them to add whatever superfluous data they wish, while still maintaining the ability to be sent through our messaging system. Take note that, despite acquiring the Type name during the base class constructor, the name property will still contain the name of the derived class, not the base class.

Moving on to our MessagingSystem class, we should define its features by what kind of requirements we need it to fulfill:

public delegate bool MessageHandlerDelegate(BaseMessage message);

using System.Collections.Generic;

public class MessagingSystem : SingletonAsComponent<MessagingSystem> {

  public static MessagingSystem Instance {
    get { return ((MessagingSystem)_Instance); }
    set { _Instance = value; }
  }

  private Dictionary<string,List<MessageHandlerDelegate>> _listenerDict = new Dictionary<string,List<MessageHandlerDelegate>>();

  public bool AttachListener(System.Type type, MessageHandlerDelegate handler) {
    if (type == null) {
      Debug.Log("MessagingSystem: AttachListener failed due to no message type specified");
      return false;
    }

    string msgName = type.Name;

    if (!_listenerDict.ContainsKey(msgName)) {
      _listenerDict.Add(msgName, new List<MessageHandlerDelegate>());
    }

    List<MessageHandlerDelegate> listenerList = _listenerDict[msgName];
    if (listenerList.Contains(handler)) {
      return false; // listener already in list
    }

    listenerList.Add(handler);
    return true;
  }
}

private Queue<BaseMessage> _messageQueue = new Queue<BaseMessage>();

public bool QueueMessage(BaseMessage msg) {
  if (!_listenerDict.ContainsKey(msg.name)) {
    return false;
  }
  _messageQueue.Enqueue(msg);
  return true;
}

private float maxQueueProcessingTime = 0.16667f;

void Update() {
  float timer = 0.0f;
  while (_messageQueue.Count > 0) {
    if (maxQueueProcessingTime > 0.0f) {
      if (timer > maxQueueProcessingTime)
        return;
    }

    BaseMessage msg = _messageQueue.Dequeue();
    if (!TriggerMessage(msg))
      Debug.Log("Error when processing message: " + msg.name);

    if (maxQueueProcessingTime > 0.0f)
      timer += Time.deltaTime;
  }
}

public bool TriggerMessage(BaseMessage msg) {
  string msgName = msg.name;
  if (!_listenerDict.ContainsKey(msgName)) {
    Debug.Log("MessagingSystem: Message "" + msgName + "" has no listeners!");
    return false; // no listeners for message so ignore it
  }

  List<MessageHandlerDelegate> listenerList = _listenerDict[msgName];

  for(int i = 0; i < listenerList.Count; ++i) {
    if (listenerList[i](msg))
      return true; // message consumed by the delegate
  }
  return true;
}

public class MyCustomMessage : BaseMessage {
  public readonly int _intValue;
  public readonly float _floatValue;
  public MyCustomMessage(int intVal, float floatVal {
    _intValue = intVal;
    _floatValue = floatVal;
  }
}

public class TestMessageListener : MonoBehaviour {

  void Start() {
    MessagingSystem.Instance.AttachListener(typeof(MyCustomMessage), this.HandleMyCustomMessage);
  }

  bool HandleMyCustomMessage(BaseMessage msg) {
    MyCustomMessage castMsg = msg as MyCustomMessage;
    Debug.Log (string.Format("Got the message! {0}, {1}", castMsg._intValue, castMsg._floatValue));
    return true;
  }
}

Message sending

Finally, let's implement an example of sending a message so that we can test this system out! Here's a component that will broadcast an instance of our MyCustomMessage class through the messaging system when the Space Bar is pressed:

public class TestMessageSender : MonoBehaviour {

  public void Update() {
    if (Input.GetKeyDown (KeyCode.Space)) {
      MessagingSystem.Instance.QueueMessage(new MyCustomMessage(5, 13.355f));
    }
  }
}

If we add both the TestMessageSender and TestMessageListener objects to our Scene and press the Space bar, we should see a log message appear in the console, informing us of a successful test:

Our MessagingSystem Singleton object will be created immediately upon Scene initialization, when the TestMessageListener's Start() method is called and it registers the HandleMyCustomMessage delegate. No additional effort is required on our part to create the Singleton we need.

public bool DetachListener(System.Type type, MessageHandlerDelegate handler)
  {
    if (type == null) {
      Debug.Log("MessagingSystem: DetachListener failed due to no message type specified");
      return false;
    }

    string msgName = type.Name;

    if (!_listenerDict.ContainsKey(type.Name)) {
      return false;
    }

    List<MessageHandlerDelegate> listenerList = _listenerDict[msgName];
    if (!listenerList.Contains (handler)) {
      return false;
    }

    listenerList.Remove(handler);
    return true;
  }

void OnDestroy() {
  if (MessagingSystem.IsAlive) {
    MessagingSystem.Instance.DetachListener(typeof(MyCustomMessage), this.HandleMyCustomMessage);
  }
}