Weaknesses Scriptable Architecture

Below are the pain points I encountered while using scriptable architecture

1. Data stored runtime

• ScriptableObject stored data in runtime is the main source for inconsistencies between build and editor. The fact that scriptable data is not automatically reset when exiting play mode in editor (unity keeps playmode changes on ScriptableObject so when you do a build you might wrongly get those changes from your last playtest session) To avoid data inconsistency between plays on the editor we are forced to reset its state manually on import(Also it depends on using fast-enter-playmode / domain reload or not.). In foundation this problem has been resolved but there is still a risk that when people try to crtl + s right in playmode the data is still saved.

2. Scope

• It is difficult to determine the scope of a ScriptableObject like determining the scope of variables in regular C# classes. Which ScriptableObject will only be placed within the scope of a certain GameObject, used globally or in a certain scene or context? Currently I am using conventional names to identify them but obviously this is not a good way.

3. Copies of data when used with AssetBundle or Addresables

• ScriptableObject can be referenced for use in many different asset groups, each group will create a copy if the ScriptableObject is not addressed or exists directly in a certain group, in addition each scene is also considered is a group if the scene is included in SceneLists in Build Profiles. Having this copy will lead to unexpected behavior in the build (the ScriptableObject value changes but is changed on the copy). To fix this problem we need to remove the entire scene from SceneLists leaving only an empty scene to load into the Launcher scene, the other scenes are placed into specific Packed Assets, then used Use Analyze on version 1.x and Check for Content Update Restrictions on version 2.x of Addressable to group duplicate assets (used in many other groups) into a separate group. The true solution would be to have no runtime ScriptableObject. There is no benefit in Instantiating them at runtime. You should just have regular C# class has the same fields as the ScriptableObject and instead of instantiating the ScriptableObject you create this normal C# object and copy the fields over. this would be garbage collected completely fine.

4. Only destroyed when Unity calls garbage collection

• In case we need to instantiate a ScriptableObject at runtime (like a scriptable containing data shared by one type of enemy) because there are many enemies, we need to instantiate a single SciptableObject to ensure that each enemy's data changes differently. The Instantiate method is simple and easy to do, but it has risks. When ScriptableObjects are instantiated at runtime, we will not be able to manage them. It is difficult to determine when it will be destroyed (are there still any objects using the ScriptableObject we want to free?). Unfortunately, it's only when we switch scenes that these scriptableObjects are destroyed because Unity calls the garbage collector. For games like survial, for example, the gameplay session is very long and enemies are born and die continuously. Using instantiate for each enemy multiple times will cause a burden on RAM and lead to overheating.

5. Garbage Collector

• Sometimes there are ScriptableObjects that need to exist between different scenes to share data between the two scenes(something like dont destroy onload). But if there is no reference to them GC will remove them and sometimes lead to null reference to fix it we need to add DontUnloadUnusedAsset to the HideFlags to make sure you do not lose state if nothing is referencing it.

6. Quantity

• ScriptableObject grows like mushrooms after the rain. This gradually causes the project to swell and become difficult to control

Remember to always avoid overusing SciptableObject and relying entirely on it, it should be in its right place to resolve dependencies. It will still be used in foundation but it needs to change