Hi, I didn’t find a definitive answer to this, so here we go.
I am looking to handle world object persistence. Imagine a player picks up/destroys one-of-a-kind object (originally in a scene, not dynamic). I’d like to persist that change onto next playing session. This is the scheme I am thinking to implement:
Essentially, a manager adds and persists references of destroyed scene objects from session to session.
player activates scene object → object gets destroyed/disabled → it notifies a manager → manager adds reference of this object to a list → list is saved after session ends → on next session object checks with manager, if the reference to it is there, then object destroys itself.
I have a hunch that destroyed GameObjects in this scenario will stay as zombies, because as I’ve read, a destroyed object uses overriden == operator to show null, but the object is just set in engine as destroyed until all references to it are lost, and only then would GC collect it.
My questions are:
Is my guess correct?
Should I just keep objects disabled instead of destroying them?
Some other better way for handling world object state persistence? (I mean, obviously using ids etc would be better, but maybe there’s some lightweight solution I am missing?)
First, there is no way to keep references to destroyed objects, when they are destroyed they are gone.
What you say about “zombie objects” is not correct. A UNITY object has two representations, one in the C# side and one in the C++ side, the moment you destroy it the C++ object is destroyed, but the C# is still there for some time without having access to a lot of information that existed on the C++ side.
Yes, you should just keep objects disabled instead of destroying them, if you want to use them again.
Another way, is to disable only the components that are performance heavy and move those objects off the screen, another is object pooling, but these are extreme situations that increase complexity and the difficulty of debugging by a lot.
You shouldn’t be looking for lightweight solutions before you have a solution and you find out that it affects your performance. 99.9% of the time lightweight solutions are not needed from the start.
Spend your time making your game instead of thinking about future performance problems.
Here’s an observation I made:
If I serialize a list of scene gameobjects in inspector, then destroy some of them - I can see the destroyed object in a list as “Missing game object”, then when I exit play mode - the object is no longer missing. So references to destroyed objects persist, and if it’s an object that’s been in the scene to begin with - the reference seems to stay intact.
Am I misunderstanding something?
I understand that Unity will try to clear as much as possible of a destroyed object (like components etc, and hence the override on == operator to show null), however, if I have a reference to a GameObject - seems like it stays unless I clear it. Soooo… save it and load it to check on next play session?
Yes.
When you enter play mode you’re playing a copy of the scene. When you leave it, you return back to the original version. These references are not being restored, you’re just returning to a difference instance of the scene. Unity is not rewinding everything you do in play mode.
1 Like
you are asking the wrong question.
you should look at techniques and methods (or asset store products) that save and load data. then use the one that make sense for your game.
answering your question (but this is not a good answer as stated above) you could keep track of the objects you want to be removed as assets to be optionally loaded when the level is loaded. so if you have a banana on a table you have an option in some dictionary or something to load that asset. if the banana had been eaten by the player you don’t load the asset (so is not in memory, it doesn’t uses resources, it doesn’t exist) if the banana respawn after some time because player in game mother keep purchasing bananas then you can load it again after some timer)
but you should look into saving/loading and not reinvent the wheel
Thanks for the answers, guys. I think I understand.
I’ll just go a classical route, probably something like this:
Manager: put persistent scene objects into an array + have a related status array that can be serialized/saved.
Ofc +some coherency checks and additional things to make it look pretty/easier to handle in inspector~
I guess this is the way I’ll go for this one.