This is not really the approach you want for save game use. Instead, identify the necessary parts you need to save for state-of-a-game, and isolate those parts and only save those parts.
Keep in mind also you may need to change your scripts so that they can be created blank, then subsequently post-creation initialized back to any arbitrary later-in-game state. Doing this may be trivial, or it may require a complete refactor.
In any case, the idea behind game saving is to save JUST what you need and nothing more.
For object pools I just call .SetActive(false) on the root game object and forget about it.
When it’s time to resurrect the object for reuse, you already have to be sure you initialize all fields, so just do that.
That will take care of it in one place that requires no additional maintenance beyond keeping it up to date for that object, which in the case of necessary initializers, you have to do anyway just to use it.
The problem is that child objects could have different positions at the time the object is disabled. Those child objects all need to be reset to their original prefab state.
My solution is just to iterate over all the child transforms and save / revert their state (using the above class) when they are enabled/disabled.
It just seems like such a common thing to be forced to do all the time. I wanted to ask if anyone had a better solution.
I am doing the same thing Kev00 is doing, it’d be awesome to have this feature.
I’m doing it by hand now, and it’s true… it is not “elegant”. A feature that just allows us to save a game object state at any point, and then tell the object to restore it’s state at any point in the game would help a lot on object pooling.
It’d have to work, not only for the game object transform and active/unactive state, but also for all of his components. (And children)