Game Development Reference
In-Depth Information
Modeling your saved data
If we look to add the saving and loading options to our game, we need to take a few things
into account first. Consider that we just had a basic class for our player's state; the follow-
ing is an example:
[Serializable]
public struct Player {
public string Name;
public int Age;
}
Note
We attach the
[Serializable]
attribute to the class to tell the serializer that it is seri-
alizable data. This isn't mandatory as most sterilizers will work with most public classes
and serialize the public properties of that class, but not private properties though.
We could then simply save the class directly to the disk. However, because our player
definition inherits from our common
Entity
class and the
Entity
class inherits from
ScriptableObject
(so we could use it as a common base for all the characters of our
game), this means we cannot perform a simple serialization.
Note
If you wish, you could change this implementation, moving all the properties from the
Entity
class to the
Player
class and then marking it as
[Serializable]
; it's your
choice. I've kept it this way to show you the considerations needed to also serialize
ScriptableObject
. This is especially useful when (like we have in this game)
ScriptableObjects
are attached to our player, in this case, the player's inventory
(the inventory items are part of the project, and we attach them to the player).
So, as the data we want to serialize is more complex, the best thing to do is build a separ-
ate
Save State
class, which will model the data we want to save.
By defining a
Save
model, we can also tailor it to contain more than just one type of
data; it could contain other specific save information, such as the time in the world, enemy
progress (if the enemy AI is also marching through the world), and the current state of the
