A note on the persistency state of Scriptable Objects

Just a reminder: now that we are all aware of the usefulness of Scriptable Objects for configuration and state

we may get confused about their persistent scope.

So for scriptable objects that are assets: suppose you have a Coach scriptable object asset that has a variable representing his relationship with the press, PressRelationship. Suppose the possible values are GOOD, SO-SO, BAD.

On editor, you set it to PressRelationship=GOOD.

You run in the editor, set it to PressRelationship=SO-SO in code or by changing it by hand, stop the editor ->PressRelationship latest runtime value will be preserved, so it will be SO-SO.

You reset the value by hand to GOOD in the editor. Then you build the application, you run the game. At startup the value will be GOOD, then you set it to PressRelationship=SO-SO via runtime code. You stop the app; the next time you run it, the initial value will be GOOD again, not SO-SO. Ok?
This is the crucial difference:

A. Values set in any way in the editor, by hand or via code, at runtime or not, are preserved and saved in the asset.

B. Values set at runtime in the build are *not* preserved and saved in the asset.

This means that you may need a “setup” method that fixes the starting values for properties in the scriptable object that you are exposing in the editor but that you don’t actually want to be changed from there — or better, just don’t expose those.

Note also that any change to the scriptable object even in the build will be preserved across scenes, so that if your game has a “play again” button, you will need to relaunch the setup methods of the scriptable objects.

P.S. As noted on Twitter (but see the full thread):

I do that too when nothing of it is something I want to be configured in the editor nor persisted in it, like the match play state in my football game. Its nice because it can be inspected in editor panels anyway to debug :-)