koobas.hobune.stream
Optimal way to save minimal serialized scene status, at runtime
My usage case is this: a home scene with menus and submenus. After leaving it to a brand new scene, everything gets destroyed. When getting back to the home scene, everything is recreated. I wanted to return to the same submenu, thus I need to save its status some how.
The status isn't all that complex in the end. There are a few (NGUI) panels and only one is active at a time. I just need, basically, to remember the last one. Basically. So this doesn't need to be a complex scene serialization. I think. And it is in runtime, nothing to do with the editor!
I'm currently resolving this, using the gameobject's names. But they need to be unique and I use a *GameObject HardFind* (I hate how unity answers can't properly link to an answer!), which will search through all objects including disabled ones. So, that's all far from optimal.
Any better ideas on how to approach the issue? Any better solutions to this approach?
would it be possible to just deactivate the etire menu ins$$anonymous$$d of destroying it? If you put all of your NGUI panels under a single parent object then ins$$anonymous$$d of destroying the menu you could use gameObject.setActive(false) on the parent menu object. Then when you reactivate it it should be in the exact same state/location/everything that it was before.
I don't use NGUI so I'm not sure if this method would screw something up.
oops just re-read the question and realized that you are going to a new scene. So I guess you could stilldo what I just said but make the menu persistent across scenes. I'll admit this seems like a hacked solution (hence the comment vs. answer lol)
@TheValar yeah, but that's far from $$anonymous$$imal, isn't it? :P
well it will add a bit of clutter to your object hierarchy and the menu will remain in memory so yes not the most elegant solution. It does however have the advantage of being extremely simple to implement :)
Since unity doesn't have simple built in functionality to save (serialize) a scene, what you need to do is save all the data that you need to reproduce the current state in persistent storage (in our case persistent means something that is kept between scenes, unless you want it to remain between games and then you'd need to store it in the disk).
The easiest way in unity to do that, is store all the data you need inside a script attached to a GameObject, and use DontDestroyOnLoad to make sure that game object persists between loading scenes.
Then whenever the scene is loaded, you need to reproduce the last state using the information in that GameObject. In your case you might need to keep in the GameObject which submenu was open, and maybe any values that the user set in the menus. Then when the scene is loaded, read which submenu should be displayed from the object, and display it. Make sure that the same object puts in default values (the home menu I guess) in it's Start(), which will only be called the first time you load the menu, because in subsequent times it will not be re-created.
what's the advantage of using a hidden indestructible gameobject over creating a non-monobehaviour serialized variable (i.e. my current approach)?
Ins$$anonymous$$d of a GameObject set to DontDestroyOnLoad, an easier way (at least causing less clutter in the hierarchy) would be to use a static class to remember which menu window was open and on reloading the menu scene, set the active menu to that.
EDIT: Any GameObject takes up memory, not only is it an object itself, but has a Transform class as well (plus any other memory it might reserve internally). While not a whole lot of memory, it's still more than a single static class.
The obvious advantage is that a GameObject can receive the Unity callbacks (Start, Update etc.)
Static class works as well, and so does a serializable variable, but then you'll have to serialize it and keep it somewhere (disk?). The DontDestroyOnLoad is just a way to keep the data in memory, ins$$anonymous$$d of writing to disk. Static class is a bit cleaner, as @Jamora said (thumbed up), though a bit less 'Unity' way of doing things. Your choice, there are many options.
I think static classes are a very bad choice. I'm currently using singletons but I'll soon change to a **Singleton Toolbox** ins$$anonymous$$d.
it seems the question has been moved (sort of) to here http://answers.unity3d.com/questions/570319/dynamically-keep-game-object-reference-after-destr.html
Should this question still be considered open since it has been reiterated?
