Slate Forums › Support › Animate Properties of Scriptable Objects
Hello.
Wanted to ask if it would be possible to implement animation of ScriptableObjects’ properties ?
Im working a lot with them, and it would be really cool. I can easily do that in flowcanvas, but in Slate, I can only reference GameObjects & Prefabs, right ? Can I implement this myself easily maybe?
Thank you in advance very much 🙂
David
Hello again David and sorry for the late reply!
Just to clarify, do you mean animating scriptable object assets themselves, or instances of scriptable objects?
The former (assets) could be possible if I change a few things first of course, but the later (instances) might need a bit more work.
Can you please clarify and/or provide an example? 🙂
Thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Hello Galvakis. No prob, I know you have are busy 🙂 I mean Instances of Scriptable Objects. The fields/properties of instances of scriptable objects.
Imagine for example an instance of an item ( for example a healtpack ). It may have a price tag as a public field or as a property. In flowcanvas i could easily reference that object ( either drag n drop or a graphvariable ). then I could do with the price-variable whatever I want.
Animating price usually doesnt really make sense in a cutsene, I know, but it is just an example for clarification.
I’m just a little confused now, because as I thought until now, was that instances of Scriptable Objects ARE assets.
Thank you Dave.
Sorry for the confusion :). I was just referring to runtime “floating” instances versus persistent assets. Although most of the time ScriptableObjects are used for assets, as you may know it is also possible to instantiate ScriptableObjects in runtime without creating/saving that instance as an asset, but in the context of your question that wouldn’t make any sense :P. Sorry.
With that said, because right now Actor Groups work with a Gameobject type reference, it is not possible to control a ScriptableObject instance, but I think that with a few changes into making Actor Groups work with an Object type instead, your suggestion could very well be possible.
I will take a look into this and see if such a change would impose any issues in the rest of the framework and if not, I will make it happen 🙂
Thank you!
Join us on Discord: https://discord.gg/97q2Rjh
That change would be interesting to us as well, since most of our data is in ScriptableObjects
One thing to notice is that ScriptableObjects are persistent (in this context), so any changes done to them would need to be undone when stopping playback.
@Gavalakis thanks for having a look into this. On my side, its not a gamebreaker if its not possible. When needed. there are workarounds. But it would be quite nice to have the abilty to do it directly.
@sugoidev
Hi.
A simple way to undo the changes is to let the object initialize a runtime-copy of itself in onAwake and work only on the copied data during runtime.
@dave Hi!
If you instantiate a runtime copy of it, the objects that use the asset won’t know about it, will they?
For example, let’s say you have a SO with a single float a few other objects use. If you animate the float in the copy, none of your objects using the original SO will be seeing the new values, they’ll still be seeing the old value stored in the original asset.
One possible way to workaround this would be creating a copy, then working on the original, then, when done, put the data from the copy in the original.
@sugoidev.
Sorry, expressed my self not well.
Your approach is right. I just dont like about it is that the onDisable method in SOs is not called at the end of playing the game in the editor, but right at the start of playing it again (Hit Play -> OnDisable() -> OnEnable()). So youre working with values which will be reset right after you hit play.
The other approach that I tried to mention is this ( let me make a citation ):
roboryantronJanuary 12, 2018 at 8:56 AM
There should be no need to reset on playmode stop if you operate on a RuntimeValue that is explicitly non-serialized.
I would have Value or InitialValue be the serialized data that you change in the inspector. When the game starts (something like ISerializationCallbackReciever.OnAfterDeserialize), copy InitialValue into the nonserialized RuntimeValue.
If you operate on RuntimeValue it should not get saved to disk.
You can find it at
http://www.roboryantron.com/2017/10/unite-2017-game-architecture-with.html
He’s talking about his System which i was very excited in this spring. I dived in and tried it out, adapted stuff and experimented with it. If you havent you really should watch his talk. He uses SOs in quite a cool way. The quote is about his approach for Variables ( He uses SOs for single shared variables , a SO could be a float for example, maybe a health float or something like that. He gets rid of Singletons with his approach )
And its quite cool to have in the toolbox. I have this system adapted to my needs and can use it whenever i need it. Also makes prototyping faster in some regards. But there are also some cons.
Oh yeah, that’s exactly my approach!
But this case of ours is special, since we are dealing with SO in a specific (and very cool) way.
I even have a little inspector for those FloatValue, IntValue, etc
It’s pretty cool. I hope more people begin using these ideas!