Java Reference
In-Depth Information
should design your game so that settings can be changed when it is in its
paused state.
TIP : Allow the user access to the game settings when the game is
paused.
Research has shown (and it's common sense anyway) that one of the
key indicators of customer satisfaction is the start-up time of a mobile
game. One of the best ways to reduce the perceived start-up time is the
use of a splash screen. The basic idea is to show something to the user
as soon as possible after they have started the application. Usually this is
a screen grab from the game itself, although in the mobile games world
it is often a high-resolution image created by a third-party graphic artist
that bears a somewhat dubious relationship to the actual game quality.
It can be an animation, a short movie video or title music - whatever
is appropriate. However it is done, the point is to show something that
catches the eye and entertains as soon as possible while performing
loading tasks in the background on a separate thread. These tasks can do
anything - commonly they are used to load meshes from the local store,
pre-fetch audio or video streams, download remote assets over a socket,
or pre-load and cache level data. Whatever the tasks are, the start-up
time of the game needs to be as fast as possible so feel free to cheat in
any way you can to achieve this. As a rule of thumb, game start-up times
should be no more than about three seconds.
TIP : Use a splash screen and background threads to reduce perceived
start-up time.
Once a game is up and running, it is the frame rate that determines
perceived performance to the end user. Generally speaking, we need to
aim for a frame rate between 15 and 25 FPS. Any more than 25 is probably
a case of diminishing returns and any less than 15 makes objects appear
to move in discrete jumps rather than smoothly. There are a variety of
techniques for maintaining a constant frame rate and we discuss them in
Section 8.4.1.
It is also essential to keep the rate at which you update the objects
in your world (the simulation rate) separate from the frame rate. The
simulation rate is usually dictated by the game physics engine. One of the
most common mistakes made by beginners in mobile game development
is to simply update the physics model once every game loop iteration.
This means that on fast hardware, integration of the physics model occurs
faster so objects move faster. It also means that as the frame rate varies
 
Search WWH ::




Custom Search