Game Development Reference
In-Depth Information
There are many ways to begin game coding and implementation. Some developers start by
creating a
GameManager
class to handle the central game logic and rules, such as the win and loss
conditions. Some instead focus on building critical game entities, such as the Player character and
enemies. And others take alternative approaches. None of these approaches are
right
or
wrong
in
any objective sense per se. They simply represent different and pragmatic approaches, which may
be more or less suited to your specific needs or to your particular style. But regardless of which
approach you take, it's certain that development has to begin somewhere. For my part, I typically
begin by creating an event-handling system and I think that approach is serviceable here, for
reasons I'll state shortly. First, let's consider events and event handling, and specifically how it more
generally relates to a game.
Events and Responses
For game developers, game worlds are ultimately
deterministic
systems. This means that, once
the game begins (the beginning of game time), everything else that follows does so
because
of a
sequential flow of events. That is, everything that happens is a calculated
response
to a related and
previous cause, which we may call an
event
. For example, enemies attack the player
when
he or she
comes into their line of sight
because
there exists artificial intelligence (AI) functionality telling the
enemies to act that way under those very conditions. Similarly, the Player character fires its weapons
when it does, only because there exists an underlying mechanism watching for human input and for
responding to it when the player presses the designated “fire” button, whichever button that happens
to be. Seen in this way, a video game can be conceived as an integrated system of events and
responses. Specifically, an event happens and something else happens in response. And this process
goes on each and every frame, until the game is terminated in some way—hopefully by the player
pressing Quit as opposed to the game's crashing from a bug! Among these events, two main kinds
can be identified:
gameplay-level events
and
system-level events
. These two terms are not part of an
industry standard vocabulary so much as terms I'm inventing here for convenience and description.
Gameplay-level events.
These describe all events, which even a reflective and
thoughtful gamer might identify themselves during gameplay, as being events in
the game world. These include events such as
when the player presses a lever
on the wall
—perhaps to unlock a door or open a secret passageway, or
when
an enemy is killed
, or
when the player enters a room or region in the level
, or
when all power-ups have been collected
. The total number of possible events
belonging to this group is potentially infinite, but all of them happen
in the game
world
. They are an integral part of the “fiction.”
System-level events.
These events are in a fundamental sense hidden from
the gamer and exist outside the game world. These are the events that only the
game developer knows about and include all core events, which are part of the
underlying game mechanics. They pertain to the foundational wheels and cogs
of the game. Such events include
when the player saves and loads her game
,
when an error occurs
,
when the game is paused
,
when the system resolution
is changed
, or
when a network timeout occurs
. Like gameplay-level events,
however, system-level events may be a potentially infinite in number. They may
not, of course, be infinite in practice because computers have a maximum
capacity. But they are potentially infinite in that there's no obvious limit to the
number of events you could invent or think about.
