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”.
If you’ve ever had to import animations into Unity, it’s likely that you have found yourself going through the same tedious process of manually tweaking the clip settings for each clip. And if the animations changed, you probably had to repeat the process – many times. At least I had.
So I made a simple editor tool to automatize the animation clip setup. Once the clip settings are defined, it now takes only a few clicks to apply them on multiple clips in one or multiple files.
You can find Animation Processor on Unity Asset Store. It’s free, like all the other tools I’ve published.
Ragdoll Copier is now available on Unity Asset Store. Ragdoll Copier is a simple editor utility that enables you to copy an existing ragdoll from a character to another with a few clicks. It’s useful for example if your character model is updated and you have to switch in the new visuals. Without Ragdoll Copier, you would have to recreate the ragdoll. It’s also useful if you have multiple prefabs of the same model. No more need to create a ragdoll for each of them separatedly.
GameObjectPooler is now available on Unity Asset Store. It’s based on an entirely static helper class with easily accessible extension methods. This means you can simply call
instance.Recycle(). And basically that’s it! No tedious manual setup required! Of course the system provides more optional features, if you need them.
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.