You still haven’t said what didn’t work. You linked the Version tolerant documentation page of microsoft, but did you actually read it? Have you looked at the example project? All you have to do is add the “OptionalField” attribute to all new variables. I just tried it and it works out of the box. I copied your class, saved a version to a file, added a new variable and mark it with OptionalField. like this:
[OptionalField(VersionAdded = 2)]
public string test;
I can load the previously saved class without any issues. If course the “test” variable doesn’t have any value since that field doesn’t exist in the save file yet. Just like shown in the example project you can add a “OnDeserialized” callback to check and post process any variables which might not have been initialized. For example like this:
[OnDeserialized]
void OnDeserialized(StreamingContext context)
{
if (string.IsNullOrEmpty(test))
test = "Hello !!!";
}
Now when i load the old save “test” will be initialized with “Hello !!!” after deserialization. If you change the new field now manually and serialize the new class again the test field will get serialized and deserialized automatically.
Keep in mind that version tolerant serialization is not backwards compatible. You can not remove any field just like explained in the docs you’ve linked. So if you store an object from a newer version of your application that has additional optional fields, those can not be opened by your old application.
Finally I’d like to mention that the BinaryFormatter is as insecure as PlayerPrefs are. What makes you thing that the BinaryFormatter is more secure? If you mean that it’s not that easy to read or change the values, this is just security through obscurity and does not provide any security at all. It may scare off some pure noobs, but those are also incapable to figure out where the PlayerPrefs are stored.
The BinaryFormatter stores the values unencrypted as plain values, just in binary. You can easily edit those with any hex editor. I actually have one in my context menu and can open any file directly with a hex editor.
If you want to make it a bit more secure (note that 100% security is absolutely impossible when you have the code to execute on the client and the data stored on the client) you should add some sanity checks and checksums that you store along with your actual data. If something got changed you can detect that. This is still not secure but the cheater has to figure out how you calculate the checksum in order to successfully manipulate any value.
I also recommend a “late fail” method if you detect changed values. So just load the values and let the game run for a few minutes and then just close the program and delete the save that was changed. Don’t tell the user you caught him cheating. A several minute delay has the advantage that it makes it tedious to test if his manipulations are successful or not. In addition you could sabotage the game slightly when it has the state “cheated”. This is basically cheater trolling, the only form of trolling that i would consider valid.