Mobile Game: UFO Zapper

Mobile Game: UFO Zapper

The concluding example of this chapter is a game. In contrast to the
Hangman server that was presented in Section 4.5, this is a classic singleplayer
action game with stunning graphics – just see Figure 5.9. Your job
is to save the world from a squadron of invading UFOs with a moving
pad that shoots laser beams (ahem).


You must shoot down as many UFOs as possible within a given time
limit. You get points for each hit: the smaller the UFO you hit the more
points you get. Try to beat our highest score of 2304 points!


Structure of a Game Application
The example presents several useful concepts that are often used in game
applications:
• an event loop to control the application
• dynamic time
• double buffering
• module random.
Using an event loop to control an application
At the beginning of Chapter 4, we noted that we have to use the
e32.Ao lock object to stop the execution and start waiting for the
user input. However, in an action game something should be happening
all the time, even if the user does nothing. Thus, instead of a lock, the
game application is controlled by an event loop.
An event loop is typically a simple while loop which takes care
of advancing time step by step. Like Ao lock, the loop prevents the
application from exiting instantly.
Whereas an animation proceeds from start to end without any user
interaction, a game must react to user input. This is handled in a similar
way to any other application, using event callbacks, which may change
values of global variables and thus change the game state. Overall, the
structure of an event loop is typically as follows:


Initialize event callbacks
while <end condition>:
Update game state
Redraw screen
Pause
The last command in the event loop instructs the execution to pause
for a while. We want the event loop to iterate as fast as possible, but we
want to control its speed. We need to give the user some time to perceive
what is happening in the game, as human perception is extremely slow
compared to the 200–300 MHz CPU of a modern mobile phone. We
also want to give the application some time to react to user events.
For the above reasons, we pause the event loop for a short while after
each iteration. The e32.ao sleep() function pauses the execution for
the given time, which can be a fraction of a second. In this case, we
pause for a hundredth of a second, e32.ao sleep(0.01), after each
iteration. This means that the game is capable of showing 100 frames per
second (FPS) at best.

Dynamic time

In some cases we want to give the user more time to observe the situation.
In this game, we increase the length of the pause to a tenth of a second
when a laser beam is fired, so that the user can see how many hits she
scored. The ability to change the length of the pause in the event loop is
called dynamic time.
In an extreme case, we might want to pause for the minimum possible
amount of time, 0 seconds, but let the application handle any user input
anyway. For this purpose, a special function called e32.ao yield()
is provided. By calling this function, you ensure that the user interface
stays responsive although your application may perform computation in
a tight loop at full speed.