ScriptableObjects

A ScriptableObject is a data container that lives as an asset in your project rather than as a component in a scene. It is the answer to "where do I put the numbers that lots of objects need?"

The problem it solves

Say fifty enemy prefabs each need the same damage value. With MonoBehaviours, that number is copied fifty times and balancing means editing fifty prefabs. With a ScriptableObject, they all point at one asset. Change it once.

There is a memory argument too. A MonoBehaviour field is duplicated per instance; a hundred enemies means a hundred copies of every value. A ScriptableObject exists once no matter how many objects reference it.

Creating one

using UnityEngine;

[CreateAssetMenu(fileName = "EnemyData", menuName = "Game/Enemy Data")]
public class EnemyData : ScriptableObject
{
    [Header("Stats")]
    public string enemyName = "Grunt";
    public int maxHealth = 100;
    public float moveSpeed = 3.5f;
    public int damage = 10;

    [Header("Visuals")]
    public GameObject prefab;
    public Sprite icon;
}

[CreateAssetMenu] adds it to the right-click Create menu in the Project window. Make as many assets from it as you like — Grunt, Archer, Boss — each with its own values.

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

    private int currentHealth;

    private void Awake()
    {
        // Read shared config, keep per-instance state locally
        currentHealth = data.maxHealth;
    }
}

The gotcha everyone hits

ScriptableObjects are assets, not instances. Write to one at runtime and the change persists in the editor after you stop playing. It does not reset.

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

    public void TakeDamage(int amount)
    {
        // Editing the shared asset. Every enemy using this data
        // loses health together, and the value stays changed
        // after you exit play mode.
        data.maxHealth -= amount;
    }
}

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

    private int currentHealth;   // per-instance state

    private void Awake()
    {
        currentHealth = data.maxHealth;   // read once
    }

    public void TakeDamage(int amount)
    {
        currentHealth -= amount;          // never touches the asset
    }
}

Where they beat the alternatives

As an alternative to singletons

A common use is decoupling systems that should not know about each other. Instead of the UI holding a reference to the player, both reference a shared asset.

using UnityEngine;

[CreateAssetMenu(menuName = "Game/Float Variable")]
public class FloatVariable : ScriptableObject
{
    [SerializeField] private float startValue;

    [System.NonSerialized] public float runtimeValue;

    // Reset from the serialised default when play begins
    private void OnEnable() => runtimeValue = startValue;
}

The player writes playerHealth.runtimeValue; the health bar reads it. Neither script references the other, so either can be deleted without breaking the other.

Events without references

[CreateAssetMenu(menuName = "Game/Game Event")]
public class GameEvent : ScriptableObject
{
    private readonly List<System.Action> listeners = new();

    public void Raise()
    {
        // Backwards: a listener may unsubscribe during the call
        for (int i = listeners.Count - 1; i >= 0; i--)
            listeners[i]?.Invoke();
    }

    public void Register(System.Action listener) => listeners.Add(listener);
    public void Unregister(System.Action listener) => listeners.Remove(listener);
}

What to take away

• ScriptableObjects are assets, so the data exists once regardless of instance count.
• Use [CreateAssetMenu] so designers can make variants without code.
• Read config from the asset, keep changing state in the MonoBehaviour.
• Runtime writes persist in the editor — guard with [System.NonSerialized] and OnEnable.
• They decouple systems that would otherwise need direct references.