ScriptableObjects

A ScriptableObject is a data class that becomes a FILE in your project — editable in the Inspector, reusable everywhere, with no scene attached. It is Unity's way of saying "content is data," and it is the pipeline behind every card in the card jam.

The definition, and the two-line comparison

A MonoBehaviour lives ON a scene object and runs code in the frame loop (Start, Update). A ScriptableObject lives IN the project as an asset and holds values — nothing more. You do not add it to a GameObject; you create instances in Assets and reference them.

	MonoBehaviour	ScriptableObject
Attached to	GameObject in a scene	Nothing — it IS an asset (.asset file)
Lifecycle methods	Start, Update, collisions	OnEnable at most — no frame loop
Each scene has	its own instance	references to the SAME asset
Edited in	Inspector, per scene object	Inspector, in the project, everywhere
Your year used it for	every controller	Card data (10.2b)

Writing one

[CreateAssetMenu(menuName = "Cards/New Card")]
public class Card : ScriptableObject
{
    public string cardName;
    public Sprite art;
    public int cost;
    public int attack;
    public int defense;
    public string description;
}

Then: right-click in Assets → Create → Cards → New Card. An .asset file appears; the Inspector shows your fields; you fill them in. That is the whole "pipeline": one class definition, then unlimited data, no further code.

// referencing them — the deck is a list of card ASSETS:
[SerializeField] private List<Card> startingDeck;
// drag card assets into the list in the Inspector. Done.

Assets are referenced, not copied

The subtle, load-bearing fact: when three different hands hold "the same card," memory holds one card object with many references — the same relationship your scene YAML has to sprites by guid (9.4). Consequences, good and bad:

• Good: one edit ("this card costs 3 now") updates every deck and every hand everywhere, instantly
• Good: memory — a 30-card deck is 30 pointers, not 30 copies
• Bad: runtime edits persist. Change a card's attack during Play mode, stop, and the change is STILL THERE — asset data outlives the session in a way scene data does not. Never mutate ScriptableObject fields as "temporary game state"; clone first if you need per-run copies (Instantiate makes a runtime copy for exactly this)
• Bad: deleting the asset file breaks every reference — the same pink-missing-sprite disaster as deleting a sprite without its consumers

When to reach for one (and when not)

Reach for a ScriptableObject when the data is authored content: many instances, edited by designers, referenced from scenes and lists, and stable across play sessions — cards, weapons, enemy types, level configs, palette definitions (9.2's palette is a candidate). Do NOT use one for live state: current health, this run's coins, a hand's current contents — that belongs to the scene/prefab world (fields on MonoBehaviours) or the singleton that survives scenes (2.1). The rule of thumb: ScriptableObjects are the nouns in the dictionary; MonoBehaviours are the sentences being spoken right now.

The exam connection

The Create PT's rubric wants a list that participates meaningfully. A List of ScriptableObject assets is the most legible version of that in Unity — the list's purpose (a deck) and its content (authored cards) are visible in two Inspector panes, no code spelunking required. The abstraction argument is clean too: one Card class describes ALL cards — that is a data abstraction managing content complexity, in writing, with screenshots (11.1b).

Where you meet ScriptableObjects this year

• 10.2b — cards as assets — the lesson this reference serves
• Lists & Arrays — the lists that hold them
• 9.4 — Your Scene Is Data — the asset/guid system underneath