Game Development Reference
In-Depth Information
Chapter
9
Handling Persistent Data
CMOD is looking good now, and we could improve it even further by adding more levels and
environments, such as rooftop levels, basements levels, and even exterior levels. If we did that,
however, it'd be useful for gamers to be able to save their games so that the next time they played,
they could resume from where they left off, preventing them from repeating their actions every
time. In other words, if we're to expand the game, it'd be helpful for the gamer to have save-game
functionality. Achieving this effectively means we'll need to store game data
persistently
on the local
computer, between playing sessions, so that even between powering the computer off and on, the
save-game data persists to be restored. Thankfully, Unity and Mono offer a range of handy features
and classes for handling persistent data, and these will constitute the focus of this chapter as we
implement load-and-save game functionality for CMOD. So let's go!
Persistent Data: PlayerPrefs, Binary Data, and More
Persistent data
is a catch-all term for any game data that should remain across playing sessions.
Unlike most game data, which is volatile and terminates when the game ends, persistent data
is stored locally on the hard drive or other storage, and can be retrieved again for later playing
sessions, even if the computer has been turned off or restarted in the interim. Hence, such data is
said to
persist
. The most common use of persistent data is for storing game states, allowing gamers
to resume from where they left off. Other uses include storing character profiles, screenshots, voice
recordings, preferences and settings, network information, and also game licensing data. For CMOD,
we'll be creating save-game functionality only.
Unity offers two main ways to create persistent data: one is to use the Player Preferences class,
which acts like a cross-platform database with key values, and the other is to use system files
(such as binary files and XML files). Before proceeding with our work on CMOD, I want to briefly
consider the options that we
won't
be using throughout the rest of this chapter to give you an
overview and appraisal of those features, and to explain why we won't be using them here.
281
