That article covers a lot of different ways to save. Though I presume you mean the last post in said article.
In which case this is roughly the way to go.
So… really… there’s a few separate parts to “saving game data”.
- tokenizing your data - this is taking your in game information you want and deciding how you’re going to represent it when saving. In the case of PlayerPrefs, it’s the various names of properties you’ll stick into PlayerPrefs. In the case of the last post in that link of yours it’s this guy:
[Serializable]
class PlayerData {
public float health;
public float experience;
}
Basically you create a representative container of your data. In this example it’s just the ‘health’ and the ‘experience’.
-
serializing your data - next part is converting said data into actual byte data that can be stored. This can be serializing it to json using JsonUtility, or converting it to binary data using BinaryFormatter (like the last post in that link). This converts that token into something that can be written to disk. There’s also xml, yaml, ini, and several other formats… including custom formats… that you could serialize into.
-
writing to disk - once you’ve serialized the data it needs to be written to disk. In the case of json, you’d just save it as a text file (usually I suffix the text file .json). In the case of the BinaryFormatter, it writes to a ‘stream’, and if you give it a FileStream, it’ll write directly to a file on disk.
…
Now as for:
I’m assuming when you say “protected”, that you mean “not easily modified by the user”.
Protected is a hard thing to say… it really depends on the skill set of the user.
First off getting to the file is a concern. And really, you usually save the file somewhere in a user persistent data folder (like %appdata% on windows). Getting to this on android is sort of trivial, though most people don’t really go looking. But if you have someone who really wants to get at it… they can find it pretty easy. It’s on their phone, it’s sort of hard for you to block them from accessing their own phone.
In the case of say json or xml. The skill required to open the file and modify its values are fairly low. Both xml and json are common formats out there and are intended to be human readable/editable. Considering that the internet abounds with html/javascript, for which xml and json are closely related, lots of people have the experience required.
In the case of say yaml… it’s not as common, but is still designed to be human readable, and therefore relatively easy to modify.
BinaryFormatter is like obfuscating the data. The resulting format is so NOT human readable that modifying it can be sort of tough. But it’s not impossible… someone with enough gusto and will can modify it. If you’re just protecting against regular cheating… BinaryFormatter should do just fine (honestly I’m of the opinion that blocking a player’s ability to cheat is jsut wasted time… who cares if they want to cheat!? let them!)
That is unless you have a multi-player or monetary aspect to your game… in which case it might be important to block them from modifying the file. Since multi-player games can have other player’s experiences effected by cheaters… and monetary games can well… cost you money if they player cheats.
In this scenario… some may suggest encryption, but I would say only encrypt save files that MUST exist on the player’s machine. And those files should not contain critical save data (especially not monetary stuff). Problem is encryption by design needs to be decryptable, and since your game needs to be able to decrypt… that means the decryption key is going to exist somewhere in your game… someone willing to put in the effort can, and with enough gusto, will find the decryption key.
But really the best way to thwart cheating is to store said data online on your server that you can control the security of.
