- Home /
Need opinions on handling Scriptable Objects
Hello everyone, I've been working on an Item system for my game. I'm using MonoBehaviours to represent items in the world space, and Scriptable Objects to hold the item data. The MonoBehaviours holds a reference to the Scriptable Object, or Item. The item class has children, such as weapon, consumable, and so on. Now, some items, such as 'scrap' for instance, will never have its values changed, since it's just a common generic item. On the other hand, a weapon will have condition (broken/working), magazines with different bullet ammounts, etc...
Right now, I'm instantiating every SO once they are in world, which works for my approach of having same items with different properties, but it just seems like it defeats the purpose of SOs, since they will all hold memory anyways. Can anyone PLEASE give me some input on this? I don't want to keep working on one of the main systems of the project and later have to refactor it all. Not expecting any answers but worth a shot! Thanks in advance
I've also thought of instantiating only the items that might eventually be modified, but if someone could suggest something better...
Answer by FlaSh-G · Feb 11 at 06:16 PM
Heyo!
Quick general note: For discussions and opinions, you're likely to have more luck in the forums, as Unity Answers is for... well... answers to questions. I'll answer anyway :)
ScriptableObjects have one thing to offer for you, and that is that they're UnityEngine.Objects that you can freely create and serialize in the editor. For example, but not exclusively, into your assets. Thus, you can use ScriptableObjects to define data (like item stats) in the editor and have them moved over to your build. A ScriptableObject that is created at runtime does not do this and thus does not have any sort of advantage over a plain ol' C# object. The only thing a ScriptableObject that you create during runtime will do is make garbage collection more annoying, as it exists both in C# land and in C++ land, as all UnityEngine.Objects do.
Because of all that, it's common practice to not use ScriptableObjects like regular objects. Most types of SOs in the wild are immutable data containers, like the static description of an item class. An instance of that item, when generated during the course of the game, would not be represented by an SO. But the item instance object can of course keep a reference to its item class SO in order to have it store the static item data.
There's also the approach of only using the identity of an SO as the data, while having the SO contain dynamic data (see here, great talk). This approach uses the fact that you can drag-and-drop inject SOs into other objects rather than having important data serialized into them. But in this approach as well, the SO would not be created at runtime. It simply gives you no advantage.
Instead, just create regular C# objects if game design dictates that an object is created during runtime. Feel free to have all sword instances reference the "sword class" SO that contains some common data for all swords that a designer can set up in the editor.
Your answer
Follow this Question
Related Questions
Need some advice for my inventory system 0 Answers
How to Instantiate objects that are Scriptable Objects 0 Answers
Scriptableobject List and Instantiating objects from it 3 Answers
A scriptable object for each variable, or one containing all those specific variables together? 0 Answers
Saving my Equipment Slots 1 Answer