Game Development Reference
In-Depth Information
The GameScreen Class
There's only one more screen to implement. Let's see what that screen does:
As defined in Mr. Nom's design in Chapter
3, the game screen can be in one
of four states: waiting for the user to confirm that he or she is ready, running
the game, waiting in a paused state, or waiting for the user to click a button
in the game-over state.
ï?®
In the ready state, we simply ask the user to touch the screen to start the game.
ï?®
In the running state, we update the world, render it, and also tell Mr. Nom to turn
ï?®
left and right when the player presses one of the buttons at the bottom of the
screen.
In the paused state, we simply show two options: one to resume the game and
ï?®
one to quit it.
In the game-over state, we tell the user that the game is over and provide a button
ï?®
to touch so that he or she can get back to the main menu.
update()
and
present()
methods to
implement, as each state does different things and shows a different UI.
For each state, we have different
ï?®
Once the game is over, we have to make sure that we store the score, if it is
ï?®
a high score.
That's quite a bit of responsibility, which translates into more code than usual. Therefore, we'll
split up the source listing of this class. Before we dive into the code, let's lay out how we arrange
the different UI elements in each state. Figure
6-8
shows the four different states.
Figure 6-8.
The game screen in its four states: ready, running, paused, and game-over
Note that we also render the score at the bottom of the screen, along with a line that separates
Mr. Nom's world from the buttons at the bottom. The score is rendered with the same routine
that we used in the
HighscoreScreen
. Additionally, we center it horizontally, based on the score
string width.
