Game Development Reference
In-Depth Information
The core ingredient uniting all events, however, whether gameplay or system level, is that they
may
invoke a response, although sometimes no response need actually occur. In other words,
when an
event happens
(and they usually happen very often) the game may
need to do something else
(which
is usually very often, too). That “something else” could be small and relatively inconsequential, or it
could be mammoth and potentially game-changing. In principle, there's really no limit to the number
of responses that follow from an event, or to the significance of those responses. In fact, when you
think about it further, there really are only events, because every response or reaction to an event could
potentially be an event itself for further action, and so on. But essentially, the important point to take
away from all of this is that events and responses are all-pervasive in games. They're everywhere and
there's no avoiding them. There are only different ways of handling and working with them. Those
methods and ways can indeed differ quite significantly, but all of them rest on the same core concepts.
Event Handling
Games, as we've seen, can be conceived as a chain of events and responses. Event handling is the
practice of
working
with and
managing
those events and responses in-game. Thus, event handling is
something we must engineer and build into a game. It's not something that exists ready-made for us,
even with Unity. In this chapter, we'll be using C# to engineer such a system. However, the question
arises as to why we should begin game development here, as opposed to elsewhere. After all, if
there are different ways to begin development, and none of them necessarily right or wrong, then it
surely cannot be wrong to begin elsewhere. And this is true. But nonetheless there are
compelling
reasons to begin here. These are as follows:
Events are foundational.
Events are everywhere in games. Whenever an
underlying action or function in code has the potential to effect something
else in-game, then in practice an event is happening, even if you don't always
see it that way at the time. And every time you think it'd be useful for some
process to detect and respond to a situation happening elsewhere, you've just
thought about an event-and-response scenario. Events are thus so foundational
to games that it's almost impossible to create any functionality or classes or
behavior without referring to them or using them. Consequently, since the
practice of making games is essentially an exercise in engineering and building,
it's good practice to begin with foundations. It's good practice to make those
foundations strong so they may sustain the complexities of the structure above.
Events are abstract.
This means that events are relevant to almost every kind of
game. And something important and powerful comes from this; namely, events
are
not
design-restrictive. That is, being so general and widely applicable, events
themselves never place constraints or limitations on how you should implement or
make the rest of your game. Events, for example, never say that enemies cannot
have range or magical attacks. They never require you to keep the vehicles in
your game to only ground-based ones, as opposed to airborne or seaborne ones.
Events as a concept really don't care about these specifics or particular instances.
They have a more general and abstract nature that frees them from specifics. And
so in practice this frequently means that if you create events from the outset, you
don't put any technical or logistical restrictions on the kinds of things you may have
elsewhere in the game. Thus, coding events empower you and never limit you.
There's no good reason to narrow your horizons before it's necessary to do so.
