Game Development Reference
In-Depth Information
The Game and Screen Interfaces
With all of that said, let's try to design a game interface. Here's what an implementation of this
interface has to do:
ï?®
Set up the window and UI component and hook into callbacks so that we
can receive window and input events.
ï?®
Start the main loop thread.
ï?®
Keep track of the current screen, and tell it to update and present itself in
every main loop iteration (a.k.a. frame).
ï?®
Transfer any window events (for example, pause and resume events) from
the UI thread to the main loop thread and pass them on to the current
screen so that it can change its state accordingly.
Input
,
FileIO
,
ï?®
Grant access to all the modules we developed earlier:
Graphics
, and
Audio
.
As game developers, we want to be agnostic about what thread our main loop is running on and
whether we need to synchronize with a UI thread or not. We'd just like to implement the different
game screens with a little help from the low-level modules and some notifications of window
events. We will therefore create a very simple
Game
interface that hides all this complexity from
us, as well as an abstract
Screen
class that we'll use to implement all of our screens. Listing 3-8
shows the
Game
interface.
Listing 3-8. The Game Interface
package
com.badlogic.androidgames.framework;
public interface
Game {
public
Input getInput();
public
FileIO getFileIO();
public
Graphics getGraphics();
public
Audio getAudio();
public void
setScreen(Screen screen);
public
Screen getCurrentScreen();
public
Screen getStartScreen();
}
As expected, a couple of getter methods are available that return the instances of our low-level
modules, which the
Game
implementation will instantiate and track.
The
Game.setScreen()
method allows us to set the current screen of the game. These methods
will be implemented once, along with all the internal thread creation, window management, and
main loop logic that will constantly ask the current screen to present and update itself.
