Game Development Reference
In-Depth Information
Screen currentScreen = new MainMenu();
Float lastFrameTime = currentTime();
while ( !userQuit() ) {
float deltaTime = currentTime() - lastFrameTime;
lastFrameTime = currentTime();
currentScreen.updateState(input, deltaTime);
currentScreen.present(graphics, audio, deltaTime);
}
cleanupResources();
We start off by creating our game's window and the UI component to which we render and from
which we receive input. Next, we instantiate all the modules necessary to do the low-level work.
We instantiate our starting screen and make it the current screen, and we record the current
time. Then we enter the main loop, which will terminate if the user indicates that he or she wants
to quit the game.
Within the game loop, we calculate the so-called delta time . This is the time that has passed
since the beginning of the last frame. We then record the time of the beginning of the current
frame. The delta time and the current time are usually given in seconds. For the screen, the delta
time indicates how much time has passed since it was last updated—information that is needed
if we want to do frame-independent movement (which we'll come back to in a minute).
Finally, we simply update the current screen's state and present it to the user. The update
depends on the delta time as well as the input state; hence, we provide those to the screen.
The presentation consists of rendering the screen's state to the framebuffer, as well as playing
back any audio the screen's state demands (for example, due to a shot that was fired in the last
update). The presentation method might also need to know how much time has passed since it
was last invoked.
When the main loop is terminated, we can clean up and release all resources and close
the window.
And that is how virtually every game works at a high level: process the user input, update the
state, present the state to the user, and repeat ad infinitum (or until the user is fed up with
our game).
UI applications on modern operating systems do not usually work in real time. They work with
an event-based paradigm, where the operating system informs the application of input events,
as well as when to render itself. This is achieved by callbacks that the application registers
with the operating system on startup; these are then responsible for processing received event
notifications. All of this happens in the so-called UI thread —the main thread of a UI application.
It is generally a good idea to return from the callbacks as fast as possible, so we would not want
to implement our main loop in one of these.
Instead, we host our game's main loop in a separate thread that we'll spawn when our game
is firing up. This means that we have to take some precautions when we want to receive UI
thread events, such as input events or window events. But those are details that we'll handle
later on, when we implement our game framework for Android. Just remember that we need to
synchronize the UI thread and the game's main loop thread at certain points.
 
Search WWH ::




Custom Search