@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.
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.
Login
Register
By registering on this website you agree to our Privacy Policy.