Super Jumper: A 2D OpenGLES Game - Beginning Android Games - page 474

Remember how we defined the game-over state: Bob must leave the bottom of the view
frustum. The view frustum is, of course, governed by a Camera2D instance, which has a position.
The y coordinate of that position is always equal to the biggest y coordinate Bob has had so
far, so the camera will somewhat follow Bob on his way upward. Since we want to keep the
rendering and simulation code separate, though, we don't have a reference to the camera in our
world. We thus keep track of Bob's highest y coordinate in updateBob() and store that value in
heightSoFar . We know that our view frustum will have a height of 15 meters. Thus, we also know
that if Bob's y coordinate is below heightSoFar - 7.5, then he has left the view frustum on the
bottom edge. That's when Bob is declared to be dead. Of course, this is a tiny bit hackish, as
it is based on the assumption that the view frustum's height will always be 15 meters and that
the camera will always be at the highest y coordinate Bob has been able to reach so far. If we
had allowed zooming or used a different camera-following method, this would no longer hold
true. Instead of overcomplicating things, we'll just leave it as is though. You will often face such
decisions in game development, as it is hard at times to keep everything clean from a software
engineering point of view (as evidenced by our overuse of public or package private members).
You may be wondering why we don't use the SpatialHashGrid class we developed in Chapter 8.
We'll show you the reason in a minute. Let's get our game done by implementing the GameScreen
class first.
The Game Screen
We are nearing the completion of Super Jumper. The last thing we need to implement is the
game screen, which will present the actual game world to the player and allow the player to
interact with it. The game screen consists of five subscreens, as shown in Figure 9-2 earlier in
the chapter. We have the ready screen, the normal running screen, the next-level screen, the
game-over screen, and the pause screen. The game screen in Mr. Nom was similar to this; it only
lacked a next-level screen, as there was only one level. We will use the same approach as in Mr.
Nom: we'll have separate update and present methods for all subscreens that update and render
the game world, as well as the UI elements that are part of the subscreens. Since the game
screen code is a little longer, we'll split it up into multiple listings here. Listing 9-20 shows the
first part of the game screen.
Listing 9-20. Excerpt from GameScreen.java; Members and Constructor
package com.badlogic.androidgames.jumper;
import java.util.List;
import javax.microedition.khronos.opengles.GL10;
import com.badlogic.androidgames.framework.Game;
import com.badlogic.androidgames.framework.Input.TouchEvent;
import com.badlogic.androidgames.framework.gl.Camera2D;
import com.badlogic.androidgames.framework.gl.FPSCounter;
import com.badlogic.androidgames.framework.gl.SpriteBatcher;
import com.badlogic.androidgames.framework.impl.GLScreen;
import com.badlogic.androidgames.framework.math.OverlapTester;
import com.badlogic.androidgames.framework.math.Rectangle;