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”.
I’m sure we’ve all felt the frustration with Unity API, when we can’t find the method we really need. A classic case is traversing the transform hierarchy. For instance, why on Earth we don’t have methods for iterating the children transforms? One reason might be that there are many ways to do it, suggesting that it’s left for us to implement them. But how is that possible? Quite simply – with extension methods.
Collision Propagators is an easy-to-use and fully extendable solution for handling collision events In Unity. It forwards Unity callbacks via events to be used by other components. Both Unity Events and native C# events can be used. Collision Propagators is built on top of Event Propagators, also available on the Asset Store.
Event Propagators is a simple solution for forwarding Unity callbacks via events (both native and Unity Events) to be used by other components. The purpose of this is to support better decoupling of your components. Event Propagators allows you to handle the callbacks in one place and react to them in another place(s).
Most programmers are familiar with the concept of events. Considering how popular Unity is, it’s still surprisingly difficult to find a single place of information on events applied in Unity environment.
I’ve met many individuals both on the internet and at work who either are ignorant of the benefits of events or simply don’t know how to use them in Unity. Many of the blog posts on the topic either provide a quick peek on the subject or delve to custom implementations with particular needs. Moreover, some of the information is simply wrong or at least bad advice.
In this article, I’m trying to address this lack of information, providing a solid place to learn the essentials of event-oriented development in Unity.