Event-driven Programming - Mastering Unity Scripting - page 120

Events
Game worlds are fully deterministic systems; in Unity, the scene represents a shared
3D Cartesian space and timeline inside which finite GameObjects exist. Things only
happen within this space when the game logic and code permits them to. For example,
objects can only move when there is code somewhere that tells them to do so, and
under specific conditions, such as when the player presses specific buttons on the
keyboard. Notice from the example that behaviors are not simply random but are
interconnected; objects move only when keyboard events occur. There is an important
connection established between the actions, where one action entails another. These
connections or linkages are referred to as events; each unique connection being a single
event. Events are not active but passive; they represent moments of opportunity but
not action in themselves, such as a key press, a mouse click, an object entering a collider
volume, the player being attacked, and so on. These are examples of events and none of
them say what the program should actually do, but only the kind of scenario that just
happened. Event-driven programming starts with the recognition of events as a general
concept and comes to see almost every circumstance in a game as an instantiation of
an event; that is, as an event situated in time, not just an event concept but as a specific
event that happens at a specific time. Understanding game events like these is helpful
because all actions in a game can then be seen as direct responses to events as and
when they happen. Specifically, events are connected to responses; an event happens
and triggers a response. Further, the response can go on to become an event that
triggers further responses and so on. In other words, the game world is a complete,
integrated system of events and responses. Once the world is seen this way, the
question then arises as to how it can help us improve performance over simply relying
on the Update functions to move behaviors forward on every frame. And the method
is simply by finding ways to reduce the frequency of events. Now, stated in this way, it
may sound a crude strategy, but it's important. To illustrate, let's consider the example
of an enemy character firing a weapon at the player during combat.
Throughout the gameplay, the enemy will need to keep track of many properties.
Firstly, their health, because when it runs low the enemy should seek out medical
kits and aids to restore their health again. Secondly, their ammo, because when it
runs low the enemy should seek to collect more and also the enemy will need to
make reasoned judgments about when to fire at the player, such as only when they
have a clear line of sight. Now, by simply thinking about this scenario, we've already
identified some connections between actions that might be identified as events.
But before taking this consideration further, let's see how we might implement this
behavior using an Update function, as shown in the following code sample 4-1.
Then, we'll look at how events can help us improve on that implementation:
// Update is called once per frame
void Update ()
{