Game Development Reference
In-Depth Information
Event-driven Programming
The
Update
events for
MonoBehaviour
objects seem to offer a convenient place for
executing code that should perform regularly over time, spanning multiple frames,
and possibly multiple scenes. When creating sustained behaviors over time, such
as artificial intelligence for enemies or continuous motion, it may seem that there
are almost no alternatives to filling an
Update
function with many
if
and
switch
statements, branching your code in different directions depending on what your
objects need to do at the current time. But, when the
Update
events are seen this
way, as a default place to implement prolonged behaviors, it can lead to severe
performance problems for larger and more complex games. On deeper analysis, it's
not difficult to see why this would be the case. Typically, games are full of so many
behaviors, and there are so many things happening at once in any one scene that
implementing them all through the
Update
functions is simply unfeasible. Consider
the enemy characters alone, they need to know when the player enters and leaves
their line of sight, when their health is low, when their ammo has expired, when
they're standing on harmful terrain, when they're taking damage, when they're
moving or not, and lots more. On thinking initially about this range of behaviors, it
seems that all of them require constant and continuous attention because enemies
should always know, instantly, when changes in these properties occur as a result of
the player input. That is, perhaps, the main reason why the
Update
function seems
to be the most suitable place in these situations but there are better alternatives,
namely, event-driven programming. By seeing your game and your application in
terms of events, you can make considerable savings in performance. This chapter
then considers the issue of events and how to manage them game wide.
