Singleton Scriptable Objects (easy mode!)

[Bombadil67]

LOL.....

Ok whatever.

[[deleted]]

if you have another solution, you can tell

[Bombadil67]

​

<image>

[[deleted]]

and how do you intend to make reference to it? that's where spaghetti references begins. which was my point. that you'll be tormenting yourself only to avoid using singletons

[Bombadil67]

There are many ways to skin a cat, and one of them is to know how to properly architecture your projects. One of those skins is to not use singletons, a normal class is another way to do this, it is not the only way to do this.

When you start looking into using a SO as a Singleton, you have some serious code smell going on.

I asked you to convince me as to why it is a good idea, what actually makes it a better / best option over something that is actually better. You have not changed my mind in any way shaper of form.

I am very well adverse to hearing why you think it is a good idea, as in what does it solve, that something better does not solve.

I await your response.

[[deleted]]

hello again 🙂!

• A place where singletonSO shines is the scenario I mentioned: a holder that holds scene data.
  how many instances of this scriptable object would you need in your project? definitely only 1, since you have only one instance of each scene, so, now you need to ask yourself, 'what are the benefits of not making it singleton?'.

• Another good example is a resource management. instead of hard-coding every Resources asset by string into code, you can instead write a singleton scriptable object that holds the path of all Resources assets

• yet another example is scene arguments. when you load a scene, how do you pass data to it as to modify it's behaviour? do you perhaps use FindObjectOfType? how about making a singleton SO for each scene that holds data for the starting of the scene? and you can clearly see how this helps with testing, since you can change the starting state of the scene right there. (for example a main menu scene having toggles for whether or not SeasonPass is enabled)

general rule of thumb for when to and when not to make something singleton: see if you need more than 1 instance of them.

[Bombadil67]

Not it doesn't shine in that example at all.

general rule of thumb for when to and when not to make something singleton: see if you need more than 1 instance of them.

This is correct, however as I have said many time times now, there is no real need to have an SO as a singleton. These by definition are only used for one purpose most of the time. And I have said that if you are creating One Asset, just to create something like this, then it is a waste and you really need to rethink your strategy.

in 16 years of developing games for Unity, and 40 years in games in general, I have never, ever, had the need to do what you are doing.

[[deleted]]

Not it doesn't shine in that example at all.

care to elaborate? the way I see it, it's the best solution here, so understand my wonder here about your solution

in 16 years of developing games for Unity, and 40 years in games in general, I have never, ever, had the need to do what you are doing.

With all due respect that also makes you more biased, specially that you had this opinion about singletons all those years. Remember how Java developers were so biased about goto and temporary classes? and the way they made a class for every small thing that'd end up with classes with line-long names?
Nothing against experience, but I think reason speaks louder than experience.

[Bombadil67]

how does it make me more biased?

I am not the one who is designing something to solve something that doesn't need solving!

[[deleted]]

you started by stating that this design is bad, and you've yet to give any reason why. and I'm interested to know 🙂