Unity ScriptableObjects: shared definitions and individual runtime state

Start with ownership

A weapon definition and a weapon currently held by a character are different kinds of data. Confusing them can make one character’s ammunition changes affect every character using that asset. Before choosing a Unity container, decide whether a value belongs to a reusable definition, one spawned instance or a saved player profile. Give each category an identifiable owner.

What an asset shares

A ScriptableObject can hold data independently of scene components. Several objects can reference the same asset and therefore share its values instead of storing separate copies. That is useful for authored configuration, but it does not make the referenced object immutable. The Unity 6.0 manual describes this shared-data role. [1]

Build a deliberate boundary

Keep designer-authored values behind a read-oriented interface and initialise per-instance state separately. An ordinary runtime class is often enough for ammunition, cooldown timers and accumulated damage. If a runtime object specifically needs ScriptableObject identity, CreateInstance creates a new instance; Object.Instantiate clones an existing object. [2][3] Decide which route matches your initialisation rules rather than treating both as interchangeable asset loading.

Example: two flare launchers

Imagine a flare definition containing a capacity of 4, a reload duration of 2 seconds and a projectile reference. Two spawned launchers both read that definition. Each launcher starts with its own ammunition value of 4 and its own reload timer. Firing launcher A changes A’s ammunition to 3; launcher B remains at 4. A balance edit to the shared reload duration can intentionally affect both launchers when they next read configuration. This example distinguishes live configuration reads from values copied at spawn: choose one policy per field and document it. Save the launcher’s definition identifier and changing state, then reconstruct it through an explicit loading path.

Limits and checks

A clone is not a promise that every referenced asset has become independently owned. Review nested references before allowing writes to their contents. Establish who destroys temporary Unity objects and who resets state between play sessions. Treat saving as a separate application feature; editing an object in memory is not a durable save format. A useful test creates two instances, mutates only one, and checks both their state and the original definition. Repeat after a scene reload and a fresh application start to reveal accidental dependence on Editor state.

Sources

1. ScriptableObject data assets — Unity Technologies.
2. ScriptableObject.CreateInstance — Unity Technologies.
3. Object.Instantiate — Unity Technologies.