One of the main use cases for ScriptableObjects is to reduce your Project’s memory usage by avoiding copies of values. Call one method (here the SaveGuiDRef) from "External Reference Resolver" (the methods which realize the IExternalStringReferenceResolver or IExternalGuidReferenceResolver interface) which for every element from the list get the GuiD of asset and store it in the separate file.A ScriptableObject is a data container that you can use to save large amounts of data, independent of class instances. Call Save and receive the file with references to assets and List unityReferences which contains list of these assets.The procedure of Store contains 2 steps (the Load will use the antiwise sequence of steps)):.The object to store is GameSettingsSO (described in my first post here).The TeamSirenix made the good products, but not very clear documentations (the procedure partially described on they GitHub TeamSirenix and partially on they tutorials External Reference Resolver, below I put the compilation from these sources, because a part of the original code contains many small weird errors): In this case to store this Type objects (in Runtime especial) must be used any workarounds described in this thread by and to be completely honest, if you want store this Type objects in Editor you can use the Odin Serializer (free part software of Odin Inspector), which use the possibilities the methods of class AssetDatabase (UnityEditor namespace !!!). And doesn't give a possibility to detect the path of the loaded asset. ScriptableObject) with Type fields with reference to any Unity assets (include other ScriptableObject), especial in build of Game.īecause the current main API to work with assets in runtime is the methods of class Resources (UnityEngine namespace) which give only possibility to load asset based on known path to the asset. The current Unity architecture doesn't give a possibility to serialize any objects (instance of class) (e.g. That was an attempt to defend Unity and at the same time a rant why we still don't have the tools we need The individual solutions will be developed by the community / developers. We don't need a complicated and convoluted solution that tries to satisfy all needs and usually fail reaching that goal. So having basic tools to interact with the engine and its assets would be the best solution. Different games have vastly different save and load needs. It should not be stuck at a certain game type. Unity is supposed to be the "allround" solution for games. So loading a savegame does only partly load the original map). Most ready-to-use solutions have limitations or specific game types in mind (games like the old halflife actually store the whole bsp map with all dynamic changes in the save file. While I never really wanted a ready-to-use save and load solution from Unity like most other major engines may have, I prefer some simple basic features where we can build on top our own solutions. We have many tiny tools which all improve what we can do, but the above mentioned basic features are still missing in Unity. Likewise the SerializeReference attribute (which gives us a lot more flexibility) is only restricted to the serialization unit and can't be used for cross references. In order to be able to create a proper save system we simply need a way to identify assets stored in the asset database at runtime and we need a way to address those later. We now have the addressables system which is kind of a hack on top of the existing system. Though simply getting a GUID of an authored asset at runtime and looking up an asset based on that GUID would make it extremely easy to roll your own serialization. I guess it's quite difficult to change the current system to be actually useful for runtime serialization.ĭon't get me wrong, I would also love to see a better assetdatabase access at runtime. Instance IDs are not globally unique and are usually restricted to a single serialization unit (scene, perfab, asset). Though Unity's serialization system has grown quite "organically" over many years and it gets progressively harder to make radical changes.Īt runtime we only have instance IDs. Some json serializers do implement meta tags to store such information and technically that's of course possible. The json serialization does not include FileIDs since json itself does not have a concept for that. Unity uses YAML or it's custom binary asset format to store this information. A single serialization unit may also use local FileIDs to refer to other instances within the same serialization unit. So instances that are stored in the asset database. In the editor you only have asset references. It's essentially an editor feature for the authoring of your game. Click to expand.Well, Unity does not really have a proper representation of the AssetDatabase at runtime.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |