The Event Listener pattern is an extremely common design pattern. Using Events instead of method calls let an object communicate with another object (or many objects) without explicit knowledge of the other object. With events acting as an implicit interface between objects, we can write much more loosely coupled (thus more reusable) code.
Unity’s own message passing system can be leveraged to achieve this effect, but there are a few problems with it. First, sending messages is hierarchy-dependent. You either need a reference to the object you wish to send the message (event) to, or you need a reference to that object’s parent object. This is not loosely coupled. Secondly, it’s not statically type-safe.
There have been several solutions to this problem (for example, FlashBang’s messaging system or this one on the UnifyCommunity wiki). These still lack type-safety, and won’t quite do.
Here is my event system implementation. It looks quite a bit like the event system in AS3:
using UnityEngine;
using System.Collections;
using System.Collections.Generic;
public class GameEvent
{
}
public class Events
{
private static Events eventsInstance = null;
public static Events instance
{
get
{
if (eventsInstance == null)
{
eventsInstance = new Events();
}
return eventsInstance;
}
}
public delegate void EventDelegate<T> (T e) where T : GameEvent;
private Dictionary<System.Type, System.Delegate> delegates = new Dictionary<System.Type, System.Delegate>();
public void AddListener<T> (EventDelegate<T> del) where T : GameEvent
{
if (delegates.ContainsKey(typeof(T)))
{
System.Delegate tempDel = delegates[typeof(T)];
delegates[typeof(T)] = System.Delegate.Combine(tempDel, del);
}
else
{
delegates[typeof(T)] = del;
}
}
public void RemoveListener<T> (EventDelegate<T> del) where T : GameEvent
{
if (delegates.ContainsKey(typeof(T)))
{
var currentDel = System.Delegate.Remove(delegates[typeof(T)], del);
if (currentDel == null)
{
delegates.Remove(typeof(T));
}
else
{
delegates[typeof(T)] = currentDel;
}
}
}
public void Raise (GameEvent e)
{
if (e == null)
{
Debug.Log("Invalid event argument: " + e.GetType().ToString());
return;
}
if (delegates.ContainsKey(e.GetType()))
{
delegates[e.GetType()].DynamicInvoke(e);
}
}
} |
To use this thing, first we declare a GameEvent subclass. This event can carry with it all of the parameters needed by the objects listening for the event.
public class SomethingHappenedEvent : GameEvent
{
// Add event parameters here
} |
Registering to listen for the event looks like this:
public class SomeObject : MonoBehaviour
{
void OnEnable ()
{
Events.instance.AddListener<SomethingHappenedEvent>(OnSomethingHappened);
}
void OnDisable ()
{
Events.instance.RemoveListener<SomethingHappenedEvent>(OnSomethingHappened);
}
void OnSomethingHappened (SomethingHappenedEvent e)
{
// Handle event here
}
} |
And finally, to raise the event, do this:
Events.instance.Raise(new SomethingHappenedEvent()); |
The cool thing about this implementation is that it’s type-safe (listener registration errors will be caught at compile time, and no casting of events or event arguments) and it doesn’t require listening objects to implement a special interface or use Unity’s built-in message passing system.
The interface for this system is almost identical to that presented by Mike Mittleman at Unite 08, and I’d wager our implementations are similar. If you really want a rundown of the benefits and pitfalls of event-driven Unity development, I suggest watching his presentation on Unity’s website.
UPDATE:
I’ve made a Gist for this thing with revisions suggested in the comments:
