Course contentsShow
← Unity Game Development
Lesson 233 of 8284. Prefabs and Data ManagementFree lesson

Modifying ScriptableObject Data at Runtime

Understand the implications of changing asset values during gameplay and how these modifications persist within the editor environment.

In this lesson, you will learn why modifying ScriptableObject data during play mode creates persistent changes in your project and how to handle this behavior.

When we create a ScriptableObject, it exists as an asset file within your Project window. Because it is an asset, it acts similarly to a Prefab; when you change its values through code while the game is running, you are not just changing a temporary variable—you are modifying the actual asset file on your hard drive.

The "Sticky" Nature of Assets

Imagine you have a PlayerData ScriptableObject that stores a currentLevel integer. If you write a script that updates playerData.currentLevel++ when a player finishes a level, that value will remain changed even after you stop the game. Unlike standard variables in a MonoBehaviour (which reset when you exit Play Mode), modifications to ScriptableObjects persist because the asset itself was updated.

Practical Example

Consider this simple script attached to a button:

public class LevelManager : MonoBehaviour
{
    public PlayerData settings;

    public void CompleteLevel()
    {
        // This modifies the asset file directly
        settings.currentLevel += 1;
    }
}

If you start your game at Level 1, click a button to complete the level, and then stop the game, your PlayerData asset file will now show Level 2 in the Inspector.

Why This Matters

This persistence is incredibly powerful for game design, as it allows you to tune balancing values (like jump height or enemy health) while play-testing, and keep those tweaks. However, it can also be dangerous. If your game logic relies on a ScriptableObject to track temporary session state, you might accidentally save "garbage" data that persists into your next testing session or, worse, persists into the final build if you aren't careful.

If you need temporary data that resets every time you start the game, use a MonoBehaviour or a standard C# class instead. If you want the data to persist as part of the game's configuration, a ScriptableObject is perfect, but be aware that every change made in Play Mode is a permanent change to your project files.

Key Takeaway: Modifying a ScriptableObject at runtime changes the actual asset file on your disk, meaning those modifications will persist after you stop the game.