Spawning Objects in Unity without the Clutter
Learning how to instantiate objects at runtime can be quite fun and liberating when it comes to developing our own games. This article should provide some guidance on how to instantiate as well as parent (and destroy) these newly-created GameObjects.
Prefabs
Before we instantiate anything, we need to create a prefab in Unity for the GameObject we want to instantiate. This essentially allows us to package up an object from the scene so we can reuse or spawn it whenever we’d like. We can do this simply by dragging a GameObject from the hierarchy to the Assets folder.
Instantiating
Once we’ve done so, we can then create a public or serialised private GameObject variable in the class we’ll use to spawn them, drag the object we want to spawn to it in the inspector, and then use the instantiate method:
This will spawn the GameObject at point 0, 0, 0 in the world, but since the Instantiate method accepts multiple parameters we can specify exactly where we’d like to spawn:
Going with the first of these three options will automatically parent the newly created GameObject to the GameObject this script is attached to, whereas the other two will just add the new GameObject to the bottom of the scene’s hierarchy. To avoid building up a long list of GameObjects like this in the hierarchy, we can also just set the parent of the new GameObject (after having first created a reference to it):
Dealing with Clutter
The other part of the equation is thinking about how we can prevent too many of these objects existing within the scene at a given time. There are multiple ways we might go about this:
- We could add each instance to a List, removing them if/when they’re destroyed, and only spawning them if the List’s length is, for instance, no greater than 4.
- Equally, we could use this list to destroy and remove the first in the list as soon as the list has exceeded its maximum of 4 (in this case).
- We could set these objects to be destroyed as soon as they go off screen or as soon as they travel too far (using the Destroy(gameObject) method).
- We could also just set these objects to be destroyed after a length of time. The easiest way of doing this would most likely be by adding a delay on the Destroy method. The finished code would then look something like this:
With something like this, we’re now able to keep our hierarchy tidy via parenting as well as prevent the game from getting overwhelmed by instantiated GameObjects.
When planning and implementing this sort of logic, I think an important question to ask your self is what are the most appropriate conditions for this object to no longer exist? In a lot of cases, the answer for this is simply ‘whenever the player can no longer see it’, but we may wish to use some other metric (e.g. when there are more than five, when it’s completed doing its task, etc.). These sorts of considerations can lead us quite nicely into thinking about scope, garbage collection, allocating memory selectively, and generally optimising our code to allow for tidier and more efficient applications (although I do appreciate C# and Unity handles a lot more of this than some other languages and engines). Like a lot of things in C# and Unity, this is something I hope to cover a little more thoroughly at a later date.
