In this lesson, you will learn how to maintain consistent game state across scene transitions by using shared ScriptableObject assets as reliable data bridges.
The Problem with Scene Lookups
In a typical Unity project, developers often rely on FindObjectOfType or static references to communicate between scenes. This is fragile: if you switch scenes, the objects in the previous scene are destroyed, and your references become null. To build a robust architecture, we must decouple our data from the lifecycle of any specific scene.
The ScriptableObject Bridge
Because ScriptableObject assets exist as standalone files in your Project folder, they persist independently of the Hierarchy. By creating a "Data Channel" asset, both the sender (e.g., a Level Manager) and the receiver (e.g., the UI HUD) can reference the exact same instance, regardless of which scene is currently active.
Consider a simple IntVariable asset that tracks the player's current score:
[CreateAssetMenu]
public class IntVariable : ScriptableObject {
public int Value;
}
When you move from a "Gameplay" scene to a "Result" scene, you don't need to pass the score as a parameter or find the player. The "Gameplay" scene simply updates the Value inside your IntVariable asset, and the "Result" scene reads that same asset. Because the asset is an independent file in your project, its data survives the SceneManager.LoadScene process.
Implementation Tip
Think of these ScriptableObject assets as "Global Variables" that live in your project’s memory. To keep your system clean, avoid logic inside these objects. Instead, treat them as pure data containers that act as a shared blackboard. By referencing these in your components, you ensure that your systems remain decoupled—no scene ever needs to know about the existence of another, only about the data channel they both share.
Key Takeaway: By using ScriptableObject assets as persistent data containers, you decouple your game systems from scene-specific hierarchies, ensuring state survives transitions automatically.