Prefab's as ScriptableObject's on steroids

ScriptableObject's are great to store all sorts of data. There are good talks available if you're not familiar with it, here is one of my favorites:

Spoiler: Unite 2016 - Overthrowing the MonoBehaviour Tyranny in a Glorious Scriptable Object Revolution

I've used ScriptableObject's for years, it's a genius invention.

However, in pretty much every project we ended up to implement a Component-like system for ScriptableObject eventually. The idea is have a SO that acts as container for other SO's.

We called the container "Config" and the components "Modules", to not confuse with Unity Components. Means this system is similar to how a GameObject acts as container for Component/MonoBehaviour.

The purpose of having those SO modules was to be able to group data without affecting the code maintainability in terms of monolithic ScriptableObject .cs files.

Rather than having a single ScriptableObject .cs file that contains everything for a specific feature, such as an Enemy, there would exist a Config for the Enemy and several modules added to the Config provide the specific data.

One module could be "balancing stats" including things such as health, another module could be what skills the Enemy can execute, another module could be how the Enemy appears in the UI, and so on. You get the idea. HUD related code doesn't have to care about the "balancing stats" module and can just query the UI module for example.

However, at another point you realize all this is great, but you also need a template-like system. Basically a system to derive from another ScriptableObject, inherit all its values and allow to override them. Unity's prefab variant system basically.

In more recent projects, since nested prefabs arrived, I've used Prefabs rather than ScriptableObject's as data containers.

The GameObject acts as the container and the Components represent the data, which previously was the "SO module". Using the Prefab system for that also allows to use its variant system, to get template-functionality for free. These "data prefabs" are kept in the project folder, just like a ScriptableObject would be.

From a coding point of view, not much changed. Rather than accessing the SO, you access the GameObject and use GetComponent to get your hands on the data, where the Component is what previously was represented by a ScriptableObject.


Has anyone else used prefabs as data containers too? What are your thoughts on it?

 

SO's are nice for some systems data. For example...I am currently using SO's to define all the properties of each of the Chemical Elements and some 100 of the most interesting isotopes. I had tried to start similar before but having to write over 200 separate C# scripts to separate the data was a big hassle. The SO's allowed me to have one type of script and hundreds of variants on the data. I do use these to drive components and some store the data from the SO's. I also use them for weapons and subatomic species. Anyplace where i have alot of similar but slightly different data.

 

I just came across an article called "Using Unity Prefabs and GameObjects only for data.", which is discussing this topic in more detail:

https://blog.gemserk.com/2020/05/26/using-unity-prefabs-and-gameobjects-only-for-data/

 

I really wish we could have SO variants like we have prefab variants

 

If we could remove the Transform from a GameObject, I guess that would be pretty much it

 

KINDA... what I really like about the SO is it's so removed from the code and other objects, it's just a completely light weight component that can hold any range of information of any type in any order without a bunch of random crap getting in the way. I find it a pain in the ass trying to group the correct variables together as various inheritances force your variables to be garbled.

I currently use prefab as data containers, each and every one of my enemies inherits from a core NPC, and then branch into archetypes. Which I would still use even if SO's were fully featured, the prefab system is awesome.

But what's so alluring about the scriptable object is you can so easily rearrange the order of the data, set it up with the most important types of data grouped at the top with other relevant variables effortlessly, and arrange it in a way that best suits you or your designers. You don't have your various points of tunable data scattered across a wide array of scripts and components within your entities.

Scriptable Objects are the perfect component to get designers to start getting their feet wet with code, and to start looking at things in a detail oriented sort of way. If they can lay out each and every point of data they might need in a script within a SO, and to group them intelligently, they will be taking their first steps towards being able to get in and actually start making some functional C#.

I started using SO's with the idea that i could have all the data in one place, but I no longer use them primarily, because you can't revert to default values, or create SO's that inherit as you've alluded to above, QA Jesus. Suppose I could code a system to do this, but it just seems a bit janky, I like the structure that the prefab system has and if anything ever really breaks i'm just a repository revert away from sanity again.

 

My use case is as a plugin developer, I have various SOs as configurations. It'd be nice if customers could create variants of the included configs, such that they get to change stuff as they want but don't go out of sync with additions

 

I also use ScriptableObjects to store data and have been wishing for a prefab-variant-like system for them as well. I'm resisting the idea of using Prefabs (perhaps somewhat irrationally) because it seems very hacky.

Yep! That's the exact situation where I was thinking that a variant-like concept might come in handy. Admittedly, you could achieve similar behaviour by making data objects more atomic/granular, but IMO that is only really practically feasible to a certain degree.

Considering that Unity is also occasionally adopting a ScriptableObject-config approach (like the ScriptableRenderPipelineAssets), perhaps they're considering creating a similar system for ScriptableObjects.