Using ScriptableObjects with Playmaker[SOLVED]

[Fat Pug Studio]

As noted in another topic, i made a neat system with hashtables, once i get the prefab name, it's easy to reference the appropriate hashtable containing that enemies HP, weapon, explosion prefab etc. I even made an almost universal template which i just need to put on the enemy and it will draw everything it needs on runtime. But, there are already so many hashtables (around 30) that it will probably be a pain to edit in a while, plus the inspector is getting laggy.

But!

Yesterday a friendly guy from twitter asked me why am i not using scriptableobjects for storing data? I've read about them before, and it's a really small page on unity api reference page, couldn't really care less. Then i got to watch this video from Unite '16 (it's really great, i recommend it -

and i've seen it's the perfect data container actually.

I'm looking to further simplify my current configuration, i've just started to dig a little deeper to find if i can use scriptableobjects better than hashtables, but i was wondering if some of you had experience in using scriptableobject AND playmaker and do you have a workflow you would recommend? What else can i do except get property and inherit stuff from it that would be useful?

By the way i've seen the global variables are actually stored in an asset container, as well as fsmtemplate

[Fat Pug Studio]

I read some more and wow, i'm amazed. I believe i can get the best of both worlds by using scriptable objects and playmaker, i'll post my current setup later, but i think it can be much better than getting the data out of hashtables for each enemy for example, i can make an enemy scriptable object with all the stuff i need and then inherit things i need and simply discard the rest and even make custom editors to simplify it.

The real question is does it make sense to use it with a basically well rounded system like Playmaker?

[jeanfabre]

Hi,

 Yes scriptable Object are cool, but they come with their flaw too, they create garbage Collection call and that's impacting perfs, with hickups now and then. So scriptable Object are good if you are only having a couple of them and they don't get destroyed and created inside the game loop.

If you know how to script, go ahead, they are indeed very powerful, however I myself use them very sparingly, and actually never use them for data containers, because they are impossible to debug as data sources outside the Editor. I always use either a proper database backend on a server or Xml so that even a game installed on the end user device can have its data extracted in a meaningfull way ( xml being stored in playerPrefs for example).

 Bye,

 Jean

[Fat Pug Studio]

Hi Jean,

thanks for the response. i would use them only as default data containers to pull data from them. As for saving, i can save data in whatever format i like once i get them from scriptable objects. Anyway, i'll be finishing this stuff with hashtables, but i believe scriptables are really way to go with playmaker. Sure, some scripting is needed, but everything can be drag and droppable with custom editor, that's what i like.

[jeanfabre]

Hi,

 Sure, ScriptableObjects are very good indeed for data container.

 Bye,

 Jean

[ArcanaAffinity]

Hi,

 Yes scriptable Object are cool, but they come with their flaw too, they create garbage Collection call and that's impacting perfs, with hickups now and then. So scriptable Object are good if you are only having a couple of them and they don't get destroyed and created inside the game loop.

If you know how to script, go ahead, they are indeed very powerful, however I myself use them very sparingly, and actually never use them for data containers, because they are impossible to debug as data sources outside the Editor. I always use either a proper database backend on a server or Xml so that even a game installed on the end user device can have its data extracted in a meaningfull way ( xml being stored in playerPrefs for example).

 Bye,

 Jean

Thanks for the info Jean.
Could you elaborate when and how do scriptableObjects occur GC?
I'm aware this comment is a bit old, but your input to scriptableObject is quite different from what I've personally heard from Ian of Unity Enterprise.
I once attended Unite 2017 where he gave a full talk about benefits of using scriptableObjects good for not only data containers but also game logic and such with precise performance checks.

[stvbabb]

I'd be curious about this as well and even how they are used together best with playmaker.

[jeanfabre]

Hi,

 basically, a ScriptableObject is an asset, and as such should be dealt with carefully in dynamic code, for example, creating new scriptableObject at runtime. If your scriptableObject are created during editing, fine. but at runtime, it will need to be managed very carefully to avoid memory leaks as you need to manually destroy and unload them, which has an impact on perfs.

More infos here:

https://forum.unity.com/threads/scriptableobject-vs-plain-c-class.328325/


As for feedback from Unity developers, if they tell you it's ok to use, then you should of course , I do use them a lot, but I am very careful about it nonetheless. But for logic,PlayMaker will not be able to work, only c#, so in our cases, it would be just for Data.


 Bye,

 Jean

[ArcanaAffinity]

Hi,

 basically, a ScriptableObject is an asset, and as such should be dealt with carefully in dynamic code, for example, creating new scriptableObject at runtime. If your scriptableObject are created during editing, fine. but at runtime, it will need to be managed very carefully to avoid memory leaks as you need to manually destroy and unload them, which has an impact on perfs.

More infos here:

https://forum.unity.com/threads/scriptableobject-vs-plain-c-class.328325/


As for feedback from Unity developers, if they tell you it's ok to use, then you should of course , I do use them a lot, but I am very careful about it nonetheless. But for logic,PlayMaker will not be able to work, only c#, so in our cases, it would be just for Data.


 Bye,

 Jean

Understood and noted.
Thanks for quick response.
I don't have any experience generating any ScriptableObject at runtime, but this is still a good note.

My AIs have logics contained as ScriptableObjects and a controller monobehaviour class doing the FSM in hard-code, so I guess if I'd want to utilize those logic containers I already have I should only have Playmaker FSM manipulate the controller class not try to initiate the logics in ScriptableObject.