Scriptable Object Singletons, why use them?

Hi,

I recently started looking up information on game architecture and I've heard that using Singletons is not a good idea. I have also started to learn more about scriptable objects and how they are just amazing. I recently watched the Unity Open Projects video called Chop Chop and it went on and on about how good scriptable objects. And around the same time, I learned about Scriptable Object Singletons and they have me confused.

What I can't fully wrap my head around is that, if singletons are bad, why is a scriptable object singleton better?

Also, I was watching the Unity Learn Swords and Shovels courses and I noticed something. During the character stats video, the instructor created a scriptable object that contained all of the stats and methods to manipulate them.

My question regarding that is, is something like that a good idea because I thought that SO's should be used like a data container that you pull from not write to? If it is okay to do it with the character's stats, which I assume will change as he levels up, why not do it with the inventory and equipment also. Just make a Inventory SO, and plug all the logic in like the stats and just inject it into the mono behavior that needs it? What makes one use case better than the other?

Thanks!

 

They're not.

Maybe you should ask that question of whoever is making the claim that it is, because I have never heard of a scriptable object singleton.

The main argument I've heard against singletons is basically that they're too good - that is to say, they're so convenient and useful that you might get in the habit of using them everywhere, and they're not appropriate everywhere. So as long as you limit singletons to where they're appropriate - that is, limit them to a situation where you will always only have one copy of something - they're good. And they're particularly good in Unity, because there's no easy way to edit fields and assign references in a plain static class.

I'm not even sure offhand how one would even make a ScriptableObject Singleton, at least a useful one. They don't have methods like Awake() that you can use to self-assign the static reference, so you'd have to assign the reference through some other script that either has a reference or calls something like Resources.Load... and at that point you really just have a manager, not a singleton. You could then shoehorn a singleton into that, but why would you?

 

Looks like it is a fairly recent introduction, assuming this is what the OP is referring to, I came a cross it a few days ago.
https://docs.unity3d.com/2020.1/Documentation/ScriptReference/ScriptableSingleton_1.html

 

Trust me, you're not alone.

Watch:

 

Bingo!

 

I'd like to note that the video you linked is talking about how to implement an equivalent to a class that, apparently, already exists in recent versions of Unity. Unity's version even has a class attribute that presumably creates and manages the file for you.

So with that busy-work done for us, suddenly a ScriptableSingleton is actually wildly useful! For all the same reasons that singletons are useful, but it makes it much harder to run afoul of the situations where singletons are not appropriate as described in my first comment.

 

Thanks for that. So, with that being said, these are actually better than the plain o'le singleton? It would be safe (even recommended) to refactor, say for example, my inventory class singleton to a scriptable object singleton?

 

Just to cool your enthusiasm...

ScriptableSingletons are editor only, part of the

UnityEditor

namespace.

 

Regarding Singleton as a pattern, there are two types of people, who don't like it and *you can't call private constructor*

So, mostly people argue about the thing that it restricts you from creating another instances. A lot of good programmers say that it's okay to mean class to have one instance, but not to make it impossible to create another one.

Singleton is very-very popular and tricky pattern. I personally using only when I know that creating another instance of the class will break something.

I think you have already ran across Game Development Patterns which has quite nice description about it. I'd trust it.

 

Suddenly a ScriptableSingleton is actually wildly worthless!

WHYYYY would they make a base class so useful and then just.... URRRRGH.

 

If I had to guess it's because of the persistence. But yeah, I wish it was runtime too.

 

Hi, It sees like this is in Editor namespace.
Also i was getting few issues with it
https://stackoverflow.com/questions...values?noredirect=1#comment122386016_69243728

 

Ooh, that's very useful for editor tools though!

 

So this video makes use of the Resource folder and Resource.LoadAll.
But I've come to understand that Resources should no longer be used. Explained here https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity6.html
How would you adjust this to not use Resources?
Perhaps use Addressables instead?

 

Personally speaking, whilst the idea of adddressables seems good and solves the issues mentioned in that article; In practise, the async only method of loading has always caused me too many headaches to make them practical to use.

I'll be sticking with Resources for the time being, as long as they aren't abused, there is no problem with them.

 

You can load addressables synchronously if that suits your needs better: https://docs.unity3d.com/Packages/com.unity.addressables@1.17/manual/SynchronousAddressables.html

Personally I've had zero issues using async code to work with addressables.

 

Singleton is "evil" because it is too easy to be abused. I have deal with a project with a big singleton global state object, and most of the time, no one knows who and when and where changed that state, because anycode can change it at anytime at anywhere. Avoid any stateful singleton as possible as you!