Everything discussed so far is bog standard savegame / loadgame functionality.
How big such a save/load facility ultimately gets is entirely dependent on things like how many rooms you have, how much data you save, and how you save it.
NONE of that is known about code that doesn’t exist, so I urge you to hurry with some basic prototyping, such as two rooms that link back and forth to each other and contain mutable saveable state (perhaps a lever or switch, perhaps the ability to store dropped items?), that you can use to test out how it works.
You’re far more likely to have issues with timing and restoring state in a way that does not have other transient effects to whatever else might be running in your game, so focus on getting that correct first.
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.
If you wanna make a really “hot” link between running scenes and background data, you can look into something like a data conduit to map unique identifiers in a scene to some kind of master data storage repository, but that’s pretty advanced stuff too:
Lightweight bidirectional delegates / conduits to data:
