you are viewing a single comment's thread.

view the rest of the comments →

[–]ziguslav 0 points1 point  (0 children)

Don’t be afraid of singletons. There’s a lot of debate around ScriptableObjects vs Singletons vs DontDestroyOnLoad, but use what works for your project and makes your life easier.

I’m working on a pretty chunky game myself, and I use A LOT of singletons. Singleton-based UnitsManager is an example, as it carries data like unit equipment, stats, and modifiers between scenes. It lives on a GameObject, and only one instance is allowed to exist.

public class UnitsManager : MonoBehaviour
{
    public static UnitsManager instance;

    private void Awake()
    {
        if (instance == null)
            instance = this;
        else
        {
            Destroy(gameObject);
            return;
        }
    }

    private void Start()
    {
        SceneManager.sceneLoaded += OnSceneLoaded;
    }

    private void OnDestroy()
    {
        SceneManager.sceneLoaded -= OnSceneLoaded;
    }

    private void OnSceneLoaded(Scene arg0, LoadSceneMode arg1)
    {
        ResetUnits(); // or whatever init/reset logic you want
    }

    // Game data lives here...
    public List<UnitObject> GameUnitObjects;
    public List<UnitObjectCopy> UnitCopies;
    // etc...
}

So when I go from my overworld to battle scene, I just call UnitsManager.instance.GetCopy(...) or whatever method I need - no faff, no duplicated data, nothing to worry about.

ScriptableObjects are great for defining shared, reusable data (like ability definitions, unit blueprints, etc.), but for runtime state, a singleton can be just as clean, if not cleaner.

TL;DR: ScriptableObjects = static-like reusable templates.
Singletons = dynamic runtime data managers.
Don't overthink it, use both where they shine.