1

Can anyone tell me about advantages/disadvantages of my approach?

I have status effects , skills as Scriptable Objects, with unique fields, that differs 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 for Object.Instantiate(ScriptableObject)? Because it will be used a lot this way in runtime (applying statuseffects in runtime = using Object.Instantiate).

I just hope, that using ScriptableObjects this way works the same as if they were simple Classes, the difference only is ability 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.

Ivan Ivanov
  • 11
  • 1
  • 4
  • Usually ScriptableObjects make more sense to be created in edit mode .. on runtime ... can't you simply use any simple class instead of a `ScriptableObject`? [This thread](https://forum.unity.com/threads/scriptableobject-createinstance-vs-instantiate.515757/) might be interesting – derHugo Aug 14 '19 at 08:39
  • Wow, thanks everyone for quick response. That's very unfortunate, actually, having to do more separation, I almost see no point in using SO's this way.. – Ivan Ivanov Aug 14 '19 at 08:49
  • And Object.Instantiate == GameObject.Instantiate? In terms of memory usage. – Ivan Ivanov Aug 14 '19 at 09:07
  • well both `ScriptableObject` and `GameObject` inherit from `Object`. However as said using Instantiate for a gameobject adds it to the Scene .. there might be more stuff going on in the background in that case but that's just a wild guess – derHugo Aug 14 '19 at 09:08
  • 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. – Ivan Ivanov Aug 14 '19 at 17:22
  • Any thoughts about that? – Ivan Ivanov Aug 14 '19 at 17:23
  • `Object.Instantiate === GameObject.Instantiate` they're literally the same function. – Draco18s no longer trusts SE Aug 14 '19 at 18:51
  • For anyone seeing this question, please check this link: https://forum.unity.com/threads/solved-unique-instances-of-scriptableobject-asset.440781/ – Paternostro Jun 24 '20 at 04:39

1 Answers1

0

SO - Scriptable Objects.

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.

Draco18s no longer trusts SE
  • 15,628
  • 3
  • 36
  • 56
Jack Mariani
  • 2,270
  • 1
  • 15
  • 30
  • And Object.Instantiate == GameObject.Instantiate? In terms of memory usage. – Ivan Ivanov Aug 14 '19 at 09:07
  • GameObject.Instantiate should not be used for SO. In terms of logic, if you apply them to a gameobject, they do the same thing. But Object.Instantiate returns an object, so it's likely you will need casting after that. Further info in [Object.Instantiate - Manual](https://docs.unity3d.com/ScriptReference/Object.Instantiate.html) and [prefab instatiation - manual](https://docs.unity3d.com/Manual/InstantiatingPrefabs.html). – Jack Mariani Aug 14 '19 at 10:01
  • Yes, I know, I meant that GameObject.Instantiate is expensive, and I thought maybe, Object.Instantiateay almost equal new Object () – Ivan Ivanov Aug 14 '19 at 10:08
  • if you use new Object() you won't initialize the GameObject properly. It requires to be Instantiated (or Object.Instantiate that does the same thing). – Jack Mariani Aug 14 '19 at 10:18
  • Thread was about using Object.Instantiane on SO and how its performance differs from c# copy constructor – Ivan Ivanov Aug 14 '19 at 10:21
  • In the comment you asked for a Object.iInstatiate == GameObject.Instantiate. I was answering that. If you mean to use GameObject.Instantiate for SO the coment has no much meaning. Gameobject.instantiate is not meant for SO. – Jack Mariani Aug 14 '19 at 10:50
  • 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. – Ivan Ivanov Aug 14 '19 at 17:22
  • Any thoughts about this? – Ivan Ivanov Aug 14 '19 at 17:22