Game Development Reference
In-Depth Information
Figure 2.1
High-level game architecture.
system from the interface used to present or request changes to data. The architec-
ture I propose encapsulates that and adds a layer for hardware or operating system
-
specific subsystems.
The application layer concerns itself with the machine your game runs on. If you
were going to port your game from Windows to iOS or Android, or from the
PlayStation 3 to Xbox 360, you would rewrite most of the code in the application
layer, but hopefully not much else. In this area, you
ll find code that deals with hard-
ware devices like the mouse or a gamepad, operating system services such as network
communications or threading, and operations such as initialization and shutdown of
your game.
The game logic layer is your game, completely separated from the machine your
game runs on or how it is presented to the player. In a perfect world, you could sim-
ply recompile all the source code related to your game logic, and it would run on any
platform or operating system. In this area, you
'
'
ll find subsystems for managing your
game
s world state, communicating state changes to other systems, and accepting
input commands from other systems. You
'
ll also find systems that enforce rules of
your game system
'
s universe. A good example of this is a physics system, which is
the authority on how game objects move and interact.
The third and last system component is the game view. This system is responsible for
presenting the game state and translating input into game commands that are then
sent to the game logic. What
'
s interesting about the game view is that it can have
different implementations, and you can have as many views attached to your game
as your computer can handle. One type of game view is for your players; it draws
the game state on the screen, sends audio to the speakers, and accepts input through
the user interface. Another type is the view for the artificial intelligence (AI) agent,
'
