koobas.hobune.stream
is it bad practice to have multiple serialized binary files for one save game?
I just watched the persisting data tutorial session (link) and learned about using serialization with singleton design. In the tutorial, all the save data (though minimal) was saved to a single file. In a real-world development scenario, would a want to always save all data to a single save file, or would it be just as well to split data into multiple files to keep things organized (and potentially minimize data loss in the case of corruption).
For example:
Consider the private classes playerData , LastSession, and GeneralSettings (which i know this last class is better served going into player prefs, but for the sake of example lets say it gets saved to a binary file). Following the tutorial, I would naturally try to save all this data into a file "AllData.dat" (Though hopefully a more creative name), and parse the data into all its individual data on load.
However, would it be just as acceptable to store a "PlayerData.dat", "LastSession.dat" and "GeneralSettings.dat" to separate them according to the relevant data inside? One downside I potentially see to this would be that it would make it easier for a hacker to find and edit relevant data, but if they can deserialize a binary file, they were probably going to figure it out anyway, in which cryptography would be the next step but thats overkill for my purposes.
Alternatively, is it also possible to take the three separate files and wrap them into one "AllData.dat" file?
I would keep settings seperate from saves probably in seperate directory too, as they have nothing to do with each other and handled differently, as for the saves keep a single file with anything that is needed to perform a load, breaking it to more files doesn't help if either one is corrupted, as all are needed to load.
Furthermore don't bother to make this data harder to be peeked at especially on developing process (text format/xml/json and so on are easy to be read manually for debug reasons of course) and if it is a single player game if someone wants to read/change those save data, just let them, it breaks their experience of the game.
Using a class that encaplulate other classes, as proposed below, is a must for organizasion but try to save the bare $$anonymous$$imum (for example for an inventory i like to save only the ids/ammounts, each item has an id, and any other value that can be changed, highly depends on the game).
Lastly try to avoid playerPrefs it is not nice to bloat the registry and deleting the game won't delete those entries unless an unistall wizard is used to take care of that, always hated games that leave chunks and bits all over the disc.
Cheers.
Why don't you create another "SaveData" class that holds your three class instances and you just serialize the SaveData class? The BinaryFormatter can serialize complex object trees.
Though the BinaryFormatter is not the best choice for savegames. Your existing savegames will break when you change anything in your serialized class. This includes adding, removing or renaming of fields.
If you like binary serialization just manually using a BinaryWriter / BinaryReader to write your desired values directly to the file. Of course it's recommended to store a version number in case you change something in the future.
Though formats like XML or JSON are much more flexible.
Thanks for the information! I'll likely look into X$$anonymous$$L or JSON for the data persistence structure in this case to ensure the structure is future proof.
