Change It Once, Fix It Everywhere: The Unity Prefab (And Variant) Trick Every Beginner Needs.

Welcome everyone! This time we're going to talk about the Unity feature that saves you from the worst kind of busywork: prefabs in Unity. Understanding how they work can save you a lot of time! There are some rules to prefabs though (what they can and can't do). For instance, prefabs can't reference scene objects. And there's more. That's what we're going to elaborate on.

Let's dive in!

What Exactly Are Prefabs In Unity?

A prefab is a reusable template for a GameObject. You build something once, say a complete enemy with its sprite, collider, and scripts, then save it as an asset in your Project window. Every copy you place in a scene is an instance of that template, and every instance stays linked back to it.

That link is the whole point. Think of a prefab as a cookie cutter that also reshapes every cookie you've already baked. Edit the prefab, and all of its instances update with it.

prefab asset (the template)  →  instances in your scenes (linked copies)  →  edit the asset, every instance follows

Creating Your First Prefab

It takes about ten seconds:

• Build your GameObject in the Hierarchy, with every component it needs
• Drag it from the Hierarchy down into the Project window, and a prefab asset appears
• The object in your Hierarchy now shows a blue cube icon, which means it's an instance of that prefab
• Drag the prefab asset into the scene as many times as you like
• To edit the template itself, double-click the prefab asset, or click the small arrow next to an instance in the Hierarchy. That opens Prefab Mode, a focused view of just that prefab

Overrides: One Instance, Slightly Different

Sometimes a single instance needs to be different. Maybe one goblin in your boss room gets 200 health. Change the value on that instance, and Unity marks it as an override: the property turns bold, with a blue bar beside it in the Inspector. That instance keeps its custom value, while every other instance keeps following the prefab.

The Overrides dropdown at the top of the Inspector lets you Apply the change to the prefab asset (so every instance gets it) or Revert it back to match the prefab. You can also right-click a single property for the same choices.

How To Instantiate A Prefab In Unity From Code

Placing prefabs by hand is fine for a level layout. Spawning enemies, bullets, and pickups while the game runs needs code. That's what Instantiate does, it creates a brand new instance of a prefab at runtime. Here's how to instantiate a prefab in Unity:

public class Spawner : MonoBehaviour
{
    [SerializeField] private GameObject enemyPrefab;
    [SerializeField] private Transform spawnPoint;

    void Start()
    {
        Instantiate(enemyPrefab, spawnPoint.position, spawnPoint.rotation);
    }
}
  

Drag your prefab from the Project window into the enemyPrefab slot, and an enemy appears at the spawn point when the game starts. Make sure you drag the prefab asset, not a copy sitting in your scene. A scene copy technically works, but you'd be cloning whatever state it happens to be in right now.

Remember the tip from the Inspector article about typing a field as the component you need? It works for prefabs too, and Instantiate hands back that same type, so you can use the result right away:

[SerializeField] private Enemy enemyPrefab;
[SerializeField] private Transform player;

private void SpawnEnemy()
{
    Enemy enemy = Instantiate(enemyPrefab, transform.position, Quaternion.identity);
    enemy.SetTarget(player);
}
  

That SetTarget line matters. A prefab asset can't hold a reference to an object that lives in a scene, so a freshly spawned enemy has no idea where the player is. You hand it any scene references right after spawning.

Need a whole wave? A loop and an array do the job, and the optional last argument tucks every spawned enemy under one parent so your Hierarchy doesn't become a mile-long list:

[SerializeField] private GameObject enemyPrefab;
[SerializeField] private Transform[] spawnPoints;
[SerializeField] private Transform enemyParent;

private void SpawnWave()
{
    for (int i = 0; i < spawnPoints.Length; i++)
    {
        Instantiate(enemyPrefab, spawnPoints[i].position, Quaternion.identity, enemyParent);
    }
}
  

And when it's time to clean up, you use Destroy:

Destroy(enemy.gameObject);   // removes the whole GameObject
Destroy(gameObject, 2f);     // removes this GameObject after 2 seconds
  

Careful with that first line. Destroy(enemy) on its own would only remove the Enemy component, leaving the GameObject standing there like a ghost. And if you're spawning and destroying hundreds of objects per second, that gets expensive. The fix is called object pooling, which deserves its own post.

Prefab Variants In Unity: Same Base, Different Flavors

What if you need an armored enemy that's identical to the normal one, except for more health and a shield sprite? Copying the prefab brings back the original problem: fix a bug in one, and you have to fix it in both. Prefab variants in Unity solve exactly this. A variant inherits everything from a base prefab and stores only its own differences.

To make one, right-click a prefab in the Project window and choose Create, then Prefab Variant. Change whatever you like on the variant. Anything you don't touch keeps following the base. Fix a bug in the base Enemy, and ArmoredEnemy gets the fix automatically, with its extra health still intact.

You can also nest prefabs, putting one prefab inside another. Picture a Room prefab that contains several Door prefabs. Edit the Door once, and every room updates.

Common Prefab Gotchas

A few things trip up almost everyone:

• Prefab assets can't reference scene objects. Pass those references in from code right after spawning, like the SetTarget example above.
• Code changes to a spawned instance never touch the prefab asset. If you change an enemy's health in a script at runtime, the prefab still says 100. Edit the prefab itself to change the template.
• Unpacking breaks the link. Right-click an instance, choose Prefab, then Unpack, and it becomes a plain GameObject. Handy occasionally, but you lose the update-everywhere benefit.

So Which Approach Should You Actually Use?

Here's the no-fluff version, the gut check you can run through in your head:

• Building the same thing more than once → make it a prefab
• One instance in one scene needs a tweak → an override
• A reusable different flavor you'll spawn many times → one of those prefab variants in Unity
• Spawning while the game runs → Instantiate, with the prefab field typed as the component you need
• Spawned object needs scene references → pass them in right after you instantiate a prefab in Unity
• Spawning hundreds per second → object pooling, not a bigger Instantiate loop
• Want a plain copy with no link → Unpack it

The question that settles most of this is "will I need more than one of these?" If the answer is yes, make a prefab before you make the second copy.

Wrapping Up

Prefabs in Unity turn "edit twenty things by hand" into "edit one thing once." Build the template, place or spawn as many instances as you need, use overrides for the odd one out, and reach for variants when you want a different flavor. It's one of the biggest time savers in the whole engine, and the earlier you start using it, the less cleanup you'll have later. 

 ~happy Coding!