Killing the God Class: The Architecture of Scriptable Objects

Welcome to Local Space.

If you are new here, this is my recurring dev log. I spend my week building in Unity, figuring out how to make things work, and inevitably breaking them. Then, I share the notes, tools, and code snippets that actually survived the process.

In this log, we are tackling Unity's most powerful architectural feature: Scriptable Objects. We aren't just using them to store variables; we are using them to decouple our logic, streamline our tools, and make our indie studio scalable.

1. Decoupling Logic from Data (Technical Deep Dive)

The "God Class" is the enemy of indie dev. It’s tempting to write a `Spaceship.cs` that handles movement logic, input, and holds the variables for "Max Speed" and "Hull Strength."

Technical Deep Dive: Scriptable Objects allow you to separate the Data (What the ship is) from the Logic (How the ship moves). This prevents memory bloat. Instead of 1,000 enemy ships each holding their own integer for `maxHealth`, they all reference a single Scriptable Object in memory.

// The Data (Scriptable Object)
[CreateAssetMenu(fileName = "NewShipData", menuName = "Ship Data")]
public class ShipStats : ScriptableObject {
    public float maxSpeed = 50f;
    public float turnRate = 2f;
}

// The Logic (Monobehaviour)
public class ShipController : MonoBehaviour {
    // Drag the asset here. No magic numbers in code.
    public ShipStats stats; 

    void Update() {
        Move(stats.maxSpeed);
    }
}

2. The Event Channel (Asset & Tool Spotlight)

How do you tell the UI that the Player died without the Player script needing a reference to the UI Manager? You need an Event System.

The Tool Spotlight: While you can write this yourself (the famous "Game Architecture with Scriptable Objects" talk), I highly recommend looking at SO-Events or, for a premium workflow, Odin Inspector.

Odin allows you to visualize your Scriptable Objects with buttons and sliders directly in the inspector. It turns your raw data assets into a fully functional Designer Dashboard, allowing you to test events by literally clicking a button on the asset file.

3. Runtime Balancing (Game Design Theory)

Balancing a game is about "feel." You cannot calculate "fun" on paper; you have to feel it while the game is running.

A unique property of Scriptable Objects is that they save changes during Play Mode. If you tweak a Monobehaviour variable while playing, it resets when you stop. If you tweak a Scriptable Object, the value sticks.

4. Reducing Technical Debt (Business of Indie Dev)

From a business and production standpoint, Scriptable Objects resolve one of the most expensive problems in development: Merge Conflicts.

If your Game Designer wants to change the damage of a weapon, and your Programmer wants to change the code for how weapons fire:

• Without SOs: Both edit `Weapon.cs`. Git creates a conflict. Someone has to manually fix it. Time is wasted.
• With SOs: The Designer edits `WeaponData.asset`. The Programmer edits `WeaponLogic.cs`.

They are two different files. There is no conflict. Utilizing this architecture allows your team to scale; you can hire a level designer to populate the world with items (Data) without them ever touching the codebase (Logic).

// When you are ready

Here are 3 ways I can help you level up your game dev journey:

Local Space is a production of Faktory Studios.
© 2024 All rights reserved.