If you're a Unity developer, you've likely heard of MonoBehaviour 📘, but there's another lesser-known feature that can be a game-changer for your workflow - Scriptable Objects.

While these might not have the same fame as their MonoBehaviour cousins, underestimating them could mean missing out on a powerful tool 🔧 that can streamline your development process and vastly improve the efficiency and flexibility of your games 🎮.

Scriptable Objects are a versatile data container (and much more) used in the Unity engine.

They are designed to enable you to create, store, and manipulate custom data independent of script instances, a feature that provides numerous advantages, particularly in a complex game where data needs to be shared across multiple scenes and scripts.

But what does this really mean? 🤔 And how can you leverage Scriptable Objects to elevate your game development process?

This article aims to demystify Scriptable Objects, delving into their benefits, illustrating their use through practical examples, and demonstrating how they can revolutionize your approach to game design.

Whether you're a seasoned Unity developer or a novice just starting your journey, our exploration of Scriptable Objects will provide you with valuable insights and tools to take your projects to the next level 💪.

So, strap in and prepare to unlock the full potential of your game development process! 🚀

Welcome to the fascinating world of Unity's Scriptable Objects! If you're a Unity developer, you might already be familiar with the concept of objects. But Scriptable Objects? That might be something new.

Scriptable Objects are a special kind of data container that Unity provides us with. In essence, a Scriptable Object is an instance of a script in your project, separate from MonoBehaviour, that allows you to store large amounts of shared data independent from class instances.

They are, in fact, serializable, custom data structures! 🎓

"But, why should I care?" 🤔

Good question! Scriptable Objects can be a massive boon to your game development process. They offer an excellent way to create and store data that isn't tied to a specific GameObject. Imagine having game data that doesn't disappear or reset every time you hit the play button. Sounds dreamy, right? Well, that's the magic of Scriptable Objects! ✨

Scriptable Objects open up a plethora of benefits for game developers. Here are some significant advantages to integrating Scriptable Objects into your Unity projects:

Remember, while Scriptable Objects offer many benefits, they are not a silver bullet for all situations. In the next sections, we'll take a look at when it's appropriate to use them and some common mistakes to avoid. Stay tuned! 🎵

If you've been using Unity for a while, you're likely quite comfortable with MonoBehaviours. They're the backbone of Unity's scripting system, allowing you to attach custom behavior to your GameObjects. However, MonoBehaviours have some limitations, which is where Scriptable Objects shine. Let's understand this with a quick comparison.🔍

MonoBehaviours live on GameObjects and can't exist without a GameObject to hold them. This design is excellent for handling game logic related to GameObjects, but it makes them less ideal for managing game-wide data.

Additionally, the data inside MonoBehaviours gets reset every time you hit play in the editor.

If you're trying to balance your game by tuning parameters in play mode, those changes will be lost when you stop playing. 🔄

Enter Scriptable Objects. These versatile containers aren't tied to GameObjects and can store data persistently even when the game stops running in the editor. Imagine being able to tweak game parameters on the fly without losing your changes—That's the power of Scriptable Objects! 💪 Furthermore, Scriptable Objects can be referenced by multiple scripts or objects, making them ideal for shared data and settings.

🧙‍♂️🎮 In a typical RPG game, you might have various types of elements like characters, weapons, potions, and a storyline. Let's think of all these as the "actors" or MonoBehaviours of our game. They interact with each other, perform actions like battling monsters, healing, or leveling up, and react to events such as user input or game state changes.

Now, suppose you have a complex system of character stats, weapon stats, and potions that affect these stats. You could store this information within the MonoBehaviour scripts attached to each object, but it quickly becomes hard to manage, especially if different objects need access to the same data. Here's where Scriptable Objects come in handy!🔑

Imagine Scriptable Objects as the "directors" of our game. They don't actively participate in the gameplay but hold critical information that defines how the game operates.

For example, a Scriptable Object could hold the data for a specific character class, including attributes like health, mana, strength, agility, and intelligence. The same goes for weapons and potions, where each type could have a corresponding Scriptable Object holding its specific stats. 📚

This approach provides a centralized location for all of your game's vital data, making it much easier to manage and tweak.

Plus, you can adjust these values in real-time while the game is running in Unity's editor, and they'll persist after you stop playing, making it a breeze to balance your game!

Another advantage of this approach is the easy sharing of data.

For instance, a health potion MonoBehaviour can reference a Scriptable Object to know how much health it should restore. And a character's MonoBehaviour can also reference the same Scriptable Object to modify the character's health. This reusability prevents data duplication and promotes a more robust and flexible system. 💼

To sum up, in our RPG game, Scriptable Objects are like the directors, setting the scene by defining the properties of the characters, weapons, and potions, while the MonoBehaviours (characters, weapons, potions) are the actors that perform actions and interact based on these predefined rules. 🎬

I hope this RPG example makes the MonoBehaviour-Scriptable Object relationship clearer.

In Unity, creating a Scriptable Object is as straightforward as creating a new C# script. Start by creating a new script in your project's Scripts folder and name it something relevant. For our example, let's call it 'CharacterData'. This script will store the various attributes for different character classes in our RPG game.

In the CharacterData script, instead of inheriting from MonoBehaviour, you should inherit from Scriptable Object. Below is an example of how your CharacterData script might look:

The [CreateAssetMenu] attribute above the class declaration allows you to create new instances of this Scriptable Object via the Unity editor's 'Assets' menu. 📁

Your MonoBehaviour script will now have access to all the data stored in the Scriptable Object, allowing you to use this data in your gameplay scripts. It's that simple! 🎉

In Unity, Scriptable Objects have their own lifecycle and set of callbacks that are triggered at different points of their existence. To better understand how and when these events happen, let's go through each callback:

Remember, understanding these lifecycle events is key to harnessing the full potential of Scriptable Objects in your game development. So, spend some time exploring these concepts and experimenting with them in your projects.

A scriptable object on the device is like a pointer, every time you load a scriptable object with Resources.Load<>(Constants.GAME_DATA_PATH); the SAME scriptable object will be loaded, not a new one or a copy. (It’s like a pointer to the same resources)

When you are in editor mode, every change made during the session will be saved, but on the device, once the session is over, all the changes made to the scriptable object will be LOSE.

As game developers, we often want to use ScriptableObjects as mutable data containers that are synchronized across all scenes during runtime, including in the build. The challenge comes in understanding how to maintain this data consistently across scenes, especially when dealing with the concept of "resets."

When a scene is loading, serialized references to assets in the scene will cause the instantiation of these assets as new runtime objects. ScriptableObject assets are no exception to this.

In essence, the data "resets" due to the creation of new instances of the asset during scene transitions. This could lead to the perception that ScriptableObjects are losing data between scenes.

Let's say in our RPG game, we have a ScriptableObject named "PlayerData" that holds vital statistics about our player character, such as health and experience points. These values are dynamic and can change during gameplay.

Now, let's say our brave hero 🗡️ has just finished a ferocious battle in Scene 1. They've gained experience points and lost some health, both of which are stored in our "PlayerData" ScriptableObject. Then, our hero moves onto Scene 2.

Upon loading Scene 2, Unity will instantiate a new "PlayerData" ScriptableObject based on the initial, serialized blueprint of "PlayerData". This is akin to a 'reset'. Therefore, rather than seeing the updated health and experience points from the battle in Scene 1, we might see the 'fresh' character stats as they were when the game first started.

The problem with "resets" is the following: when a scene is loading, serialized references to assets in this scene will cause instantiating of these assets as new runtime objects, and scriptable object assets are not an exception, therefore, if you have mutated data in the instantiated Asset Ain scene 1, in scene 2 you often will have another instance of Asset A with all states "resetted" because its object was created from serialized "blueprint" of Asset A

This example illustrates the importance of understanding how Unity handles ScriptableObject instances across scenes, and why we need to implement measures to maintain consistent, mutable data. 🎮🔄

To prevent the unloading of ScriptableObjects between scenes, even if they're not referenced in one scene, you can add a specific code snippet to your ScriptableObject (see the solution here: http://answers.unity.com/comments/1569389/view.html).

Basically, you can set the ScriptableObject's hideFlag to prevent it from unloading through scenes where it's not being referenced, like so:

This understanding is crucial for leveraging the power of ScriptableObjects in managing data across different scenes, providing a seamless and consistent gaming experience. 🎮🔁

Note:remember to use the full scriptable object asset path es:“Assets/Gladio Games/Resources/GameData.asset”

ScriptableObjects give us a convenient way to decouple data from behavior. But when you have data distributed across ScriptableObjects and MonoBehaviours, you might find yourself clicking back and forth between them in the Unity editor. A neat solution to streamline this process is using Custom Inspectors. 🚀👀

Custom Inspectors in Unity allow you to customize how your scripts look in the Unity Inspector. When dealing with ScriptableObjects, this feature becomes a powerful tool that can help you visualize and edit your data right from the MonoBehaviour inspector. This section will guide you through creating a custom editor for your ScriptableObject.

Let's begin by understanding the essentials of creating a Custom Inspector:

Below is an example of a Custom Inspector for a ScriptableObject called NPCHealth. This code shows the MonoBehaviour's variables and also draws the ScriptableObject's inspector:

When you've set this up, you should be able to see the NPCHealth ScriptableObject's data directly in the MonoBehaviour that references it, making your data much more accessible! 🙌

Remember, the implementation of a custom editor might vary depending on the complexity of your ScriptableObject and the specific needs of your project. For more detailed guidance on custom editors, check out Unity's documentation on Custom Editors.

This following script from Tom Kail is an extension of how ScriptableObject references are displayed in the inspector. By default, Unity only shows you a single line with a reference to the ScriptableObject, but with this script, you'll see all properties of the ScriptableObject right there in the inspector when the object reference is not null.

⬇️ Download the script from GitHub

In order to persistently save changes made to ScriptableObjects during runtime, you'll need to Serialize then and then save the data into a file.

While ScriptableObjects themselves are not intended to be saved during runtime, they can serve as a reference for the data that needs to be saved and loaded.

Here's how you might approach it:

Let's say you have a ScriptableObject that tracks the state of a game character - their health, level, position, etc. While you play the game, you’ll change the scriptableObject data, but at some point during the game, you can decide to serialize and save the scriptable object data into a file.

Now to persist these changes, you would serialize this scriptable into a format suitable for storage. JSON and binary are common formats used for serialization. The JsonUtility.ToJson() method in Unity can be used for JSON serialization.

Once you have your serialized data, you can write it to a file on your user's disk using System.IO.File.WriteAllText() for JSON.

Then, when you want to load your data back into the game, you'd read the data from the file, deserialize it back into a class instance, and use that data to set the values of your ScriptableObject.

This approach lets you take advantage of the convenience of ScriptableObjects during development while still being able to persistently save and load data during runtime. It's a best-of-both-worlds solution! 💾🎮🔄

The following pattern and example have been taken from the Create modular game architecture in Unity with ScriptableObjects Ebook.

You can make this pattern more useful by defining the EnemyAI ScriptableObject as an abstract class. This allows it to act as a template for a variety of ScriptableObjects that are compatible with the EnemyUnit MonoBehaviour, so the abstract ScriptableObject can stand in for more than one algorithm.

Thus, you could have concrete ScriptableObject classes for behaviors like Patrol, Idle, or Flee that derive from the base EnemyAI. Even though they all implement the same MoveUnit method, each can produce very different results.

In the Editor, each asset is interchangeable. You can just drag and drop the ScriptableObject of choice into the EnemyAI field. Any compatible ScriptableObject is “pluggable” in this fashion.

The EnemyUnit or another component can behave as the “brain” that monitors when to switch ScriptableObjects and also swap behavior at runtime. This is one way the EnemyUnit can react to gameplay events. Simply switch EnemyAI ScriptableObjects on each state change.

In production, a second developer or designer can implement the actual movement or AI logic within the ScriptableObject. As additional movements or behaviors get added to the game (e.g., DuckAndCover, Chase, etc.), the original EnemyUnit script remains unchanged. This pattern can help keep your codebase more extensible, in keeping with the open-closed principle from SOLID programming. Because everything is already split into smaller objects, the resulting project is more scalable as you add team members.

Many developers opt to use singletons – one global instance of a class that survives scene loading. Singletons, however, introduce global states and make unit testing difficult.

If you’re working with a Prefab that references a singleton, you’ll end up importing all of its dependencies just to test an isolated function. This reduces modularity and debuggability.

Consider an alternate solution to help your objects communicate: ScriptableObject-based events.

In the observer design pattern, a subject broadcasts a message to one or more loosely decoupled observers. Each observing object can react independently of the subject but is unaware of the other observers. The subject can also be referred to as the “publisher” or “broadcaster.” The observers are also known as “subscribers” or “listeners.” An event-based architecture only executes when needed, rather than running each frame. For this reason, it’s often more optimized than adding logic to a MonoBehaviour’s update methods.

You can implement the observer pattern with MonoBehaviours or C# objects. While this is already common practice in Unity development, a script-only approach means your designers will rely on the programming team for every event needed during gameplay

An alternative is to create ScriptableObject-based events.

This is a designerfriendly way to set up the observer pattern. Here, the ScriptableObject works as an intermediary between subject and observer, providing a graphical interface in the Editor.

At runtime, you’ll often need to track a list of GameObjects or components in your scene. For example, you may need to maintain a list of enemies or NPCs.

Because a ScriptableObject instance appears at the project level, it can store data that’s available to any object from any scene.

Again, this replicates much of the easy global access of a singleton without that pattern’s known drawbacks. Reading data directly from a ScriptableObject is also more optimal than searching the Scene Hierarchy with a find operation such as.

Object.FindObjectOfType or GameObject.FindWithTag. Depending on your use case and the size of your hierarchy, these are relatively expensive methods that can be inefficient for per-frame updates.

Instead, consider storing data on a ScriptableObject as a “Runtime Set.” This is a specialized data container that maintains a public collection of elements but also provides basic methods to add and remove to the collection.

Here’s a basic Runtime Set that tracks a list of GameObjects:

Copy

using System.Collections.Generic;
using UnityEngine;
[CreateAssetMenu(menuName = "GameObject Runtime Set", fileName
= "GORuntimeSet")]
public class GameObjectRuntimeSetSO : ScriptableObject
{
private List<GameObject> items = new List<GameObject>();
public List<GameObject> Items => items;
public void Add(GameObject thingToAdd)
{
if (!items.Contains(thingToAdd))
items.Add(thingToAdd);
}
public void Remove(GameObject thingToRemove)
{
if (items.Contains(thingToRemove))
items.Remove(thingToRemove);
}
}

At runtime, any MonoBehaviour can reference the public Items property to obtain the full list. Another script or component must be responsible for managing how the GameObjects are added or removed from this list.

Reference the Runtime Set in a MonoBehaviour. Then, in the OnEnable and OnDisable event functions, add or remove the object from the Runtime Set’s Items list. Alternatively, use an event channel to send a GameObject as its payload (e.g., GameObjectEventChannel)

"In conclusion, ScriptableObjects in Unity offer a powerful 💪 and efficient way to handle data storage and manage state. They allow for modular design 🧩, ease of testing 🧪, and a clear separation of concerns, thereby improving the overall organization and structure of your game development project.

While they cannot entirely replace MonoBehaviours for direct scene interaction or use of Unity's lifecycle events, their persistent nature and lower memory usage make them an indispensable tool 🛠️ for managing game data. Remember, understanding when to use ScriptableObjects versus MonoBehaviours can significantly impact your project's performance and scalability. So keep exploring, keep learning, and happy coding! 👨‍💻🎮.

Marco Mignano 👋 ➡️ Passionate Unity Game Developer Marco - coding aficionado, video game enthusiast, and self-proclaimed piazza addict. Constantly conquering new challenges, one line of code at a time. Got an exciting project? Let's make your game next game together!

Contact: marco@gladiogames.com