Message processing

The final requirement for our messaging system is that this object should have some kind of timing-based mechanism built in to prevent it from choking on too many messages at once. This means that, somewhere in the code base, we will need to make use of MonoBehaviour event callbacks to tell our messaging system to perform work during Unity's Update(), essentially enabling it to count time.

This could be achieved with the static class singleton (which we defined earlier), which would require some other MonoBehaviour-based God class to call into it, informing it that the scene has been updated. Alternatively, we can use the singleton component to achieve the same thing, which has its own means of determining when Update() is called and hence handle its workload independently of any God class. The most notable difference between the two approaches is whether or not the system is dependent on the control of other objects and the various pros and cons of managing a singleton component (such that it won't get destroyed between scenes; we don't want to accidentally recreate it during shutdown).

The singleton component approach is probably the best since there aren't too many occasions where we wouldn't want this system acting independently, even if much of our game logic depends upon it. For example, even if the game was paused, we wouldn't want the game logic to pause our messaging system. We would still want the messaging system to continue receiving and processing messages so that we could, for example, keep UI-related components communicating with one another while the gameplay is in a paused state.