It has no handle to the game thread so this cannot be explicitly
The flag variable running is set afterthe call to Thread.start() -
so if the game thread starts and is immediately pre-empted by another
thread before line 43 executes, the application is left in an inconsistent
Access to the flag variable running is not synchronized across
the GUI and game loop threads (e.g., by using the Java keyword
volatile in its declaration).
It creates a large number of new object instances (Sprites in this case)
instead of re-using a pool of them. The amount of heap in use at any
time depends completely on how often the garbage collector runs.
No effort is made to manage the frame rate. The thread simply sleeps
for 50ms each time the game loop executes. Changing the sleep
period speeds up or slows down the movement of the ghost sprites.
There is no way to turn off the tone sequence used for sounds. This is
There is no concept of 'game over' - it just runs forever with no
It uses magic numbers (line 131) for special key codes instead of
defining them as constants. Unfortunately, you also can't use the Can-
vas.getGameAction() method to handle softkey events because
these are not part of the standard MIDP key mappings and are specific
to each manufacturer.
8.2.3 Debrief Summary
So far we have discovered two important concepts regarding game
development with Java ME:
It is really easy to write Java games.
It is really easy to write Java games badly.
This is not all that surprising. The vast majority of mobile phones in the
mass market at the time MIDP 2.0 was designed had a number of built-in
limitations. So MIDlets did not have much memory, little local storage
space and were rarely paused. Few mobile-phone operating systems are
multitasking and MIDlets that lose focus are often terminated outright. A
direct consequence is that there is a large code base of Java ME sample
code in existence that takes little or no heed of the pause-resume cycle.
It is common to see (as above) a start() method on the GameCanvas