This post forms the second part of my article on ScriptableObjects.
In part one, we discussed ScriptableObjects in general: what they are, how to create them, and why to use them. We also saw how ScriptableObjects can be used as (stupid) data containers and (intelligent) blueprints.
In this post, I’ll first discuss how ScriptableObjects can be used as persistent managers. After discussing the different type of managers, I’ll show how I’m currently handling all the managers in my game without having to rely on a scene that loads all the required components in a predefined order.
This also means that I can start my game from any scene without having to worry about the managers that should be present when the game starts.
When you create classes in Unity, there is the ever present decision over whether or not to inherit MonoBehaviour. Basically, an instance class that relates to the spatial dimensions or should be attached to a game object, has to be a MonoBehaviour.
This has been aptly described as “the MonoBehaviour Tyranny”. Fortunately, it can be solved with ScriptableObjects.
This article is split into two parts. In the first part, we’ll first discuss what ScriptableObjects are, how to create them, and what’s the main purposes of using them.
In the second part, I’ll demonstrate how I’m using a static manager class together with singleton ScriptableObjects to overcome some issue that arise from the above-described “tyranny”.