When to Use Scriptable Objects Instead of Singletons in Unity

Singletons vs. Scriptable Objects: Debugging Your Unity Architecture

Over-reliance on Singletons can lead to a tangled mess in Unity.

They seem convenient, but can create tight coupling and hinder testability.

Let’s diagnose and fix this by exploring when Scriptable Objects offer a superior solution.

The Singleton Pattern: Global Access, Global Problems?

Singletons provide global access to a single instance of a class.

public class GameManager : MonoBehaviour
{
    private static GameManager _instance;
    public static GameManager Instance { get { return _instance; } }

    private void Awake()
    {
        if (_instance != null && _instance != this)
        {
            Destroy(this.gameObject);
        } else {
            _instance = this;
            DontDestroyOnLoad(this.gameObject);
        }
    }

    public int playerScore = 0;
}

Accessing the score is then as easy as GameManager.Instance.playerScore.

This simplicity is tempting, but it comes at a cost.

Singletons introduce hidden dependencies, making it hard to reason about your code.

Changes in one Singleton can have unforeseen consequences elsewhere.

They also make unit testing a nightmare since you can’t easily isolate and mock dependencies.

Scriptable Objects: Data Containers with Flexibility

Scriptable Objects are data containers independent of scene objects.

Think of them as reusable assets that can hold game data, configurations, or even code logic.

To create a Scriptable Object:

using UnityEngine;

[CreateAssetMenu(fileName = "EnemyData", menuName = "ScriptableObjects/EnemyData", order = 1)]
public class EnemyData : ScriptableObject
{
    public string enemyName;
    public int health;
    public float speed;
}

You can then create instances of EnemyData directly in the Unity editor.

Singleton vs. Scriptable Object: A Comparative Analysis

Scriptable Objects excel in data-driven game design.

Enemy stats, item definitions, and game settings are perfect candidates.

Unlike Singletons, you can easily create variations and tweak values without code changes.

Imagine defining enemy types using Scriptable Objects.

Each enemy instance references its specific EnemyData asset.

Changing the health in the Scriptable Object affects all enemies of that type. No recompile needed!

Refactoring: Singleton to Scriptable Object – Step by Step

Let’s say your GameManager Singleton handles game settings like volume levels.

1. Create a GameSettings Scriptable Object: Define volume levels and other settings within this asset.

   🚀 Get Your Personalized Game Dev Plan

   Tailored tips, tools, and next steps - just for you.

   using UnityEngine;
   
   [CreateAssetMenu(fileName = "GameSettings", menuName = "ScriptableObjects/GameSettings", order = 1)]
   public class GameSettings : ScriptableObject
   {
       [Range(0, 1)] public float masterVolume = 1f;
       [Range(0, 1)] public float musicVolume = 0.5f;
   }
   

2. Remove Volume Logic from GameManager: Delete the volume-related code from the GameManager Singleton.

3. Reference GameSettings in Relevant Scripts: Add a GameSettings field to scripts that need volume data and assign the Scriptable Object in the Inspector.

   public class AudioManager : MonoBehaviour
   {
       public GameSettings gameSettings;
   
       void Start()
       {
           AudioListener.volume = gameSettings.masterVolume * gameSettings.musicVolume;
       }
   }
   

This decouples the volume settings from the GameManager, making your code more modular and testable.

You can now easily create different GameSettings profiles for different game modes or difficulty levels.

Debugging Tips

• NullReferenceExceptions: Ensure Scriptable Objects are assigned in the Inspector.
• Data Persistence: Scriptable Object data is persistent between sessions in the editor. This can be useful or problematic, depending on your needs. Be mindful of unintentionally saving changes.
• Runtime Modification: Changes to Scriptable Objects at runtime will persist in the Editor if you don’t reset them or handle data saving/loading explicitly.

Common Pitfalls and How to Avoid Them

• Overusing Scriptable Objects for EVERYTHING: Not everything needs to be a Scriptable Object. UI management or specific game logic might still belong in MonoBehaviour scripts.
• Modifying Scriptable Objects During Play Mode Without Consideration: Remember, changes made during play mode are persistent in the editor by default. Resetting the data or implementing a proper saving mechanism is critical.
• Using Singletons for Data Storage: This is a code smell. Data belongs in Scriptable Objects or other data containers, not tightly coupled within a Singleton’s behavior.

As you work to debug your game’s architecture and streamline your systems with Scriptable Objects, remember to document your progress. A dedicated game development journal can be an invaluable tool for tracking your decisions, identifying potential problems, and maintaining consistency throughout the development process. Try out our simple game development journal to help you stay organized!

By understanding the strengths and weaknesses of both Singletons and Scriptable Objects, you can make informed decisions about which pattern best suits your needs, leading to cleaner, more maintainable, and testable code.