Game Development 101 - Beginning Android Games - page 97

Pixmap.dispose() method. Pixmap instances use up
memory and potentially other system resources. If we no longer need them,
we should dispose of them with this method.

ï?® Finally, there's the

With this simple graphics module, we can implement Mr. Nom easily later on. Let's finish this
chapter with a discussion of the game framework itself.

The Game Framework
After all the groundwork we've done, we can finally talk about how to implement the game itself.
For that, let's identify what tasks have to be performed by our game:

ï?® The game is split up into different screens. Each screen performs the same

tasks: evaluating user input, applying the input to the state of the screen,
and rendering the scene. Some screens might not need any user input,
simply transitioning to another screen after some time has passed
(for example, a splash screen).

ï?® The screens need to be managed somehow (that is, we need to keep track

of the current screen and have a way to transition to a new screen, which
boils down to destroying the old screen and setting the new screen as the
current screen).

ï?® The game needs to grant the screens access to the different modules (for

graphics, audio, input, and so forth) so that they can load resources, fetch
user input, play sounds, render to the framebuffer, and so on.

ï?® As our game will be in real time (that means things will be moving and

updating constantly), we have to make the current screen update its state
and render itself as often as possible. We'd normally do that inside a loop
called the main loop . The loop will terminate when the user quits the game.
A single iteration of this loop is called a frame . The number of frames per
second (FPS) that we can compute is called the frame rate .

ï?® Speaking of time, we also need to keep track of the time span that has

passed since our last frame. This is used for frame-independent movement,
which we'll discuss in a minute.

ï?® The game needs to keep track of the window state (that is, whether it was

paused or resumed), and inform the current screen of these events.

ï?® The game framework will deal with setting up the window and creating the

UI component we render to and receive input from.

Let's boil this down to some pseudocode, ignoring the window management events like pause
and resume for a moment:

createWindowAndUIComponent();

Input input = new Input();
Graphics graphics = new Graphics();
Audio audio = new Audio();