Question Best practice to instantiate and simulate in the background

Hey Guys,

I need your help again. I'm still a beginner.

Situation
The player owns Units. These units are defined by ScriptableObjects but once the player bought them, they need to have individual values like health and stuff so I need to instantiate them. But I don't want then to shop up in scene yet. They get orders and do their job by harvesting or whatever. while doing that, they need to become invisible often because they are in (an inventory of) a house or cave. I still need to keep these things alive and keep their work going, even when they are not visible or if I change scene. At the least they age, even when stored in some List.

Question
What is the best practice to do that? Instantiate GameObjects as DontDestroyOnLoad and simply disable graphics? Or can Monobehaviors somehow "live" in a List in some GameManager without their own GameObject?

 

One way is to break up the visuals from the logic.

For instance the NPC logic would be concerned with all the internal bookkeeping, where it is, what it ultimately might look like, if it is visible now, etc.

The visuals would only be enabled if the thing was visible in game, and it would likely be turned on / off by either the root logic controller, or else some other visibility manager thingy.

Imagine a groundhog that sits there and turns off all his visuals and waits for groundhog day. On groundhog day he would turn on his visuals, look around, then decide what to do next. His logic would always be present, but his visuals would be turned on and off appropriately.

 

Thank you Kurt-Dekker!

I like the idea of splitting it. But how would I do that? How can I manage these monobehaviors without being visible? Do I need to have GameObjects without Graphics for all units or is there a better / different way?

 

I would structure the GameObjects in the unit to look like this:

BaseUnitWithAllScriptsHere <--- put scripts here obviously

    Visuals  <---- ALL visuals would go beneath here, animations, etc

    Colliders <---- if you have colliders?

That way the base script would have a reference to the Visuals and would enable/disable it on demand.

Depending on your need for colliders or other things, those might actually live at the root, OR they could live in the Visuals area, OR you could make another child as a peer of Visuals called Colliders.

 

I see. Just to recap:
I have the GameObjects with diabled graphics child living under DontDestroyOnLoad and keep them there, until I need them.

When I need them, I enable graphics and move them where I need them.

While not needed, I keep a list of these and run my own update function every now and then to reduce load on frame updates.

 

You would let the root object ALWAYS stay enabled so scripts on it would run the normal way that Unity calls Update()