How can scriptable objects track data changes after building project?

In regards to this tutorial https://unity.com/how-to/architect-game-code-scriptable-objects#example-players-health-points,

from what I understand, as soon as your project is built, you are no longer able to save new values to scriptable objects, so how is it ever possible for variables to be used in this manner? Everywhere I read about this technique people are raving about how great of an architecture style it is, but it seems to break one of the most fundamental rules about scriptable objects in that once a project is built that they cannot be modified.

Here is a clip from a Unite conference that is also centered around this architecture plan:

I have encountered multiple issues with using singletons like the speaker in that video describes, so I would love to get to the bottom of how I can utilize scriptable objects like this.

 

They are just bags of predefined data. Generally predefined data is not changed.

You can always instantiate (clone) them and change those copies all you want.

If you change a scriptable object at runtime in the editor, it actually changes it on disk. This is by design and how Unity editor scripts can be so seamless.

 

New values can't be saved to disk. You can't use ScriptableObjects as some game save token system. That's not what they're designed for.

You can modify the values in the ScriptableObjects though, in memory. You can clone them, instantiate new ones, etc. You just can't modify the on disk versions of them. Just like you can't modify any on disk assets (prefabs, materials, etc). When the game stops and restarts all those assets are back at the built versions.

I don't know what rule you're talking about... nor how it's broken...

Think of ScriptableObjects the same way you might any other asset. A material, an animator, a prefab, a scene, etc etc etc. That's what/how they behave. ScriptableObject basically just allows you to define your own asset type, implement it, and create assets from it. Those assets can be saved to disk for building, or instantiated at runtime for in place use.

Lets give an example of their uses...

Lets say I have a game where I have a player avatar. On it there is a "movement script" and this movement script moves the character around at a certain speed, jumps a certain height, etc etc etc. There's a good 9 variables defined for all the ways the movement can be tweaked (speed, turn speed, jump speed, push speed, etc etc).

Now... lets say there are multiple avatar "skins" to choose from. They all have the same "speed" settings because the entire game is designed around those specific speeds... so we don't want that to change on all characters. BUT the model, animations, etc all have changed.

Well, now we have to go to each and every "movement script" for each and every prefab for each avatar and tweak the settings. If we decide to change any of them, we have to go to ALL of them.

OR

If we had the "movement settings" (a scriptableobject) defined as its own asset that got drag and dropped onto the "movement script". Well now we just have a single asset to change and all the avatars are updated.

Now imagine you had a character creation system... then when a player creates their avatar we just assign the "movement settings" to it.

Lets say you had classes of characters... well now you can just have "movement settings" assets for each individual class, a factory that picks that setting out of the collection, and assigns that.

All while making it super easy for a designer to just go into the folder where all the character settings are, and modify it through the inspector (rather than having to open some hard-coded factory class you have out there).

...

Or lets take this a step further.

Here is my configuration for a player in my game:


Note the "Default Movement Settings":


Now... why it's called "Default Movement Settings" is that when you pick up weapons, your characters speed/etc changes. For example here is my "Elephant Gun":


It has all sorts of things including how the animations work etc.

But you'll notice the "Override Movement Settings" and "Override Aim Movement Settings":


Using this when you equip the elephant gun, the movement script will utilize this override settings instead of the default settings.

 

@lordofduct

Thanks, one final question: can I have an instance called CurrentMoveMentSettings, which I pass:

• to a screen: it updates the current stats
• to the player: it needs to know how to move
• to the inventory: it can update the value based on what I'm carrying.

This instance would not be created programatically, such that it can be passed around by the designers.
Is this possible during production as well?
The reason is that I did stumble upon the notion that ScriptableObjects are impossible to change in production, but didn't found yet how it is not possible.