Hi all!
I only know a couple methods used to save game data, but for what i’m going for i’d need one that is quick and relativly safe.
By quick i mean something like: you buy a house in game, and your properties list and money count get instantly updated and saved so that you can’t change your mind and alt+f4 the game to make another choice.
The game that i’m working on has a side of “life simulator”, so it has lots of variables like the ones in the example above that need to be quickly saved: money, tiredness, in-game day, relationship indicators… that sort of stuff.
How can i archieve a game that saves everithing you do, without tanking performance (and possibly where saves aren’t easy to “hack”)?
Thx for reading.
P.S.: the game “updates” always after a player choice, kinda like if it was turn based. Example: the time of day doesn’t advance on its own, instead it changes form night to morning if the player decides to sleep, or work all night.
This should be true for all variables, so no need to constantly keep saving some variables as they all get updated always after specific inputs.
Unless you have lots and lots of development time to spare, just save what you need.
Load/Save steps:
When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object.
Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.
If you want to use PlayerPrefs to save your game, it’s always better to use a JSON-based wrapper such as this one I forked from a fellow named Brett M Johnson on github:
Do not use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.
If you’re concerned about the user ‘hacking your save files,’ or ‘cheating in your game,’ just don’t be. There’s nothing you can do about it. Nothing is secure, it is not your computer, it is the user’s computer. If it must be secure, store it on your own server and have the user connect to download it.
Anything else is a waste of your time and the only person you’re going to inconvenience is yourself when you’re debugging the game and you have savegame errors. Work on your game instead.
Remember, it only takes one 12-year-old in Finland to write a script to read/write your game files and everybody else can now use that script. Read about Cheat Engine to see more ways you cannot possibly control this.
When it comes to security I always liked the phrase: “Hackers gonna hack” - which simply means don’t waste your time trying to stop it, focus your energy on adding fun and releasing - trust me you’re gonna need it. Only way to properly secure anything is to not execute code on machines you don’t control (server authoritative games) and the cost benefit of that is going to be a massive net negative for all but competitive multiplayer games.
Right, also keep in mind that something like the equivalent of a “replay-attack” is almost always possible. That means the player can simply copy / save the save files somewhere else and later just replace the save files and he’s back where he was before his “bad in-game decision” and try another route. That’s something you can not really prevent if you store the game data on the users machine. The only solution here would be to off-load all major game mechanics and game state to a server you control (see any MMO or competitive online game). Of course running and hosting servers is not only expensive but requires constant maintenance. Also the overall structure has to be designed in a way to detect and prevent manipulations. The general server attitude should be: always expect tampered data and how to deal with it. This is a quite tricky business.
Though for singleplayer offline games, as the others have said, it’s essentially wasted time spend. The majority of players are usually tech noobs and can’t even figure out where the relevant data is stored or how they can manipulate it. Apart from that most don’t even think about how they can cheat, that’s only a tiny minority. Of course you can always add a bit obfuscation or tamper checks into the save files to scare off the above average user. Though you can never stop / prevent manipulation completely.
I remember that for a short time period I had used the shareware Milkshape 3D in the past. It had a 30 day testing period. It wrote the “install date” to 5 different places (3 registry keys and 2 files in system folders). If you removed one or all but one it would recreate all the others and the time was still ticking down. If you knew all 5 spots and removed them you got a fresh 30 days period at the next start. I even made a tool to clean up the mess the software left behind on my system, though I never shared it My point is they jumped through some hoops in order to “protect” their test version but it was quite trivial to bypass.
Me personally, I don’t care if someone cheats. They only cheat themselves. I still made a sale and that’s the point. Don’t care if they break the game for themselves, that’s their problem they paid for that.
Now if they pirate my game I’ll be upset, but still nothing I can do about it, no amount of DRM will stop any one from changing SOFTware.
Edit: I wish we could down vote comments, especially about binaryformatter.
Thanks to everyone for the answers
You are right about not getting crazy trying to protect the saves… i wanted to be sure that the game wasn’t easily cheesable, but at the end of the day if they ruin the game it’s their loss (or gain!). I’ll look into @Kurt-Dekker 's suggestion about PlayerPrefs, and thanks for the info about the binaryformatter, since i’ve used it in the past.
Thanks again and sorry for the late answer!
My point is they jumped through some hoops in order to “protect” their test version but it was quite trivial to bypass.