Understanding Scriptable Objects

Hey guys, was hoping you could help enlighten me on the properties of scriptable objects! I found a good amount of documentation but still have a few key questions. First, when using CreateInstance does the new object created still reflect all changes to the original SO script? I was under the impression I could make changes, lets say to SO weapons in a character's inventory during play that was instantiated, then serialize things that would change such as durability while keeping things the same for instantiated SO's later? Also, im still hazy on serialization, so does Unity automatically serialize the parent object and clones or just the parent then uses that to recreate the clones during deserialization? I might be way off but thanks in advance for helping me understand this stuff!

 

One other thing: i won't have these weapons or items in the real world so I thought using Scriptable Objects, which from my understanding are just easily serializable data containers would be best

 

One last bump! I read a lot about SO's today and they seem to do what i think they should but id be a lot more comfortable if someone with more experience with them could weigh in on my understanding/usage of them so i dont end up having to redo everything down the line

 

A reference to a ScriptableObject can be one of two things: a reference to an asset on the disk, or a reference to an in-memory object. The latter object will cease to exist when Unity does an asset collection (which typically happens during scene transitions or when entering/exiting play mode), unless special hideFlags have been set on the object. The former, a representation of an asset on the disk, means that you're directly editing a file in your project and your changes are being written out to disk as you make them (more or less, there is some delay in the actual writing to disk).

If you have code that looks like

Code (csharp):

1. var myThing = ScriptableObject.CreateInstance<MyAwesomeClass>();

then your myThing variable is an in-memory instance of a MyAwesomeClass object. It wont have any changes saved, and will likely cease to exist when you exit play mode. Furthermore, in the above example, the myThing variable will be a brand new instance of the class. All of its variables will have their default values. Unity will not have filled out any data into any serialized fields (except for field initializers). This is because we created in the instance with CreateInstance<T>().

If, on the other hand, we Instantiated an existing object

Code (csharp):

1. var myInstance = Instantiate<MyAwesomeClass>(myThing);

now myInstance is a copy of myThing. Well, it is as much of a copy as Unity can provide. Unity can only fill out values that are serializable. Note that myInstance is still an in-memory object. So all of above about myThing being in-memory also applies to myInstance.

Now, if we load an asset from disk, we are able to make permanent changes. Consider

Code (csharp):

1. var myAsset = AssetDatabase.LoadAssetAtPath<MyAwesomeClass>( "Assets/Some/Path/Example.asset" );

Now myAsset is a reference to an on disk asset. Any changes made to a field of myAsset will persist, even when exiting play mode.

 

I'm sorry, I don't have any real answers for you, but have you seen the project:
TextAdventure: Creating a Text Based Adventure by Matthew-Schell
18 youtube vids, starting with

This project is pretty deep into Scriptable Objects. It's not trivial (in my opinion)
and does a real nice job of demo without getting overly bogged down a complex game.

 

Instanciated SO's are copies of the original. If you change an instance at runtime then it does not affect it's original. Serialization would be like you changing the original, and all the subsequent existing copies of it also getting updated.

Think of it like recipes versus real food. The recipe is the SO original, and the real food is the instance. You can order a big mac from the recipe menu, then splatter mustard all over it and it doesn't change the recipe.

In the runtime, changes to the original would only affect new copies, not existing ones.

 

Thanks kru for the in depth explanation, definitely crucial information, and ill check out those videos gwnguy! And LaneFox that is an amazing analogy, basically what i was guessing was happening so im stoked! Thanks guys, this was super helpful!