Reputation: 11
Can anyone tell me about advantages/disadvantages of my approach?
I have status effects, skills as ScriptableObjects, with unique fields that differ for every in-game character (like duration, damage, castTime
, that all depends on individual Character Stats).
Moreover, I have most logic in them, that is just being controlled only with events in each object's StatusController
/SkillCastingController
.
So I came up with using:
Object.Instantiate(assigned shared ScriptableObject instance)
to have separate instances for everyone.
Is there a big memory cost to using Object.Instantiate(ScriptableObject)
? Because it will be used a lot this way in runtime (applying status effects in runtime = using Object.Instantiate
).
I just hope that using ScriptableObjects will work the same as if they were simple classes, with the only difference is being able to create and edit them in editor.
And if this assumption is true:
Object.Instantiate(assigned in inspector StatusEffect/Skill ScriptableObject)
is the same as creating new instance of simple class with copy constructor:
new StatusEffect(statuseffects[0]/Skills[0]).
If this is true - there shouldn't be a lot of memory usage, right?
Quote from professional, any thoughts?:
SO are simply a class made for data that have handy implications within Unity's serialization. If you are creating a run-time instance of the SO, which is a common pattern for ensuring run-time read-only, you are simply just duplicating the root ScriptableObject's memory. Because Object.Instantiate does not implicitly duplicate any sub-assets, which if they are referenced by the root, the clone will maintain a reference to the original Scriptable Object's sub-assets. Unless these ScriptableObjects allocate a massive amount of memory, the adverse effects of duplication should be nominal.
Upvotes: 1
Views: 9897
Reputation: 2408
Creating SO is consuming much more memory than creating a class, and most usually if you're instantiating them during play mode is much better to simple instantiate a class, so you get rid of most of SO overhead.
In general SO are best suited to be created in editor mode BEFORE play.
For a deeper understanding of SO, and to find the best strategy between SO vs GameObject you may also read this question.
Upvotes: 1