Game Development Reference
In-Depth Information
The
Game.getCurrentScreen()
method returns the currently active
Screen
instance.
We'll use an abstract class called
AndroidGame
later on to implement the
Game
interface, which
will implement all methods except the
Game.getStartScreen()
method. This method will be an
abstract method. If we create the
AndroidGame
instance for our actual game, we'll extend it
and override the
Game.getStartScreen()
method, returning an instance to the first screen of
our game.
To give you an impression of how easy it will be to set up our game, here's an example
(assuming we have already implemented the
AndroidGame
class):
public
class MyAwesomeGame
extends
AndroidGame {
public
Screen getStartScreen () {
return new
MySuperAwesomeStartScreen(
this
);
}
}
That is pretty awesome, isn't it? All we have to do is implement the screen that we want to use
to start our game, and the
AndroidGame
class will do the rest for us. From that point onward,
our
MySuperAwesomeStartScreen
will be asked to update and render itself by the
AndroidGame
instance in the main loop thread. Note that we pass the
MyAwesomeGame
instance itself to the
constructor of our
Screen
implementation.
Note
If you're wondering what actually instantiates our
MyAwesomeGame
class, we'll give you
a hint:
AndroidGame
will be derived from
Activity
, which will be automatically instantiated by
the Android operating system when a user starts our game.
The last piece in the puzzle is the abstract class
Screen
. We make it an abstract class instead
of an interface so that we can implement some bookkeeping. This way, we have to write less
boilerplate code in the actual implementations of the abstract
Screen
class. Listing 3-9 shows
the abstract
Screen
class.
Listing 3-9. The Screen Class
package
com.badlogic.androidgames.framework;
public abstract class
Screen {
protected final
Game game;
public
Screen(Game game) {
this
.game = game;
}
public abstract void
update(
float
deltaTime);
public abstract void
present(
float
deltaTime);