Heh… I’m not sure there is a “clean” solution.
This is really just an advanced savegame system where you will need to store enough information to essentially replay the user’s original intents when they built the scene, modified by whatever else happened to the scene chunks after they put them in place.
As usual the cleanest solution is going to be whatever the minimal engineering lift you can do is. If you just have a few fields in a few custom MonoBehaviours, might be easiest to just hard-code it with if-component-present checks. That will be far easier to debug than a more-generalized system.
OTOH, if you have and/or foresee a more open-ended situation, perhaps it would pay to make some kind of reflection-based analysis system that spins through the scene finding Components and plucking public fields out of them and storing them. And as you intuit, that gets hairy real fast, with IDs and deduplicating, etc.
Anyway… here’s my $0.02 paste-a-snippet for saves:
Load/Save steps:
My own take:
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 [ICODE]new[/ICODE] 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.