Discussion Just One ScriptableObject per Script

I have an interesting problem in hand and I would love to learn everyone's thoughts on this topic.

There are many at time I have to create scriptable object scripts where it ends up being just one object per script. A good example was a card game where I had to script custom functionality on reveal such that each card is unique, but still needed reference from the editor like sprite, name, mana cost etc.

In this case, by making it a scriptableobject, I can create multiple variants, but I don't have a need for that and just need something simple. Just one scriptable object is all I need.

So, when I do create these scripts, it's pretty annoying to create a scriptable object everytime, navigate elsewhere and set the references.

What is a solution to this problem? I feel like a new type of of scriptable object is needed where the object is script and the script is the object, simplifying the whole lot.

Anyone who has worked on a similar problem, please share your thoughts.

 

You can always attach multiple scriptable objects to a list, and then use this list throughout the code to refer to specifics. Or you can load your scriptable objects dynamically, to same effect. You can also dynamically load a scriptable object only when it's needed, by its name. Or you can allocate them in advance, then refer to them by their names.

There is some confusion within your post, so I have to make sure we're on the same page here. A scriptable object is a simple YAML file that describes some fields that are natively-serialized by Unity. Nothing special about it, you can achieve the same thing with a txt or JSON, or XML, but you'd have to write your own parser to handle deserialization (aka the conversion into runtime data). In case of SOs YAML serialization is automatic + you get a read/write editor for the fields + you can also include some elementary code to ease integration (this is why it's called SCRIPTABLE object, and not just object).

That said, you can make an SO that already has EVERY card that you need. Or an SO that refers to only one part of the card's anatomy. There are basically zero limitations, it's all how you design your own system around the concept of it.

SciptableObjects are basically just MonoBehaviours with their wings cut off, laid down like bricks. The way Unity handles them internally is incredibly similar, except the part where you run updates on them. They are clever because they reuse the existing Unity infrastructure and help you deliver custom serialized data just like MBs do, and you can still automate certain aspects, however they don't overburden the system with extra stuff.

 

OP, are you designing your cards by having a base type, and having every different card be a derived type? That's definitely not going to scale very well.

Really a case where you should look at SerializeReference and custom inspectors.

 

For your problem multiple project and/or inspector views could be helpful as well. You also can lock the views so they won't change when select other objects. And you can filter for SOs in general or class names in folders with t:name . You alos can save your custom Editor Layouts and switch between different layout in the top left corner of the Unity editor.