Game Development Reference
In-Depth Information
The enemy class in the code sample 4-2 has been refactored to an event-driven
design, where properties such as
Ammo
and
Health
are validated not inside the
Update
function but on assignment. From here, events are raised wherever appropriate based
on the newly assigned values. By adopting an event-driven design, we introduce
performance optimization and cleanness into our code; we reduce the excess baggage
and value checks as found with the
Update
function in the code sample 4-1, and
instead we only allow value-specific events to drive our code, knowing they'll be
invoked only at the relevant times.
Event management
Event-driven programming can make our lives a lot easier. But no sooner than we
accept events into the design do we come across a string of new problems that require
a thoroughgoing resolution. Specifically, we saw in the code sample 4-2 how C#
properties for health and ammo are used to validate and detect for relevant changes
and then to raise events (such as
OnDead
) where appropriate. This works fine in
principle, at least when the enemy must be notified about events that happen to itself.
However, what if an enemy needed to know about the death of another enemy or
needed to know when a specified number of other enemies had been killed? Now, of
course, thinking about this specific case, we could go back to the enemy class in the
code sample 4-2 and amend it to call an
OnDead
event not just for the current instance
but for all other enemies using functions such as
SendMessage
, as we've seen in the
previous chapters. But this doesn't really solve our problem in the general sense. In
fact, let's state the ideal case straight away; we want every object to optionally listen
for every type of event and to be notified about them as and when they happen, just as
easily as if the event had happened to them. So the question that we face now is about
how to code an optimized system to allow easy event management like this. In short,
we need an
EventManager
class that allows objects to listen to specific events. This
system relies on three central concepts, as follows:
•
EventListener
: A listener refers to any object that wants to be notified about
an event when it happens, even its own events. In practice, almost every
object will be a listener for at least one event. An enemy, for example, may
want notifications about low health and low ammo among others. In this
case, it's a listener for at least two separate events. Thus, whenever an object
expects to be told when an event happens, it becomes a listener.
•
EventPoster
: In contrast to listeners, when an object detects that an event
has occurred, it must announce or post a public notification about it that
allows all other listeners to be notified. In the code sample 4-2, the enemy
class detects the
Ammo
and
Health
events using properties and then calls the
internal events, if required. But to be a true poster in this sense, we require
that the object must raise events at a global level.
