We’ve all been there, you’re in the middle of playtesting a project coming up with million dollar features. All you need to do is just debug and you’re all set to count your fortune except your Hierarchy is overflowing with gameobjects! Now you can combat the overflowing menace of instantiating objects with a little know-how and a little bit of code.

Using a previous project (you can check out here) we’re gonna take a mass of instantiating enemies and make the mess a little more manageable. First let’s see what we’re tackling first.

Well that’s horrible but we can fix that no problem. Let’s start by going into our Spawn Manager and see exactly where we spawn these enemies.

So right here is where the Spawn Manager starts spitting these guys out. There’s two ways to tackle this and this is a matter of preference, first is to simply make the enemies children of the Spawn Manager so let’s try that first.

One line of code, you simply take the newly created tempEnemy and set the transform’s parent to that of the Spawn Manager. This is the end result.

This is great in a pinch but not very helpful for organizational purposes since everything will be under the Spawn Manager. Now let’s try the second method which is to create a brand new GameObject container to hold your freshly minted enemies. That’s a little more complex but not much, I promise.

First let’s create a private GameObject we’ll call “enemyContainer”. This will act as a container for our enemies.

Next we’ll assign a new GameObject named (yes, you guessed it) “Enemy Container” using the built in string property of GameObject constructor. Be sure to put this before anything that instantiates the objects or you will get a null reference exception error.

Now we’ll go back down to our instantiation code and do like we did before for enemyTemp and assign the transform’s parent to our freshly created Enemy Container object.

Now let’s see it run in action this time.

That’s so much better. You can also assign a Game Object that you created in the hierarchy to act as the container. You could have a system of buckets to hold certain objects based on their type and assign them via the inspector. Generally I try to avoid that as it’s too easy to forget to assign a container and would rather just generate them on the fly. Here’s the full code with both methods for posterity.

There you have it, easy clutter removal in a few short steps. This kind of project clean up seems a little overboard for a project of this size and it is. However when you’re running much larger projects with multiple team members (or teams) organization like this becomes critical. Your sanity will thank you in the long run. Until next time, happy coding.