ocean glade
I've watched a few videos on using SOs for game architecture by storing variables and events in them. While that sounds great, we all know that SO instances do not reset their values after exiting playmode.
The problem i see here, is that everyone's git changelist will now be cluttered with those changed instance assets. For some reason, i've heard nobody talk about this, yet it bugs me immensly as i use git for all of my Unity projects, often in teams.
ebon robin
You do not use assets themselves if you don't want them changed. You instantiate SO and use that instance.
ocean glade
but dont we want to use assets, as this allows us to reference them without singletons?
serene pier
I've watched a few videos on using SOs for game architecture by storing variable...
theres way more flaws in using scriptable objects this way, but I don't think it really affects git like this. Wouldnt you usually have an object (whether in scene or prefab) that references a dedicated SO in order to reference a specific instance of that event? Another object would do the same for listening to the event.
This doesn't get serialized no matter if its a c# event or unityevent if you subscribe at runtime
the main problem here is that you would be creating an SO per event needed
ebon robin
but dont we want to use assets, as this allows us to reference them without sing...
You can also restore the state of the object on exit.
ocean glade
@ebon robin using a built in feature or by resetting it to some defaults i've stored elsewhere?
ebon robin
You can use Reset() to trigger on program exit, but you need to keep track of what's inside and don't forget to update it if changing something.
ocean glade
oh neat i didn't know that existed
serene pier
Ah I see, it was the variables, not specifically the events. Truthfully id still just call this an overuse of scriptable objects. You are modifying values in something thats intended to be used as immutable data. Any editor workaround here might just be annoying and break up the expected workflow of scriptable objects
One workaround you could use is creating a separate plain c# class which you modify values in instead of the SO
you could call Reset, but what if there are values the user actually wants to change?
ocean glade
You know what's funny, Unity used this techinque themselves in the first Open project
ebon robin
You would use SO here only if you want the comfort of configuring it as an asset with values.
ocean glade
honestly i just like working with asset references and not some runtime generated objects i cant see
ebon robin
Then yea, just keep in mind if you want mutable SO at runtime then reset it or instance it.
serene pier
You know what's funny, Unity used this techinque themselves in the first Open pr...
there was also some unity talk like 8 years back that people reference. i just find theres no purpose to it, the only thing this "solves" is avoiding getting a reference to another object properly. You still run into the issue of having an asset per event which is not good. if you run into a use case where you need a variable number of events, you cannot use this system as is. Suddenly you need to create instances of the asset at runtime and manage their lifecycle. These assets dont destroy themselves
if you end up creating instances of it, you also lose the core functionality of two things referencing the same asset through drag/drop. So it does get awkward