UnityLearn - Beginner Programming - Observer Pattern - Pt. 02 - Working with Multiple Subscriptions

Novemeber 5, 2019

Beginner Programming: Unity Game Dev Courses

Beginner Programming: Unity Game Dev Courses

Unity Learn Course - Beginner Programming

Working with Multiple Subscriptions

Creating a Parameterized Event

Parameterized Event: an event that takes in at least one parameter

Points of Reference

A subscriber must have a reference to the publisher (class raising the event) in order to be able to subscribe to that event.

The general pattern for making delegates and events from how they have done it so far is that you create the overall delegate type that you will want the events to use outside of a class definition and public (so that all classes that want to make an event of this delegate type can use this single delegate type as a reference). The events themselves are then within the class definition, and use that newly created delegate type.

Example Breakdown

I broke down the tutorial example in order to better understand it.

The parameterized event is created in the EnemyController script. This is done by creating a delegate called EnemyDestroyedHandler outside of the class definition in the EnemyController script (this delegate is of type void and takes an int parameter, so any event using this must do follow the same signature). They then created a public event of type EnemyDestroyedHandler named EnemyDestroyed within the class definition of EnemyController.

Since subscribers need references to the publishers in order to subscribe to their events, they go to the GameSceneController class to subscribe to the EnemyDestroyed event since it already has references to the EnemyController class in its spawning methods. Here they add a method (Enemy_EnemyDestroyed, the default name) from within the GameSceneController class to the EnemyDestroyed event. It matches the signature (return type void, with a single paramter of type int). Now, when the EnemyDestroyed event is called in the EnemyController script, the parameter input given there is the same parameter input used for all methods subscribed to that event. So in EnemyController, EnemyDestroyed(pointValue) ends up calling Enemy_EnemyDestroyed(pointValue) from within the GameSceneController class.

The GameSceneController also creates its own event of type EnemyDestroyedHandler named ScoreUpdatedOnKill. This uses the same delegate type created in the EnemyController script, so they just need to create the event here in the GameSceneController script. It should be noted that this can be done simply because they are using the same signature delegate type here, it does not necessarily even have to do with the fact that its a similar game related event. This event is then called within the Enemy_EnemyDestroyed method, which is subscribed to the EnemyController EnemyDestroyed event already. So this creates a chain of method calls from a single event.

This event, ScoreUpdatedOnKill, is used to update the HUD score value. To accomplish this, we need the HUDController class to subscribe to the event. So they go to the HUDController and create a reference to the GameSceneController class (since subscribers must have a reference to the publisher). Since the GameSceneController is an object that will persist throughout the entirety of the game, they simply create the reference to it and subscribe to the event within the GameSceneController within the Start method of the HUDController.

ScoreUpdatedOnKill, the GameSceneController event, is given the method GameSceneController_ScoreUpdatedOnKill from the HUDController. This method simply calls the method UpdateScore which changes the text to match the new score.

It is important to note that since this is a chain of events, as opposed to multiple subscribers subscribing to a single event, the value passed throughout the chain can change. The EnemyDestroyed event in EnemyController uses the int pointValue, so that the GameSceneController method Enemy_EnemyDestroyed subscribed to it adds that value to the totalPoints, which is held within the GameSceneController. The GameSceneController then passes totalPoints (not pointValue) into its event, ScoreUpdatedOnKill, which is the event the HUDController subscribes to in order to update the score. This makes sure it displays the new total score as opposed to just the value for the last score gained.

I wanted to make this difference clear since I also noted that multiple subscribers to a single parameterized event will all use the same parameters. This chain of events simply use the same delegate type because they just happen to want to use the same signature (return type void with a single int parameter) and nothing more.

Multiple Subscribers

You can have several classes subscribe to the same event.

What was weird for this example was that they just wanted to reenable the firing mechanism for the player when an enemy was destroyed, using the same ScoreUpdatedOnKill event. This event requires a method of return type void with an int parameter. So they made a method satisfying this, but it doesn't use the int parameter at all. It simply calls another method that is just void return type with no input parameter, EnableProjectile (which lets the player fire again). Since you can simply subscribe to an event with a method that just calls another method, your method actually doing work does not particularly have to match the signature of the original delegate type.

Conclusion

Actions (C#): types in the System namespace that allow you to encapsulate methods without explicitly defining a delegate

Actions are inherently delegate types so they keep you from having to separately define a delegate when creating an event. They mention that they will just use actions from here on for the course, so I assume this is generally better and cleaner practice this way. This does make more sense with my recent understanding that the delegate signature type is not particularly that crucial for the actual outcome when dealing with this subscriber and publisher pattern.

SUMMARY

Subscribers need a reference to their publisher in order to use their events, so look for places where you are already creating this reference for improved efficiency. An event can have multiple subscribers, so calling that event can call multiple methods from multiple objects. You can also create chains of actions that call methods while starting other events. Actions are a more compact and cleaner way to create an event without the need for separately creating the delegate.