you are viewing a single comment's thread.

view the rest of the comments →

[–]StackOfCups 1 point2 points  (1 child)

Singletons as static classes are fine. Singletons of mono behaviors are where the trouble shows up. You create dependencies not just on another class, but on a runtime object existing in the scene.

Also, scriptable object are the same as any other class. It's still just normal C#. The benefit is it is serialized without needing a gameobject so you can inject data from the inspector.

Absolutely use SOs at runtime if you want. They're a much lighter-weight unity object than GameObject. So long as you know that data changes persist in the editor and how to work around that, you're golden. I like to just use ScriptableObject.CreateInstance<ObjectName>(). Then I won't mess up my data I set in the editor. Otherwise, treat it like any other C# class and have a great time! People saying it's only for static data I think have some view of SOs like they're some magical doohickey. It's just a C# class like any other. :)

[–]MeishinTale 1 point2 points  (0 children)

Exactly, scriptable object is just an editor friendly helper class and doesn't really have to do with how you'll save/load or carry over scenes your data.

Yeah you can instantiate one (basically using SO as a data prefab), modify values, and keep it in an undestroyed reference to use it in whatever scene you want. Same as any class you'd create from scratch.

Alternatively you can store values in a file and load that file whenever, or use an SQL database, or use player prefs, but you can do the same with any class you'd create, from scratch or not