Good practice with runtime instantiation

HI everybody !
Got a question about what’s good practice for runtime instantiation.
In the Argon Assault project, Ben does something that I don’t fully understand?

He has that game object wich is a ship and he wants to play some fx when it dies.
To do so, he instantiate at run time (when the ship “blowing up method” is called) an FX game object containing a particle system and an audio player.

But, said fx game object spawns at the root of the hierarchy. I understand that it isn’t something you want. Aspecially when you get lots of them spawning in a scene.

But what bugs me is that he proceed to “fix” that issue by childing this fx game object to a “folder” game object called “spawned at run time”.
Why wouldn’t you child this fx to the gameobject it is related to?

Assuming you’re going to do that to every game object spawned at run time. Isn’t it just sweeping the problem under the rug?
Like : Ok. The root of your hierarchy isn’t a mess anymore. But you get that “spawned at run time” gameobject overflowing with children.

ps : I read my post a couple of time to make sure that it is understandable. But my english isn’t at its best shape right now. So feel free to ask for clarifications. :slight_smile:

A spawned game object still exists so it really doesn’t matter if it is in an empty game object or not. But you might parent it to a game object so it maintains the same world space. It still consumes memory.

So if spawn at start then to get the longer calls out of the way. You may want to look at object pooling.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms