koobas.hobune.stream
Why unity can't create/save asset (ScriptableObject ) at runtime ?
Unity can create asset (ScriptableObject ) by using AssetDatabase.SaveAssets() at editor script .
Why unity can't create/save asset (ScriptableObject ) at runtime(means in a build) ?
Is there technical difficulties or it been designed this way ?
If it's designed this way , why ?
Hi there @creay,
That is the intended behaviour, you cannot permanently add scriptable objects, or save / serialize them.
Here's a question similar to yours: http://answers.unity3d.com/questions/874590/scriptable-objects-not-working-after-being-built.html
If you look at the answer of Bunny, he explains how "When you create a build of your project all assets are packed into packages which can't be modified at all." and "A build can only read the packed assets."
So yes, it was designed that way. Perhaps unity would've opted to allow for asset creation at runtime, but that's probably not possible due to build packaging shenanigans that are inaccessible from the build itself.
I hope that helps, if you need any more details, let me know! :) (Note, since this question is in moderation at this point in time, I chose to try to answer your question via comments)
@ThePersister thanks for your answer, it's helpful.
Accroding to @Bunny83's answer "Only the Unity editor can actually serialize anything. Unity's serializer isn't available at runtime. A build can only read the packed assets."
It seems the deserializer is available at runtime but serializer isn't.
I still don't understand why it's designed this way, what's the benefit of it ,wouldn't it be better if deserializer and serializer both available at runtime ?
That does seem strange, I bet there are technical reasons for it.
For one, unity won't compile any build or serialization functionalities along with your game on its own, because that would explode the size of mobile builds!
Reasons like that.
Luckily, we can easily add our own serialization methods. One of which for example would be: http://answers.unity3d.com/questions/610893/how-do-i-save-a-custom-class-of-variables-to-playe.html
I'm currently working with scriptable objects as well. I plan to serialize the scriptable objects to binary data, and then simply save that binary data using for example the code in the link above.
There are several other ways to save data, this is just the way I'm headed. I hope that helps.
I suppose Unity designed it that way, so that it doesn't force functionalities, build size and other complexities upon you, but leaves it up to you to decide how you want to handle things!
I hope that satisfies your request. If you're interested in more details, you can always try mailing unity staff or checking out the "live training sessions" and asking it there.
Here's some unity Twitter accounts you can hunt down: 
Best of luck!
Cheers,
ThePersister
@ThePersister,Thanks for your answer,it's helpful.
According to @Bunny83 's answer : "Only the Unity editor can actually serialize anything. Unity's serializer isn't available at runtime. A build can only read the packed assets."
It seems that Unity deserializer is available at runtime,but serializer is not. I still don't understand why it's been designed this way, what's the benefit of it? Wouldn't it be better if serializer available at runtime?
We simply don't know the exact reason why, but some points might be:
The assets of a project are packed into resource files. Those aren't ment to be changed at runtime, only loaded. Basically everything that a build includes is read-only except files in seperate folders.
The Unity Editor uses a lot third party code, libraries, licenses. Some licenses have quite hard restrictions and can't be transferred to others. The Unity editor is a product of Unity Technologies and sold / licensed to us developers. If certain features would be included in the engine itself, some of those licenses would apply to us as well. That would require us as developer to also pay for that third party license. Since we only use the Unity editor as end-user it doesn't affect us.
Finally: size. A lot people already complain about the size of a unity build, especially on mobile. At the same time they want more and more features to be included in the engine. Every additional feature will increase the build size and since the engine's core is not modular, certain things can't or are difficult to strip from a build when they aren't used.
They have now included the JsonUtility class which can serialize almost the same things (with the same restrictions) as the serializer in the editor. However in a lot cases you might want to roll your own way of serializing / saving your gamestate.
Another reason why they would exclude certain things from a build is: If almost all features of the editor can be used at runtime, one could simply create an application like the Unity editor and allow others in turn to create almost the same things as with the Unity editor but without applying to the terms of the Unity editor. I think that's actually one of the most important points as seen from UT.
Pretty much every engine out there has similar restrictions. The engine isn't capable of creating texture / model / audio assets but is able to read them. Often other tools are needed to create such assets. Show me an engine that is able to create assets at runtime? For example "Source" formats like VTX, VTF, $$anonymous$$DL, BSP, $$anonymous$$AP, ... all those need specialized programs to create them.
Excellent answer @Bunny83,
Thanks for the extra details, help me learn a bit more as well! :)
