A common and confusing issue in Unity projects is when ScriptableObject data appears to reset during Play Mode. Developers often report that:

• Values revert after exiting Play Mode
• Runtime changes are lost
• Data behaves inconsistently between Editor and Build
• Multiple objects share unexpected values

This is often described as a ScriptableObject bug, but in most cases, it is expected behavior based on how Unity handles assets and runtime memory.

This article explains why ScriptableObject data resets during Play Mode and how to use reliable patterns to avoid data loss and confusion.

Understanding ScriptableObject Behavior

ScriptableObjects are asset files. They are not scene objects. When you modify them during Play Mode, you are modifying the in-memory version of that asset.

Important rules:

• Changes made in Play Mode are not permanently saved (unless explicitly written to disk).
• When exiting Play Mode, Unity reloads assets from disk.
• In builds, runtime changes are never saved automatically.

This is why data appears to “reset.”

Common Scenario 1: Modifying Asset Data at Runtime

Example ScriptableObject:

[CreateAssetMenu(menuName = "Game/PlayerData")]
public class PlayerData : ScriptableObject
{
    public int health = 100;
}

Using it in a MonoBehaviour:

public PlayerData playerData;

void Start()
{
    playerData.health -= 10;
}

During Play Mode, health becomes 90. After stopping Play Mode, it returns to 100. This is expected.

Common Scenario 2: Shared Instance Across Objects

If multiple objects reference the same ScriptableObject, they all modify the same data instance.

This can cause unexpected shared state:

• Enemy A reduces health
• Enemy B sees reduced health

This is not a reset bug. It is shared asset behavior.

Common Scenario 3: Domain Reload Disabled

If Enter Play Mode settings disable Domain Reload, static fields may persist while ScriptableObjects reload differently. This can create confusing behavior where some data resets and some does not.

Check:

• Edit → Project Settings → Editor → Enter Play Mode Settings

Common Scenario 4: Creating Instances at Runtime

If you modify the asset directly instead of instantiating it, you are changing the original asset reference.

Wrong pattern:

playerData.health -= 10;

Better pattern:

private PlayerData runtimeData;

void Awake()
{
    runtimeData = Instantiate(playerData);
}

Now modifications affect only the runtime copy.

Reliable Solutions

Solution 1: Always Instantiate for Runtime Use

To prevent shared data issues and confusion:

public PlayerData baseData;
private PlayerData runtimeData;

void Awake()
{
    runtimeData = Instantiate(baseData);
}

This keeps the asset clean while allowing safe runtime changes.

Solution 2: Separate Config Data from Runtime Data

Use ScriptableObjects only for:

• Configuration
• Base stats
• Static data

Store runtime state in regular classes:

public class PlayerState
{
    public int health;
}

Solution 3: Use Save Systems for Persistent Changes

If you need changes to persist, implement saving:

• JSON serialization
• PlayerPrefs (for simple data)
• Custom save files

ScriptableObjects do not automatically save runtime changes.

Solution 4: Reset Data on Play Start

If you intentionally modify ScriptableObjects in Play Mode, reset them manually:

[RuntimeInitializeOnLoadMethod]
static void ResetData()
{
    // Reset static or cached data here
}

Important Editor Warning

If you modify ScriptableObject values in Play Mode and see them saved permanently, it means you changed them in Edit Mode or used editor scripts. Be careful not to unintentionally overwrite asset data.

Best Practices for ScriptableObjects

• Treat ScriptableObjects as configuration assets, not save data.
• Instantiate them for runtime use.
• Do not store temporary state in asset files.
• Be careful with shared references.
• Understand the difference between Editor memory and build behavior.

Conclusion

ScriptableObject data resetting during Play Mode is not a Unity bug. It is expected behavior based on how Unity loads and reloads asset data. The confusion usually comes from modifying asset instances directly instead of working with runtime copies.

By instantiating ScriptableObjects at runtime, separating configuration from game state, and implementing proper save systems, you can avoid data loss and ensure predictable behavior in both Editor and builds.

Understanding how Unity manages asset memory is essential for building stable and scalable systems.