Yes, I know, inception is putting an idea in the head of someone and not precisely recursion, but nowadays is a recursion synonym. And the other option was naming this post “Yo dawg, I heard you like prefabs”.

(All THE IMAGES ARE SCALED DOWN. CLICK THEM TO OPEN THEM IN A NEW WINDOW)

Well, this week we are going to talk about a problem that, although we finally managed to solve,  had us trying lots of different solutions and has given us many head aches, a problem named Nested Prefabs.

Unity’s prefabs are instantiable objects. The problem is that these objects can’t be placed inside other objects, without losing the reference to the original object. It would be like a Flash MovieClip, but the main difference is that the MovieClip allows children to maintain their original reference.

Why did this bother us so much? Well, each stage in Okhlos, is composed by four chunks. Each chunk is, in turn, composed of different buildings. And each building is composed of different props and structures.

CHUNKS

This is a chunk. The main component of the chunks are buildings, but they can also have other elements like hazards, enemies, props, etc., and some of these can be completely randomized.

BUILDINGS

The buildings are composed of a main structure and different props, also some other decorations which may be sprites or the like.

PROPS

Props are the weakest destructible elements. They usually have a small structure and some sprites.

 

The following image will perhaps better illustrate how these things, chunks, buildings and props, fit together.

As you can image by now, when we add this hierarchy to the prefab’s problem you end up with three o four levels of lost references for each chunk or building. At first we simply tried to deal with this without resorting to any kind of nesting of prefabs, but it came at a high price. Basically, we had to redo every chunk and building a couple of times.

What we do now, is use a script we named Building Holder. That script holds a reference to a prefab, and instantiates it on runtime.

This reference points to an object of GameObject type, thus it can be either a GameObject in the scene or a prefab. What we found out when we started using this was that if the reference pointed to itself, when we hit apply, it stored a reference to the Game Object in the scene, not to the actual prefab.

You can see it (kinda) more clearly here:

The green line shows how the reference points to the Project view (to the actual prefab). The red line shows the object in the Hierarchy view (which is the scene view, what we don’t want to happen). And the blue lines show the objects’ structure (chunk, building, prop).

To set the reference point to actual prefab and not  the instance is fundamental to be able to modify a building without having to modify its instance in each chunk (or to put it in other words, to be able to modify a building once instead of gazillion times) but luckily we now how to do it.

 

Finally, a few screenshots showing some chunks together:

 

And closing up this week, a tree destruction .gif!