Datasheet

MEMORY MANAGEMENT AND DISK SPACE 57
User::ResetInactivityTime() regularly, in the game loop. This
is unnecessary while the game is being played, because the user is
generating input. It should also cease when the game changes modes
to display the pause menu, to then allow the system to switch off the
backlight and display the screensaver as it normally would do.
Since simulating user activity during attract mode prevents the sys-
tem from saving power by dimming its backlight, the length of time
the game displays its attract mode should be limited, as section 2.6.2
described, unless the phone is powered externally by the main charger.
The CTelephony class can be used to retrieve information about
whether the phone is connected to a main charger, by calling CTele-
phony::GetIndicator().TouseCTelephony methods, you must
link against Etel3rdParty.lib, and include the ETel3rdParty.h
header file.
2.6.4 Saving Game Data
When the game is paused, it should save any important game state in case
it is needed to continue the game in the state it was in before pausing.
For example, the player may re-boot the phone before the game is next
played, but it should still be able to continue the game from the point
before it was paused. A player who has got to a particular level in a game
will not be happy if their progress is lost because they had to interrupt
their session.
A game should always save its data at regular intervals so it can be
restored to the same state, should the game suddenly be stopped, for
example if the battery power fails or the battery is removed completely.
In the event of a ‘battery pull,’ the game’s data manager code should
be prepared for the possibility that the data has been corrupted – such
as if an update was under way when the power down occurred. The
game should be able to recover from finding itself with corrupt data, for
example, by having a default set available in replacement, or performing
data updates using rollback.
When saving game data, it is important to consider the amount of
information that should be written to file. If there is a large amount
of data, for example over 2 KB, it is advisable not to use the blocking
RFile::Write() method, since this could take some time to complete
and would block the game thread. It is advisable to use an active
object to schedule the update, using the asynchronous overload of
RFile::Write(), or to use one of the higher-level stream store APIs.
2.7 Memory Management and Disk Space
Mobile devices have limitations on the amount of memory (RAM) they
can support for a number of reasons, including size (the limitations of the