📝 Lesson 3.1: ScriptableObjects for Data

The Problem: Duplicated Data

Imagine 50 Goblins in your game, each a prefab instance with a MonoBehaviour holding maxHealth = 30, speed = 4, damage = 5. Now the designer wants goblins tougher: health 40. You either edit the prefab (fine) — but what if those values are tuned per-scene, or spread across several enemy scripts? The data gets duplicated and drifts out of sync.

The deeper issue: data is riding on behavior. The numbers that define "what a goblin is" are trapped inside a component that also has to live on a GameObject, run a lifecycle, and exist in a scene. What we want is to store the data once, separately, and let every goblin point at it.

💡 The goal: one source of truth for each kind of data, editable by designers, referenced by many objects. Change it in one place, and everything using it updates. That's exactly what a ScriptableObject gives you.

What Is a ScriptableObject?

A ScriptableObject is a class that inherits ScriptableObject instead of MonoBehaviour. Like a MonoBehaviour it has serialized fields you edit in the Inspector — but unlike a MonoBehaviour, an instance is saved as a project asset, not attached to a GameObject.

Both derive from Unity's Object, but they answer different questions:

All three goblins point at the same GoblinData asset. Edit that one asset and every goblin sees the change — the single source of truth we wanted. There's also a memory win: 50 goblins share one copy of the data instead of each carrying its own.

Authoring a Data Asset

Two steps: write a class that inherits ScriptableObject, and tag it with [CreateAssetMenu] so you can create instances from Unity's Assets → Create menu.

using UnityEngine;

[CreateAssetMenu(fileName = "NewEnemyData", menuName = "Game/Enemy Data")]
public class EnemyData : ScriptableObject
{
    [Header("Stats")]
    public int maxHealth = 30;
    public float moveSpeed = 4f;
    public int damage = 5;

    [Header("Presentation")]
    public string displayName = "Goblin";
    public Sprite icon;

    // ScriptableObjects can have methods too — data + behavior on the data itself.
    public int DamageAfterArmor(int armor) => Mathf.Max(0, damage - armor);
}

Referencing Data from a MonoBehaviour

An EnemyData asset is just data — something has to act on it. That's a MonoBehaviour with a reference to the asset, wired in the Inspector (Lesson 1.3). The behavior lives in the component; the numbers live in the asset.

using UnityEngine;

public class Enemy : MonoBehaviour
{
    [SerializeField] private EnemyData data;   // drag a GoblinData asset here
    private int currentHealth;

    void Start()
    {
        // Read starting values FROM the shared data asset into per-instance state.
        currentHealth = data.maxHealth;
        gameObject.name = data.displayName;
    }

    public void TakeDamage(int amount)
    {
        currentHealth -= amount;
        if (currentHealth <= 0)
            Destroy(gameObject);
    }

    void Update()
    {
        // Behavior uses the shared data, but state (currentHealth) stays local.
        transform.Translate(Vector3.forward * data.moveSpeed * Time.deltaTime);
    }
}

Now swapping an enemy from Goblin to Orc is a single drag in the Inspector — no code change. Designers can create and balance dozens of enemy types without touching the Enemy script at all. That's data-driven design: behavior is fixed in code, variety comes from data.

The Shared-Instance Gotcha

Here's the trap that catches everyone once. Because all enemies share the same asset, writing to that asset's fields at runtime changes it for everybody — and, in the Editor, the change can persist after you stop playing.

// ❌ DON'T do this — it mutates the shared asset, affecting all enemies
// and permanently editing your data asset in the Editor.
public void TakeDamage(int amount)
{
    data.maxHealth -= amount;   // WRONG: writing to the shared ScriptableObject
}

💡 Why it persists: In a build, ScriptableObject edits are discarded when the game closes. But in the Editor, the asset is a real file — runtime writes to it are saved like any Inspector edit, silently corrupting your tuned values. This surprises people because it doesn't happen with MonoBehaviour fields, which reset each Play session.

When to Use Which

ScriptableObjects are powerful but not the answer to everything. Three homes for your data, each with a job:

Exercise & Quiz

using UnityEngine;

public class Enemy : MonoBehaviour
{
    [SerializeField] private EnemyData data;
    private int currentHealth;

    void Start()
    {
        // TODO: copy data.maxHealth into currentHealth; set the object's name.
    }

    public void TakeDamage(int amount)
    {
        // TODO: reduce currentHealth (NOT data!), destroy at 0.
    }
}

using UnityEngine;

[CreateAssetMenu(fileName = "NewEnemyData", menuName = "Game/Enemy Data")]
public class EnemyData : ScriptableObject
{
    public int maxHealth = 30;
    public float moveSpeed = 4f;
    public int damage = 5;
    public string displayName = "Goblin";
}

using UnityEngine;

public class Enemy : MonoBehaviour
{
    [SerializeField] private EnemyData data;
    private int currentHealth;

    void Start()
    {
        currentHealth = data.maxHealth;      // copy shared config into local state
        gameObject.name = data.displayName;
    }

    public void TakeDamage(int amount)
    {
        currentHealth -= amount;             // modify LOCAL state, not the asset
        if (currentHealth <= 0)
            Destroy(gameObject);
    }

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

Summary

📚 Additional Resources

• Scripting Reference — ScriptableObject
• Scripting Reference — CreateAssetMenu
• Manual — ScriptableObject

🚀 What's Next?

You can now separate data from behavior. Next we separate systems from each other. Lesson 3.2, Events and Decoupling, uses C# events, UnityEvents, and ScriptableObject event channels so components can talk without knowing about each other — the cleanup pattern from Lesson 1.2 finally pays off.