in unity 2020.x Unity just has introduced scriptable Singleton. a class that derives from Generic Class Called ScriptableSingleton its like singleton but you only can have single instance of it and seems to be good for ScriptableObjects that need to be Forced to be Single. but there are some differences.

they can be project Specific or Shared. they can get any format and unlike usual scriptableObjects they have no visualization in the inspector. the question is how should i use them and they are appropriate for which approaches? this is the link to the reference:


  • 2
    \$\begingroup\$ "its like singleton but you only can have single instance of it". That is the definition of a singleton. \$\endgroup\$
    – Evorlor
    Nov 7, 2020 at 23:47

1 Answer 1


According to the docs you link:

The ScriptableSingleton generic class allows you to create 'Manager' type classes in the Unity Editor. In classes that derive from ScriptableSingleton, serializable data you add survives assembly reloading in the Editor. Also, if the class uses the FilePathAttribute, the serializable data persists between sessions of Unity.

So based on this description, the ScriptableSingleton class is used for storing data that you might need for an editor utility.

Say you've built a custom plugin for the scene editor to do some procedural generation. And let's say it needs to do some heavy-duty pre-computation and caching when your assets/settings change, so that it can run at interactive speeds the rest of the time.

If you store that pre-computed data in a normal ScriptableObject, then you have to tell the utility where to look for it. And it gets confusing if someone makes two copies of the asset - which one should it use?

But if you store the data in static variables, then they're lost when you change your game code and reload the assembly, when you enter/exit play mode, or when you exit and re-launch the editor. So you redundantly do the slow pre-processing work over and over, bogging down the editor workflow.

The ScriptableSingleton appears to be made to solve those problems, giving these editor utilities a place to store persistent, easily-accessed information that won't get wiped out by common events like changing a script file.

If I'm reading it right, it looks like you can even store this data outside the Unity project, to share editor utility settings between multiple projects.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .