Danger in Instantiating ScriptableObjects?

Scripting
1

Hi,

i have several kind of simple questions but i cant for the love of anything find proper awnsers.
So here it goes:

  • is it ok to Instantiate SOs?
  • if i Instantiate a SO, and assign it to a Reference of a Monobehaviour that is in a Scene, do i dirty that scene/need to save it (even after Playmode)?

I enjoy the convinent use of ScriptableObjects in the Editor, i would like to use it to build “AbilityChains” for a StateMashine for my player. Example Press Q → Fires Skill A, Skill A consist of the followin Chain “Jump, Attack”

Now in this particular AbilityChain, some characters would be able to Modify the “Jump” or the “Attack” part with +50% more Jump etc etc. This is a State modification of the SO and that would mean that everyone would jump higher. To avoid this i want to Instantiate the SOs and keep the modification isolated in the SO, without affecting others.

BUT… i hear horrible things about this, its nearly as bad as the usage of a “goto” it seems.

I do have a proper Solution to this, but its more work ( like wraper Classes)

2

Yes.

I don’t really understand what you’re trying to do. You can instantiate SO in runtime (so you won’t save your scene) or in edit mode, then it will be an asset in the project so you can assign it in the inspector and you will need to save the scene.

? What? Where do you hear horrible things and what those ‘horrible things’ are?
It’s completely okay to instantiate SOs and assign them even in runtime. They are just instantiated classes with some extra magic methods and behave like assets.

3

From your described use case I’d lean towards having the character controller pass relevant bonuses to the attack function so your scriptable stays the same and you don’t incur any memory costs.

4

If you don’t mutate state on your SOs there is no need to instance them