Prefabs

Summary

A prefab is a reusable, saved template of a game object — complete with every component and configured value — that can be instantiated repeatedly to create many identical (or slightly customized) copies. Instead of manually rebuilding an enemy's components and settings every time one is needed, a prefab is built once and then stamped out as many times as required, with edits to the original template able to propagate to every copy.

Why This Matters

Manually assembling a game object's components and settings every single time one is needed doesn't scale — placing fifty identical enemies by hand, each requiring the same Health, MeleeAttack, and EnemyAnimator components configured the same way, is both slow and error-prone, since a mistake in configuring one copy is easy to miss. Worse, fixing a bug (a wrong default health value) then means finding and re-fixing all fifty individually. Prefabs solve both problems: build the template once, spawn it as many times as needed, and — depending on the engine's specific propagation rules — fix it once for every instance sharing that template.

Mental Model

A prefab is a cookie cutter, not a single cookie. Cutting a hundred identical cookies from one dough sheet is fast and consistent because each cut reproduces the same shape from the same cutter — and if the cutter's shape needs to change, replacing it changes every cookie cut afterward without needing to reshape ones already made by hand. A prefab is that cutter: define the shape (components, settings) once, and every instantiation reproduces it reliably.

Core Explanation

• A prefab is an authored template, saved as an asset. It captures a game object's full component list and configured values as reusable data, independent of any specific instance currently in a scene.
• Instantiating a prefab creates an independent copy in the world. Instantiate(enemyPrefab) produces a new game object with the same starting components and values as the template — subsequent changes to that specific instance (its position, its current health) don't affect the template or other instances.
• Editing the template can propagate to existing instances. Depending on the engine and whether an instance has "overridden" a specific value, changing the prefab template (adding a component, changing a default) can automatically update every instance still following it — a powerful but easy-to-misunderstand behavior worth learning explicitly per engine.
• Prefabs commonly nest and reference other prefabs. A Player prefab might contain a Weapon prefab instance as a child — changes to the Weapon prefab template propagate into every Player prefab (and scene) using it.

Syntax / Theory

C# (Unity)

[SerializeField] private GameObject enemyPrefab; // Reference to the saved template asset.

void SpawnEnemy(Vector3 position)
{
    GameObject instance = Instantiate(enemyPrefab, position, Quaternion.identity);
}

Editing enemyPrefab's asset (in Prefab Mode) and saving updates every placed instance in every scene that hasn't explicitly overridden that specific property — this propagation is one of Unity Prefabs' defining behaviors.

C++ (Unreal — Blueprint Classes)

UClass* EnemyClass = LoadClass<AEnemy>(nullptr, TEXT("/Game/Blueprints/BP_Skeleton"));
AEnemy* Instance = GetWorld()->SpawnActor<AEnemy>(EnemyClass, SpawnLocation, SpawnRotation);

Unreal's closest equivalent is a Blueprint Class — an Actor subclass authored (often visually) with a specific component configuration, saved as an asset, and spawned repeatedly the same way a Unity prefab is instantiated.

Unreal Blueprint

Dragging a Blueprint Class asset into the level, or spawning it at runtime with Spawn Actor from Class, mirrors dragging a Unity prefab into a scene or calling Instantiate — both are "stamp out a configured template" operations.

Practical Example

A projectile system spawns many short-lived instances of the same pre-configured object.

public class WeaponFire : MonoBehaviour
{
    [SerializeField] private GameObject bulletPrefab;

    public void Fire(Vector3 origin, Vector3 direction)
    {
        GameObject bullet = Instantiate(bulletPrefab, origin, Quaternion.LookRotation(direction));
        bullet.GetComponent<Rigidbody>().velocity = direction * bulletSpeed;
    }
}

Every fired bullet starts from the exact same configured template — mesh, collider, damage value — with only its per-instance position and velocity differing; nothing about the bullet's shared configuration is re-specified at each Fire() call.

Common Mistakes

• Editing a scene instance's value and being surprised the change didn't propagate to the prefab template — or vice versa. Once an instance's property is explicitly overridden, it stops following further changes to the template for that specific property, which trips up developers unfamiliar with a given engine's override rules.
• Building a "prefab" by manually copy-pasting a configured game object in the editor instead of using a proper prefab asset. Copies made this way have no ongoing link to a shared template — fixing a bug means re-fixing every pasted copy individually, defeating the entire purpose.
• Instantiating a prefab that references scene-specific objects directly. A prefab is meant to be self-contained and reusable across scenes — a direct reference baked into it pointing at one particular scene's specific object breaks the moment the prefab is used somewhere else.
• Not pooling frequently-instantiated prefabs (bullets, particles). Repeatedly calling Instantiate/Destroy for short-lived, high-frequency objects is more expensive than reusing instances from an object pool (see [[CON-0022]]'s ObjectPool<T> example).

Game Development Example

A loot system spawns different item prefabs based on what an enemy drops, reusing the same spawning logic regardless of which specific item it is.

public class LootTable : MonoBehaviour
{
    public GameObject[] possibleDrops; // Each entry is a prefab reference.

    public void DropLoot(Vector3 position)
    {
        GameObject chosenPrefab = possibleDrops[Random.Range(0, possibleDrops.Length)];
        Instantiate(chosenPrefab, position, Quaternion.identity);
    }
}

Adding a new droppable item to the game means creating a new prefab and adding it to possibleDrops — DropLoot itself never needs to change to support it.

Best Practices

• Build reusable game objects as prefabs from the start rather than manually duplicating configured objects in a scene.
• Understand your engine's specific override/propagation rules before relying on "editing the template updates every instance" behavior.
• Keep prefabs self-contained — avoid baking in references to scene-specific objects that won't exist wherever the prefab is reused.
• Pool prefab instances that are created and destroyed frequently, rather than instantiating and destroying them individually every time.

Exercises

1. Create an Enemy prefab with Health and MeleeAttack components configured, instantiate three copies in a scene, and confirm that changing one instance's position doesn't affect the others.
2. Take the bulletPrefab example and convert it to use an object pool instead of Instantiate/Destroy per shot — describe why this matters for a weapon that fires rapidly.
3. You're building an item system with 200 different item types, each needing a slightly different icon, description, and effect, but sharing the same pickup/inventory-slot behavior. Decide between one generic Item prefab configured 200 different ways via data versus 200 separate prefabs, and justify the trade-off.
4. Research "nested prefabs" (prefabs containing other prefab instances as children) and explain one advantage this gives a Player prefab that contains a Weapon prefab, versus building the weapon directly inside the player prefab with no separate template.

Related Concepts

• Game Objects — a prefab is fundamentally a saved template of a game object's structure; understanding what a game object is comes first.
• Components — a prefab's value comes from capturing a specific, reusable combination of configured components, not from the prefab mechanism itself.
• Scenes — prefabs are commonly instantiated into a scene at runtime, complementing a scene's pre-placed, hand-authored content.

Further Reading

• KNOWLEDGE_SCHEMA.md — GDKB's concept maturity ladder and cross-linking rules, which this document follows.
• Unity documentation — Prefabs: https://docs.unity3d.com/Manual/Prefabs.html
• Unreal Engine documentation — Blueprint Classes: https://dev.epicgames.com/documentation/en-us/unreal-engine/blueprints-visual-scripting-in-unreal-engine