Out of the box, it’s really difficult to instantiate ScriptableObjects when you’re using them as assets - you need to create or use custom editor code just for this purpose.Here are some issues I’d like to see addressed in the future regarding the ScriptableObjects: In short: You can use ScriptableObjects for storing shared data inside scenes, but currently it’s clumsy and you should use other means like data-only behaviours or ScriptableObjects stored as assets. compiling scripts while the game is running inside editor), but I guess they would work better than plain C# classes which simply get wiped out due to the serialization. If you want inspector for plain C# data structures, you need to implement a custom editor, which can be quite tedious.Īlso, I’m not sure how run-time ScriptableObjects behave during hot-loading (i.e. ScriptableObjects do have one slight advantage over plain C# classes for run-time, and that is support for inspector. It’s better to use plain C# classes for that. However, because if you only need something during run-time, you don’t need that data to be serialized and using ScriptableObject for that does very little sense. NOTE: You can spawn and use ScriptableObjects also run-time. However, this hasn’t been a real issue, as the number of these objects is usually very limited. They get a GameObject and Transform (and they’re spatial), which is a bit of a waste. You probably understand why I’m not using SSO’s □ Instead, I just create these specific data-only behaviours that I add to each scene. Nice thing about using ScriptableObjects in scenes is that you can later convert them into assets stored in the asset database, to be shared between scenes. The problems are mainly UI/access issues. So using ScriptableObjects for shared data inside scene files is far from optimal, but possible. And if you need more than one instances of same type of ScriptableObject, you’re in trouble. If you already duplicated the SOExampleBehaviour previously, you’ll now have two instances of SOExample laying around and Unity returns either one by random. I’m also using Object.Find() to find a single instance of a SOExample, but I have no way of knowing which instance I get. Notice that I added to OnEnable work every time I tick the enabled flag for the component. What we need first a the ScriptableObject to use: Why do I do this? Let’s first see how to use ScriptableObject that goes only in a scene file. For example if the each scene is a level in a game, I have a LevelInfo component that resides in a GameObject called “_levelInfo”. Usually I end up putting scene specific data into a single component in the scene in some GameObject. Having said that I haven’t used this feature much. You can also embed textures and meshes in scene files, many times by accident. Note: this same applies to any assets, not only ScriptableObjects. Let’s call these kind of ScriptableObjects by Scene ScriptableObjects (SSO’s □ ). But if ScriptableObject is NOT in the asset database, it actually gets serialized into the scene file. I guess many developers don’t know that they can actually instantiate ScriptableObjects and have them exist only in the scene. If ScriptableObject is referenced by the scene and stored as an asset in the asset database, only a reference to the asset is stored in the scene file. Scene Only, Pleaseīut what if you need to have shared data in the scene? You might not want to create assets for each data in each of the scene, as this makes the asset database cluttered with data only relevant to a certain scene. I usually have a GameDatabase asset which contains the global configurable parameters for the game. This data can be anything like lists of enemy prefab names, in-game shop configuration, list of chapters and levels in the game and their respective scene names etc. For example if you need team colors (red and blue) instead of sprinkling the colors to every possible component you can just have a reference to a TeamColor ScriptableObject and keep the color there – the same way you do with PhysicsMaterial for example. You can then reference this data from the components in the scene, and they all will share same values. A neat solution for persistent, config-kind-of-data is to put it in a custom ScriptableObject that then is saved to the asset database. (They really should do a blog post / tutorial / documentation about how to store your data, like a flow chart to decide where to put your data □ ) Common Data, Common ProblemĬommon problem is where to put data that you need to share between components. I’m not going to in the details - you should read the great blog post at Unit圓d.com about the serialization here. When you start developing with Unity, one of the basic thing you need to get your head around is the way Unity handles classes and data for your game.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |