Suggestion: Prefab Variants for any Object (ScriptableObject Variants)

In my game, I have a bunch of settings ScriptableObjects that I use to specify different values for an objects in my game. What I'd like to be able to do is make a new settings object, and only override certain settings, so the rest stay in sync with the original settings object. With prefab variants, this is now possible, but my settings objects need to have an accompanying GameObject, which is not ideal. It makes it clunky to load these settings objects, because I can no longer load them by type, and instead I need to store a reference to them somewhere.

So what I'd really like is if Prefab Variants were generalised to work on any UnityEngine.Object, so I can make a variant of any asset I like. Mostly I'd use this for ScriptableObjects, but I'm sure there's bound to be other uses for this too.

Thanks for reading.

 

+1

Similar use case in my project:
I made an AI system where I define a behavioural structure of a CP by a collection of traits (Actions they can choose to take), and a few general levers, such as simulated reaction time.



I can define different AI difficulty levels or create different behaviours for different game modes by changing the reaction time or values used by each trait to decide whether to choose it at a certain time. But I need to create an asset for each difficulty setting that may very well only differ by a single value being changed (Such as the reaction time), and that means that every time I want to change the basic balance of the core AI, I need to make sure to do it on all difficulty levels separately.

Would be awesome to have the ability to use variants here.

 

Same here. I make database using scriptable objects, and I want to be able to make some elements to be variants of others. Using prefabs for such things makes it much more complicated, also that way I can't store whole database as single object anymore. Plus it's still pretty bugged right now and link to prefabs get broken all the time.

 

+1

I've managed to build something like this myself, but it would be incredibly rad if there was a feature like this, since my implementation leaves much to be desired

 

Unsurprising, that makes a lot of sense.

 

That's a shame, really. I got used to having inheritance of configs when modding games like Stalker, Max Payne, etc. It seems like a standard tool in game development. Now I see only 2 options to solve this:
- Use clunky MonoBehaviors for configs and put them in prefabs/variants (a hack at best)
- Don't use ScriptableObjects at all for configs instead using some kind of INI or YAML format with inheritance/overriding support. Which is also a big shame, you'll lose all the awesome editor inspector functionality and the already existing mechanics of overriding properties of serialized objects

@SteenLund if you focus on just providing variants for ScriptableObjects would that still be too burdensome to implement? From a user stand point, it feels like a natural next step because you already have the mechanism & UI for overriding serialized fields in objects.

 

Here's something that is quite similar:
https://assetstore.unity.com/packages/tools/utilities/datablocks-33587

I also have something like this as well. It's integrated into my project and it requires Odin serializer, but I may throw it on github at some point:

 

I also made similiar thing with Odin (just inspector part, serializer not required) for my database scripts, but I made it more like Unity's nested prefabs style - it overrides everything you modify and shows it with small blue line on the side, and you can revert it from context menu. Makes much less space than this toggle style (I made it toggle style just like this at first)

 

Sounds super cool! I also am just using the inspector part, not the serializer. I could try to rip it out at some point xD And yeah I personally like having more fidelity with what is overridden and what is not, but I may try out the prefab editor approach, maybe it'll work out

 

Looks exactly like prefab variants in principle. How exactly are those sub-configs are serialized? Do you have a generic mechanism for overriding any type of config or is it just a custom set of Nullable properties for specific type of config?

 

Each field is a Parameter<T>, where T is the type of field. That parameter class contains the serialized value, as well as a bool "isSet". It also has the functions Get() and Set(), as well as a reference to the parent object, which is initialized during startup. Get() will either return its personal value if "isSet" is true, and will otherwise return the parent object's value.

 

In my case, I made a script that apply attribute "Parented" to all drawers inside database class' editor. This attribute's drawer add override highlighting and "revert" context menu. Also it calls database's method that sync values between entries. That method, in normal Unity's terms, makes SerializedObjects for each database entries, and then copies NOT overridden values from one entry to another. Well, I actually use Odin's ProprtyTrees there, but they work similiar to SerializedObjects.

 

I'm sorry to necro this old thread, but that's all I've found regarding this topic which I think is really interesting.

@joshcamas , @GamerXP Do you guys mind shedding a bit more light on the idea? There is something I don't understand, in both your examples the "parent", as well as which fields are actually overridden still need to be serialized, correct?

Thanks a ton!

 

Yes, it serializes all data like normal + additional override flags. Some editor script read those override flags and sync data based on parent-child relations.

It's even possible to remove those flags from final build since they are for data sync purpose only. You can't do that with #if UNITY_EDITOR though since game will, most likely, crash.

 

Ok cool thanks a lot, that makes sense.
If I understand correctly, the flags are added inside the custom odin attribute, right?

If I get something usable I will try to push it to github.

Thanks

 

Hei, I came up with an implementation, everything is working, although some stuff might be a bit shaky:
https://github.com/GieziJo/ScriptableObjectVariant

I managed to save the data of the override + parent in the .meta file using `AssetImporter.GetAtPath(AssetDatabase.GetAssetPath(targetObject)).userData`, which works well but might be an issue if another script stores data there.

The whole thing works by just adding the attribute 'Parent' to any `ScriptableObject`.

I'm not a huge fan of how I implemented the attribute part (basically a check for all ScriptableObject types if they have the attribute), so I'm definitely open to suggestions

Thanks for the ideas, definitely helped!

 

Saving in meta file sounds like a good idea. I don't think it will be a problem since only custom classes can implement that, so it can't conflict with plugins. Though, performance may be not that good if it reads and writes it all the time?
Implementing it with interface may be an option as well - this saving/loading will be a bit less painful.

*looks at gif*
I did with checkboxes at first as well, but rewrote it later - the way prefab variants are implemented feels better. Why won't you try doing it the same way?
1. It overrides automatically any field that changes from user's input
2. There is a context menu for each field that adds "Revert" option
3. It shows small blue rectangle at the left side of the field if it's overridden.

 

Thanks for the feedback

I think performance wise it's not too bad from a read and write perspective for override and parent data:
- data gets only read once, and then a null check on some properties reloads them when they get lost (unity reloading or recompiling or whatever)
- data gets saved when 1) a new parent is set, 2) when the object gets deselected <- this is probably not fool proof but I haven't seen any problems until now (would make more sense to have it when the rest of the asset gets serialized but there is no delegate for that as far as I know).

The rest of the SO data gets written and read from as normal.

I'm not sure how this would be done with an interface, but wouldn't you then loose the advantage of having this as an attribute which is completely ignored at compilation? Here everything only happens in the editor, and the actual SO is modified, the references to the parent and overridden fields don't exist once compiled.

Yes obviously the way unity handles prefab variants is a lot better, but also in the case of data it's, imo, a bit harder to get in one view what's original and what's overridden. And I honestly have no idea how I would go about the window they add to have an overview of the overridden fields.

I've done some modifications, the checkbox is now on the left, and I've added as a reference the value of the parent next to the field when it's overridden.



Honestly, except for the issues I mention on the git page, UI-wise I think this fits my needs pretty well, so I might leave it at that

One bigger issue imo is that when you modify fields in the original, the data gets not propagated to the variants directly. You have to select the individual variants which then get updated (this time automatically, as they get checked on activation). This could be solved if there was a way to capture "OnValueChanged" in the "FieldInfo" but I haven't found anything in that direction for now.

 

BTW, did you check if it works with arrays and SerializedReference multi-type fields? I had to do some special checks for those.

 

Thanks, you were right! The lists and arrays had some issues, they kept the reference to the parent field and would modify the original instead of just a copy.
I solved this by checking, for IEnumerable, if the object is the same, and if the case, making a copy via serialization and deserialization. Seems to work:

Code (CSharp):

1. // handle copy of list/arrays
2. if (typeof(IEnumerable).IsAssignableFrom(targetFieldInfo.FieldType) && targetFieldInfo.GetValue(Attribute.Target) == parentFieldInfo.GetValue(Attribute.Parent))
3. {
4.     object parentObject = parentFieldInfo.GetValue(Attribute.Parent);
5.     byte[] parentAsData = SerializationUtility.SerializeValueWeak(parentObject, DataFormat.Binary);
6.     object parentObjectCopy = SerializationUtility.DeserializeValueWeak(parentAsData, DataFormat.Binary);
7.     targetFieldInfo.SetValue(Attribute.Target, parentObjectCopy);
8. }

I'm not sure what you mean by "SerializedReference multi-type fields", could you give an example? thanks

Also, I implemented propagation of values to children.

 

I mean things like this:

[SerializeReference]
public IYourInterface Field;

This field can be of any type derived from IYourInterface. This is also true for [OdinSerialize] fields.

 

hi from 2022, now we have material Variants. And we on half-road from ScriptableObject Variants. I supose it's the SubAsset system. You can save ScriptableObject inside other ScriptableObject, but you can't save Material under Material. If someone realy need ScriptableObject Variant - you can use MonoBehaviour + Prefabs as alternative. Override fully functional, and you also have same file-based nature. You have no some other features, such as Json-conversation. But in conext of ScriptableObjects Variants it works

 

SerializeReference is gorgeus, BUT: change namespace or class name will brake your data. MonoBehaviour/ScriptableObjects have no this refactor-stopping disadvantage

 

That's just how serialization works. It's the same for any class reference or field reference as well

 

@mitaywalle the
MovedFromAttribute helps with renaming without breaking SerializeReference-- super handy. (https://github.com/Unity-Technologi...Scripting/APIUpdating/UpdatedFromAttribute.cs)

 

Thank you, good to know tha it exist

 

I've just released Asset Variants, which allows (almost) any asset to be a variant of any other asset (polymorphic or even entirely unrelated types are allowed; anything in common can be copied over), without requiring Odin Inspector. The main use case is ScriptableObjects and Materials, but almost any asset works out of the box:
https://forum.unity.com/threads/asset-variants.1310693/

Every collection (aside from HashSet) has a size override button, which is the .Array.size of regular Unity serialized Arrays/Lists. For Odin serialized collections, the size path is a "fake" path:
- For Dictionaries, the size override means you can add new keys, or remove old keys; The override button for the value of a KeyValuePair allows you to change the value, but unless the size is overridden the keys must stay the same.
- Stacks/Queues and Odin serialized Lists/Arrays work like changing the .Array.size value of a Unity serialized Array/List (even though there is no such InspectorProperty in the PropertyTree).
- HashSets can only be overridden as a whole

 

Since then you guys have figured out Material Variants. Can we get same thing but for sciptable objects now?

 

Bump, same question

 

big bump as well!

 

Bumpidy bump + 1 + 10000

 

Scriptable object variants would be greatest thing ever for game data handling