Eonevolve Learning
Unity and DevelopmentUnity and codeIntermediate~6 min

ScriptableObjects as a Data Boundary

Snapshot

~80 sec

A ScriptableObject is a data asset that lives outside any single scene or MonoBehaviour. Moving shared, designer-facing config - an invented currency's starting balance, a soft/hard flag - into one asset gives every system a single source of truth instead of copies pasted across scenes.

You will learn

  • Explain what problem a ScriptableObject solves that a MonoBehaviour field does not.
  • Identify config that belongs in a ScriptableObject versus state that belongs in a MonoBehaviour.
  • Connect this data boundary to the same trust-boundary thinking used for soft and hard currency design.

Target outcome

You can point at one invented value in a project and say whether it belongs in a ScriptableObject asset or in a MonoBehaviour's own state.

Visual walkthrough

Visual walkthrough

~6 min

  1. Three roles worth separating

    • ScriptableObject asset

      Shared config saved as a file - one copy, read by many objects.

    • MonoBehaviour instance

      Per-object runtime state that changes during play - a current balance, not the starting rule.

    • Data boundary

      The line between config that should be edited once, and state that should change during gameplay.

  2. Config asset versus runtime reader

    Invented example. CurrencyDefinition holds the shared, editable rule; WalletView only reads it and never redefines the value itself.

    Languagecsharp
    [CreateAssetMenu(menuName = "Config/Currency Definition")]
public sealed class CurrencyDefinition : ScriptableObject
{
    public string displayName;
    public int startingBalance;
    public bool isHardCurrency;
}

public sealed class WalletView : MonoBehaviour
{
    [SerializeField] private CurrencyDefinition currency;

    private void Start()
    {
        // The MonoBehaviour reads shared config; it never redefines it.
        Initialize(currency.startingBalance, currency.isHardCurrency);
    }
}

    Code annotations

    1. Lines 1-6

      Shared config as an asset

      CreateAssetMenu lets a designer create and edit this data without touching code.

      Effect: Every object referencing this asset sees the same starting balance and currency type.

    2. Lines 8-16

      MonoBehaviour reads, does not own

      WalletView holds a reference to the asset and reads from it once at Start.

      Effect: The wallet's own runtime balance can change during play without ever mutating the shared config asset.

  5. Sort config from state

    An invented economy needs: (1) whether a currency is soft or hard, and (2) a player's current balance of that currency. Which belongs in a ScriptableObject, and which does not?

    Expected reasoning

    Whether the currency is soft or hard is shared design config that rarely changes and should live in the ScriptableObject. The player's current balance is per-player runtime state that changes constantly and belongs in a save-aware MonoBehaviour or data structure, not in the shared asset.

Go deeper