Game Development Reference
In-Depth Information
Note Yes, we deliberately left out networking from the preceding list. We will not implement
multiplayer games in this topic. That is a rather advanced topic, depending on the type of game. If
you are interested in this topic, you can find a range of tutorials on the Web. ( www.gamedev.net
is a good place to start.)
In the following discussion, we will be as platform-agnostic as possible. The concepts are the
same on all platforms.
Application and Window Management
A game is just like any other computer program that has a UI. It is contained in some sort of
window (if the underlying operating system's UI paradigm is window based, which is the case for
all mainstream operating systems). The window serves as a container, and we basically think of
it as a canvas from which we draw our game content.
Most operating systems allow the user to interact with the window in a special way, besides
touching the client area or pressing a key. On desktop systems, you can usually drag the
window around, resize it, or minimize it to some sort of taskbar. In Android, resizing is replaced
with accommodating an orientation change, and minimizing is similar to putting the application
in the background, via a press of the home button or as a reaction to an incoming call.
The application and window management module is also responsible for actually setting up the
window and making sure it is filled by a single UI component to which we can later render and
that receives input from the user in the form of touching or pressing keys. That UI component
might be rendered via the CPU, or it can be hardware accelerated, as is the case with
OpenGL ES.
The application and window management module does not have a concrete set of interfaces.
We'll merge it with the game framework later on. The things we have to remember are the
application states and window events that we have to manage:
Create : Called once when the window (and thus the application) is started up
Pause : Called when the application is paused by some mechanism
Resume : Called when the application is resumed and the window is again in
the foreground
Note Some Android aficionados might roll their eyes at this point. Why use only a single
window ( activity in Android speak)? Why not use more than one UI widget for the game—say,
for implementing complex UIs that our game might need? The main reason is that we want
complete control over the look and feel of our game. It also allows us to focus on Android game
programming instead of Android UI programming, a topic for which better topics exist—for
example, Mark Murphy's excellent Beginning Android 3 (Apress, 2011).
 
Search WWH ::




Custom Search