Reducing Prefab Bloat with Unity ScriptableObjects

The Problem: Duplicate Data in Prefabs

When building a game with dozens of enemy types or item variants, the instinct is to create a unique Prefab for each. If every 'Goblin' Prefab carries its own copy of health, movement speed, and attack power, you aren't just wasting memory—you're creating a maintenance nightmare. Changing the movement speed of a Goblin requires updating every single variant Prefab manually.

The solution is to separate configuration data from instance logic. By moving shared variables into a ScriptableObject, you create a single source of truth that exists as a project asset rather than a component on a GameObject.

Decoupling Data from Logic

A ScriptableObject is a data container that inherits from UnityEngine.ScriptableObject instead of MonoBehaviour. Because it doesn't need to be attached to a GameObject in a scene, it exists independently in your project folder.

This architecture enables a data-driven workflow. Instead of a script asking "What is my speed?" from its own internal variable, it asks "What is the speed defined in my assigned configuration asset?" This allows designers to tweak game balance in the Inspector during runtime without stopping the game, and those changes apply instantly to every object referencing that asset.

Implementation: The Configuration Asset Pattern

To implement this, you define a data class and then create assets from that class using the [CreateAssetMenu] attribute. This makes the data accessible via the right-click menu in the Project window.

Example: Enemy Stats Configuration

// 1. Define the data container
[CreateAssetMenu(fileName = "NewEnemyStats", menuName = "Game/Enemy Stats")]
public class EnemyStats : ScriptableObject
{
    public float maxHealth = 100f;
    public float moveSpeed = 5f;
    public int attackDamage = 10;
}

// 2. Use the data in a MonoBehaviour
public class EnemyController : MonoBehaviour
{
    [SerializeField] private EnemyStats stats;
    private float currentHealth;

    void Start()
    {
        // Reference the shared asset rather than storing local copies
        currentHealth = stats.maxHealth;
    }

    void Update()
    {
        transform.Translate(Vector3.forward * stats.moveSpeed * Time.deltaTime);
    }
}

How to verify:

1. Create the EnemyStats script.
2. Right-click in the Project window > Create > Game > Enemy Stats to create an asset (e.g., "GoblinStats").
3. Assign "GoblinStats" to multiple Enemy GameObjects.
4. Enter Play Mode and change the moveSpeed in the "GoblinStats" asset. All enemies will speed up or slow down simultaneously.

Critical Trade-offs and Limitations

While powerful, ScriptableObjects have specific behaviors that can cause bugs if misunderstood:

• Editor Persistence: Changes made to a ScriptableObject during Play Mode persist after you stop the editor. This is excellent for tuning balance but dangerous if you use them to track runtime state (like current health).
• Build Read-Only Status: In a compiled build (.exe, .apk), ScriptableObjects are read-only. You cannot save player progress or game state by writing to them. For saving, you must still use JSON, XML, or binary serialization to a local file.
• Hidden Dependencies: If too many systems rely on a single global ScriptableObject, it can become a "hidden singleton," making it harder to isolate components for unit testing.

Practical Decision Matrix

Use Case	MonoBehaviour Variable	ScriptableObject Asset
Current Health / Mana	Yes (Unique per instance)	No (Shared across all)
Base Attack Power	No (Redundant)	Yes (Single source)
Player Save Data	No (Reset on scene load)	No (Read-only in build)
Weapon Configs	No (Bloats Prefabs)	Yes (Swap assets easily)

Closing Action

Audit your current Prefabs. If you find the same constants (e.g., float speed = 5.0f) repeated across multiple scripts or Prefabs, migrate them to a ScriptableObject. This will reduce your memory footprint and allow your design team to balance the game without touching a single line of code.