📦 Lesson 2.3: ScriptableObjects: Data as Assets

What Is a ScriptableObject?

You know MonoBehaviour: it must sit on a GameObject, in a scene, and gets Update, colliders, transforms. A ScriptableObject is its data-only sibling. It's a class Unity can serialize into a .asset file that lives in your Project, not in any scene and not on any GameObject. It has no Update, no transform — it just holds fields.

Think of the difference this way. Twenty goblins in your scene are twenty GameObjects, each with an Enemy component (behavior). But they all share the same stats — 30 health, 3 damage, 3.5 move speed. Copying those numbers onto twenty components is wasteful and fragile; change the balance and you edit twenty objects. Put the numbers in one EnemyStats asset and all twenty just point at it.

💡 Not a replacement for MonoBehaviour. ScriptableObjects don't do things each frame — they describe things. You'll almost always have both: a MonoBehaviour that acts, holding a reference to a ScriptableObject that supplies the numbers.

Creating WeaponData

A ScriptableObject definition is just a class that derives from ScriptableObject instead of MonoBehaviour. The magic ingredient is the [CreateAssetMenu] attribute, which adds an entry to Unity's Assets ▸ Create menu so you can spawn assets from it:

using UnityEngine;

[CreateAssetMenu(fileName = "NewWeapon", menuName = "Game/Weapon Data")]
public class WeaponData : ScriptableObject
{
    public string weaponName = "Pistol";
    public int damage = 10;
    public float fireRate = 2f;      // shots per second
    public int magazineSize = 12;
    public GameObject projectilePrefab;
    public AudioClip fireSound;
    public Sprite icon;
}

Notice the fields are plain public — ScriptableObjects serialize the same way components do, so [SerializeField] private fields work too. Because it's data, there's no Start or Update; it's a tidy bundle of values, and those values can include asset references like prefabs, clips, and sprites.

Data as Project Assets

Once the class compiles, right-click in the Project window ▸ Create ▸ Game ▸ Weapon Data. Unity drops a new .asset file that you name and select; its fields appear in the Inspector, ready to fill in. Make one asset per weapon — Pistol, Shotgun, Rifle — each a separate file with its own numbers.

Here's the Project window holding three weapon assets, with the selected Shotgun shown in the Inspector — exactly what you'll see on screen:

Referencing an SO from Code

A component uses the data by holding a WeaponData reference — exactly like any other serialized field. Drag the Shotgun asset into the slot and the weapon behaves like a shotgun; drag Rifle in and the same script behaves like a rifle. The behavior lives in code; the numbers live in the asset:

using UnityEngine;

public class Weapon : MonoBehaviour
{
    [SerializeField] WeaponData data;   // drag an asset here
    float nextFireTime;

    public void TryFire()
    {
        if (Time.time < nextFireTime) return;
        nextFireTime = Time.time + 1f / data.fireRate;

        var proj = Instantiate(data.projectilePrefab,
                               transform.position, transform.rotation);
        proj.GetComponent<Projectile>().damage = data.damage;

        AudioSource.PlayClipAtPoint(data.fireSound, transform.position);
    }
}

Swapping weapons at runtime is now trivial — assign a different data asset and everything (damage, rate, sound, projectile) follows. That's the decoupling win: the Weapon code doesn't hardcode a single number.

Shared vs. Instanced Data

This is the one concept that trips people up, so slow down here. When many components reference the same SO asset, they share one object in memory. Read from it freely. But if a component writes to it at runtime, every other referencer sees the change — because there's only one.

Figure 2: Five goblins, one shared EnemyStats asset. Editing the asset re-balances all five at once — but writing per-enemy runtime state (like current health) into it would corrupt them all.

So split your thinking into two kinds of data:

• Shared / definition data — the unchanging template: max health, base speed, damage. Keep this in the SO and only read it. Editing the asset intentionally re-balances every user, which is exactly what you want in the editor.
• Instanced / runtime state — the per-object values that change during play: current health, ammo left, cooldown timers. These belong in the MonoBehaviour, initialized from the SO:

public class Enemy : MonoBehaviour, IDamageable
{
    [SerializeField] EnemyStats stats;   // shared definition (read-only)
    int currentHealth;                   // instanced runtime state

    void Awake() => currentHealth = stats.maxHealth;  // copy, don't mutate

    public int CurrentHealth => currentHealth;
    public void TakeDamage(int amount) => currentHealth -= amount;
}

The goblin reads stats.maxHealth once to seed its own currentHealth, then only ever changes its private field. The shared asset stays pristine.

Why This Matters

ScriptableObjects pay off in three big ways:

• Designer-editable. Balancing lives in .asset files a non-programmer can tune in the Inspector — no code edits, no recompiling. Change the shotgun's damage over lunch without opening Visual Studio.
• No scene bloat. Data lives once in the Project, not copied onto every GameObject or baked into each scene. Twenty goblins reference one stats asset instead of carrying twenty copies of the same numbers, which also keeps scene files small and merge-friendly.
• Decoupling. Just like interfaces and events, SOs cut a dependency: code depends on a data contract (the SO type) rather than hardcoded values. A brand-new weapon is a new asset, not a new class — often no code at all.

💡 The whole module clicks together here. Interfaces decouple who calls whom. Events decouple who reacts to what. ScriptableObjects decouple code from data. In the next lesson we combine events and SOs into one pattern — the ScriptableObject event channel — that decouples across entire scenes.

Hands-on Challenge

Summary

🚀 What's Next?

You now have all three decoupling tools: interfaces, events, and ScriptableObjects. In Lesson 2.4: ScriptableObject Event Channels we fuse events and SOs into a single elegant pattern — a GameEvent asset that any system can raise and any GameEventListener can react to, letting entirely separate scenes talk without a single direct reference.