Saving Player Data

Save Systems

While not every game needs one, when a game does need a save system it must be done right. Luckily there are multiple approaches to this in Unity. I plan on going over a couple for this Devlog.

PlayerPrefs

The first one I want to cover are PlayerPrefs. PlayerPrefs are very simple to implement, requiring only two lines of code one to save and one to load.

PlayerPrefs can be stored as an Integer (10), Float (10.0), or String (“Ten”). The first parameter of the function is the key used to reference the stored value, it must be the exact same or it will reference an entirely different value.

Now honestly PlayerPrefs should only be used for Settings, Highscore, and/or Player name, because of the aforementioned key as well as each value that needs to be stored would require an additional two lines for each which can make your code very awkward to read and debug. One final constraint of this method is storing complex values like Vectors, or custom classes. This is where the other methods come into play.

Saving and Loading a file

Now this method requires the use of System.IO namespace which allows us to read and write files, and other things that are outside of the scope of this Devlog. With this namespace added we can save player data to all sorts of file types. For the majority of the time you’ll want to use a Text, Json, or XML file. As for which out of those three you should use, In my experience it is mostly down to preference.

Text File

Saving and Loading from a text file is very simple and uses these two lines of code. 

Note that this both stores and returns as strings so you may need to convert strings into other data types. This text file is very easy to edit externally as they are glorified sentences so probably not the best for developers that want to discourage cheaters. Honestly besides very specific applications you are better off with the other file types, but it is nice to know. Now an important thing to note is the path parameter which I will explain after I show how to save and load the next two types. 

JSON and XML

Before we begin this section I want to note that JSON and XML are very different under the hood and are only  grouped together here because for basic use they are very similar in implementation. For both we can use a serialized class or struct to “Combine” multiple values into one that we then save as a JSON or XML.

 The biggest benefit is that when we load the save file we don’t have to individually load each value like with PlayerPrefs or convert from a string like with text files. Saving and loading a json is as simple as 

(prettyPrint is an optional parameter that formats the JSON in rows for readability)

Saving and loading from an XML requires a few more steps. We need the System.Xml.Serialization namespace and a serializer.

Technically the serializer does not need to be stored but I’d rather make it once when the application is opened. Now it's very simple to Save and Load from the XML file.

It is very important that you close the stream when you are finished as that frees the resources it used and prevents the file from being considered open by the application, which would prevent you from accessing that file again until it is closed.

One last nice thing about JSON and XML is that the file ending can be anything. So instead of Save.json or Save.xml we can have Save.data or [Player Name].savedata

Binary Formatting

Technically we could save the serialized class directly using binary formatting.

Like JSON and XML you can make the file ending anything, and unlike the others the average player is not going to tamper with as it is in binary this however makes them really hard to debug as it doesn’t get shown as 01010011 01101110 01100001 01110000 01100010 01100001 01100011 01101011 but a seeming random collection of symbols and value names. It also can open your players to malice code if the game loads a save file that a bad actor has created or modified. Overall avoid this method. It offers very little that other methods can’t do better.

Save Location

As I mentioned earlier we will be talking about path or more specifically the Save file Path. This is where the game saves and finds the Save file on your system, eg. C:\Users\J Carmon\Documents\30XX. Given how your game may be played on a variety of Operating systems and machines as well as the way players may have their files structured, it is very important that we have a consistent file location the game can find no matter what. Lucky Unity has this as Application.persistentDataPath. This path is always accessible to Unity as a directory and is the best place to store player saves. Now where this varies based on a couple of factors but this is a list of the common paths Unity - Scripting API: Application.persistentDataPath. Using this we can code the path directly to our save system.

We can even make a folder for our saves. 

Editor Prefs

I also want to mention this as it can be quite useful for Tool creation but Editor prefs can be used to save an Int, Float, string, or even a bool that will always be the same even between projects. This can not be used for gameplay and is purely for editor use. Implementation wise they are just like Player prefs.