{"id":531,"date":"2021-09-17T20:07:48","date_gmt":"2021-09-17T20:07:48","guid":{"rendered":"https:\/\/bronsonzgeb.com\/?p=531"},"modified":"2021-09-17T20:07:49","modified_gmt":"2021-09-17T20:07:49","slug":"the-type-object-pattern-with-scriptable-objects","status":"publish","type":"post","link":"https:\/\/bronsonzgeb.com\/index.php\/2021\/09\/17\/the-type-object-pattern-with-scriptable-objects\/","title":{"rendered":"The Type Object pattern with Scriptable Objects"},"content":{"rendered":"\n
This article will demonstrate how to implement the Type Object pattern in Unity using Scriptable Objects.<\/p>\n\n\n\n
What problem does Type Object solve?<\/h2>\n\n\n\n
There’s plenty of literature on the subject, but I’ll briefly explain the origins of this pattern. Let’s put Unity aside for a moment. Imagine you had to define a bunch of different buildings for your city builder game. In classical OOP style, you maybe be tempted to start with a base Building<\/code> class. Then, you’d subclass Building<\/code> for each new type and adjust the building cost, sell price, income generated, etc. Now you have a bunch of subclasses with nothing but a few variables changed here and there. Plus, you have to recompile your code every time you add a new building or change the cost of an existing building. Using subclasses to define types is both a hassle and inflexible.<\/p>\n\n\n\n
Now back to Unity. In Unity, it’s unlikely you’d take this approach at all. Instead, you’d define some building component and attach that to a prefab. Then for every new type, you’d create either a new prefab or prefab variant. So, Unity has already helped us turn our code into data in the form of prefab files. Great! Turning code into data is the aim of the Type Object pattern. Rather than creating a Type<\/code> to represent variants of a class, we create a single Type<\/code> that holds all the variable data. Then we make new types through data rather than through code.<\/p>\n\n\n\n
So if Unity already solved the problem, what’s the point of this article? Well, I’m here to offer a different approach. You’ll still use prefab variants, but Scriptable Objects provide further benefits on top of the variant system.<\/p>\n\n\n\n
Scriptable Objects as Type Objects<\/h2>\n\n\n\n
We’ll create a bunch of monsters and experience the Scriptable Object advantage first-hand. Let’s jump right in with some code.<\/p>\n\n\n\n
using UnityEngine;\n\npublic class Monster : MonoBehaviour\n{\n public int Health;\n public int Speed;\n public int Attack;\n}<\/code><\/pre>\n\n\n\n
Behold the classic monster. Admittedly it’s a simple example, but it’s enough for demonstration purposes. Here, our monster has three stats: Health, Speed, and Attack. As I mentioned before, generally, in Unity, you would attach this component to a prefab and modify the stats on each variant to define new monsters. This is a good approach, but when we throw a Scriptable Object into the mix, we gain several advantages for minimal cost.<\/p>\n\n\n\n
Let’s quickly build something to provide some context. Create a new Type Object that derives from Scriptable Object with our base values.<\/p>\n\n\n\n
using UnityEngine;\n\n[CreateAssetMenu]\npublic class MonsterType : ScriptableObject\n{\n public int StartingHealth;\n public int BaseSpeed;\n public int BaseAttack;\n}<\/code><\/pre>\n\n\n\n
Now, modify the Monster class to hold a reference to the Type Object.<\/p>\n\n\n\n
using UnityEngine;\n\npublic class Monster : MonoBehaviour\n{\n public int Health;\n public int Speed;\n public int Attack;\n public MonsterType Type;\n\n void Start()\n {\n Health = Type.StartingHealth;\n Speed = Type.BaseSpeed;\n Attack = Type.BaseAttack;\n }\n}<\/code><\/pre>\n\n\n\n
Then, in the Start<\/code> method, copy the base values from the MonsterType<\/code> into this instance of a monster. By the way, this is a crucial step because any modifications to Scriptable Objects will affect all the objects referencing it. Not to mention, those modifications persist in and out of play mode. So if you change these base values while your game is running, you’ll lose your carefully balanced stats.<\/p>\n\n\n\n
Scriptable Objects, Prefabs and Version Control<\/h2>\n\n\n\n
When it comes to version control, merging complex assets is a pain. It’s common to run into a situation where a designer must balance stat values across several creatures in a game. At the same time, artists may iterate on the visuals while gameplay developers attach new components. If multiple developers make simultaneous changes to the same prefab, it’s unlikely that those changes will merge cleanly. In this case, someone will have to redo work. What if we could split these tasks into separate assets, eliminating merge conflicts? That’s where Scriptable Objects come in.<\/p>\n\n\n\n
When the stats live inside a Scriptable Object, designers can change them without touching the prefab file at all. As a result, the only merge conflicts that arise come from two designers tweaking the same value. What’s more, when conflicts occur, they’re easier to solve because Scriptable Object files are more readable. For comparison, here’s a simple prefab:<\/p>\n\n\n\n
The Scriptable Object is almost<\/em> human-readable. Plus, the stats StartingHealth<\/code>, BaseSpeed<\/code>, and BaseAttack<\/code> are<\/em> readable, which are the values most likely to change.<\/p>\n\n\n\n
Next, let’s explore the power of Scriptable Object as references.<\/p>\n\n\n\n
Scriptable Object References<\/h2>\n\n\n\n
I had a hard time titling this section, but bear with me for a minute, and you’ll see where I’m going with this. One of the main advantages of Scriptable Objects is that they are first-class citizens in the Unity editor. What does that mean? Scriptable Objects automatically work with all the editor systems. They serialize and deserialize easily. The Inspector recognizes them as referenceable objects. They simply work. Now, this is pretty awesome, but it’s only part of the story. Multiple objects can reference a single Scriptable Object through dragging and dropping in the Inspector. Plus, it’s easy to test if two references are pointing at the same thing. Why do we care? Let’s find out.<\/p>\n\n\n\n
Let’s say our monsters have weaknesses to other monsters. By referencing MonsterType<\/code> directly, designers can define weaknesses by dragging and dropping Scriptable Objects in the Inspector.<\/p>\n\n\n\n
Let me show you what I mean. Add a MonsterType<\/code> array called Weaknesses<\/code>.<\/p>\n\n\n\n
using UnityEngine;\n\n[CreateAssetMenu]\npublic class MonsterType : ScriptableObject\n{\n public int StartingHealth;\n public int BaseSpeed;\n public int BaseAttack;\n public MonsterType[] Weaknesses;<\/strong>\n}<\/code><\/pre>\n\n\n\n
This field will appear in the Inspector as a list of MonsterType<\/code> elements. You can freely modify a monster’s Weaknesses<\/code> as you wish. <\/p>\n\n\n\n
Worms are weak to Pidgeons and Cats<\/figcaption><\/figure><\/div>\n\n\n\n
But how do you know if a monster is weak to another monster? Let’s add a helper to the Monster<\/code> class.<\/p>\n\n\n\n
using UnityEngine;\n\npublic class Monster : MonoBehaviour\n{\n public int Health;\n public int Speed;\n public int Attack;\n public MonsterType Type;\n\n void Start()\n {\n Health = Type.StartingHealth;\n Speed = Type.BaseSpeed;\n Attack = Type.BaseAttack;\n }\n\n public bool IsWeakAgainst(MonsterType type)\n {<\/strong>\n foreach (var weakness in Type.Weaknesses)\n {\n if (type == weakness)\n return true;\n }\n\n return false;\n }<\/strong>\n}<\/code><\/pre>\n\n\n\n
Since MonsterType<\/code> is a reference, we check if a given type<\/code> is ==<\/code> to any elements in the Weaknesses<\/code> array. If yes, we know both variables are pointing to the same Scriptable Object, and consequently, it’s part of the monster’s weaknesses. Isn’t that neat?<\/p>\n\n\n\n
You could extend this as well. What if you had two nearly identical monsters, but one of them was fiery? Create a new Element<\/code> type and add it to MonsterType<\/code> with an accompanying ElementalWeaknesses<\/code> array. Then you can check if a given monster is weak against a certain element too.<\/p>\n\n\n\n
Using Scriptable Objects makes it straightforward to compose new variants through data by dragging items around the editor, which is the purpose of the Type Object pattern.<\/p>\n\n\n\n
Wrap-Up<\/h2>\n\n\n\n
I want to extend this example further by adding abilities to the monsters with Scriptable Objects. However, that’s veering away from the Type Object pattern and into the Command pattern. So, I’ll save that for a future post!<\/p>\n\n\n\n
![\"\"](\"https:\/\/bronsonzgeb.com\/wp-content\/uploads\/2021\/09\/WormWeakness.png\")