I would use JSON just because debugging is so much easier.
It’s also good you’re thinking about it right now, but only to an extent.
Spend a few minutes and make a placeholder main menu with NEW and LOAD buttons.
Spend a few more minutes and make a placeholder pause menu with SAVE and QUIT buttons.
Get something saving (and reloading!) immediately, even if it is just the name of your player or the amount of gold.
Either way, maintain 100% data vs presentation separation. Have 100% of your data stored within something that gets serialized by the existing LOAD / SAVE system you start with, just keep growing it.
It’s useful to put in a version number early so you can invalidate old saves as you restructure.
Load/Save steps:
An excellent discussion of loading/saving in Unity3D by Xarbrough:
And another excellent set of notes and considerations by karliss_coldwild:
Loading/Saving ScriptableObjects by a proxy identifier such as name:
When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. Save data needs to be all entirely plain C# data with no Unity objects in it.
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, so you end up with a defective “dead” Unity 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.
