The Unity Prefab Waterfall

That’s why we care about this technique, because otherwise without it we duplicate things in Unity – a lot. Then…

We lose track of our project.

Bugs appear everywhere.

Builds swell to device-breaking sizes.

We go a little crazy.

… and then die!

OK, I may be exaggerating just a little here, but in my experience creating some of the world’s biggest and best online courses on Unity I get to see what my 100s of thousands of students do right – and wrong.

The Premise

NOT premises, like a building. And when a cloud provider offers you an “on-premise” solution then they’re dumb, they mean “on premises”. Man, who can use a dictionary these days! Anyway, I digress.

When you sit at a computer typing, or using your mouse, think about how much value it’s even possible to create. If you type continually at am ambitious 80 words per minute, then you’re only creating about half a kilobyte per minute! You may create real value a little faster with the mouse, but I doubt it! So if you’re not recording video or audio, your project file shouldn’t be growing faster than about 30 kilobytes an hour!

Image Source

Of course in reality the project will grow much faster because your pesky game engine will be creating all sorts of derived files like lighting cache, navmeshes, and so-on. However, the value you actually create (rather than import) will be very limited.

Why This Matters

This matters because, once you realise this is how slowly you’re actually creating new value, then you start to think carefully about duplication. Copy and paste is the root of all evil, and if you’re not careful that’s exactly what you’ll be doing all the time – particularly in Unity.

When you add an object to a scene, information about it (size, position, etc) will be stored in the .unity scene file – at least it will once you save. This is fine until you come to re-use that object. You want to make sure that each piece of information has just one place to live, and lives in that place (as Mr Franklin said).

The Waterfall

The basic premise (did I mention this isn’t a building?) is that information should flow from the scene, to the prefab, to the scriptable object…

Let’s take an example. You have a street scene composing of many different street lamps. First you make a lamp, and store it in the scene. Then you decide you’re going to re-use it, so you “prefab” it (short for pre-fabricate). Then you decide to specialise some of the lamps, changing perhaps a number written on them, or the light colour. This data shouldn’t be stored in duplicate prefabs, but rather in scriptable objects (SOs).

This waterfall ensures that each level contains only the value it’s adding, for example…

The Scene: Contains the positions, rotations and maybe scales of the objects.

The Prefab: Contains all the components, links to materials, and other general information.

The SO: Contains the specialisations like differences in colour, number, light, etc.

Recap & Take-Aways

The purpose of this brief post is to get you thinking. Remember that duplicating data always ruins your life, and that clarity is worth fighting for. Hopefully this simple technique will at least make you stop and think about whether there’s away to not repeat yourself.