![]() ![]() That data can then be loaded into a generic enemy object that then reads the data and adjusts settings as needed. The values of the fields can be adjusted for the new enemy… Instead if all the design data for the enemy, such as the visuals, speed, damage, health, etc are all contained in a single SO then all that needs to be created for a new enemy is a copy of that SO. This can be even more complicated if the designer is not the coder… It can get out of control in a hurry - making debugging hard and testing nearly impossible. Or if you have one large “ENEMY” script this can lead to long chains of “if statements” or a bulky switch statement checking to see what type of enemy and then running code specific to that enemy.Īnd that’s okay, unless you want to add 2 new enemies or 10, or 100! If each enemy has their own script, then you’ll need to create a new script with a lot of the same functionality as other enemies. Let’s say you want to add a new enemy to your game. SOs allow the separation of design data from runtime data. Rather they live in your project folders - and this is were a lot of their power and usefulness comes from. They are objects, but they aren’t gameObjects and they don’t have a transform. This also means that they can’t be attached to a gameObject in the same way that a MB/Component can be. This means that they won’t receive most callbacks such as Start or Update, but they can contain variables and functions. It inherits from UnityEngine.Object just like a MonoBehaviour does, but it’s not a monobehaviour. In this tutorial we're going take a look at the basics of SOs, how to create them, a few examples of how to use them plus some pros and cons for using them in your projects.Ī SO is just a script. SOs and Odin are a great combination which is what we’ll be looking at in the next tutorial. If you are using them, there might be even more ways to use them to make your project easier to maintain or make it easier to add features. SceneIndex will also return -2 if the scene is assigned but not in the build settings.If you’re not using them in your project. IMPORTANT : If no scene is assigned, SceneName and ScenePath return null as expected, but SceneIndex returns -2, because as explained here, Scene.buildIndex already returns -1 if the scene comes from an AssetBundle. You can also directly get all three values (name, path, or build index) through public properties : SceneName, ScenePath, and SceneIndex. As a "default" option, LoadAsync() is a shortcut that will attempt to use the build index, or the scene's path if the build index is unavailable or invalid. Step 3 : You can then use one of the LoadAsync methods directly from the ScriptableObject like you'd do with SceneManagement : LoadAsyncFromName(), LoadAsyncFromPath(), and LoadAsyncFromBuildIndex(). ![]() Step 2 : Directly assign a scene on the ScriptableObject, while the Editor script automatically saves the corresponding name, path and build index. ![]() Step 1 : Add using ZeShmouttsAssets.DataContainers at the top with the other usings. As a context menu on a SceneAsset : Create/ZeShmoutt's Assets/Data Containers/Scene Data from SceneAsset.In the Project window : Create/ZeShmoutt's Assets/Data Containers/Scene Data.Using Unity's menu bar : Assets/Create/ZeShmoutt's Assets/Data Containers/Scene Data.With all that free time you suddenly get from no longer having to debug every single scene, you can now focus on important stuff like how terrible Unity's default way of loading scenes is. It doesn't care about you changing the name, path or build index : as long as you tell it which scene it must point to, it will find it. If you need to change a single scene (remove it from the build settings, rename it, whatever), you will forget to do the corresponding change somewhere, resulting in incorrect scenes being loaded or trying to load a scene that doesn't even exist anymore.īy using my SceneData, you can directly reference the SceneData anywhere you need it, and let it do the work of figuring where the scene is in your built game. Six months later, you have dozens of scenes and dozens of different scripts loading scenes. In Unity, you can load a scene by either its name, its path or its build index - so the common way of picking the scene is by adding a public int or a public string to your script and load from that. Why would I need to store a scene in a ScriptableObject ? Unity 2018 or older : Clone/download the repo and put it in your Unity project's assets.Unity 2019 or newer : Open the Package manager, select and import the package with the git URL.I'd appreciate a lot if you could mention me somewhere if you use it, though. ![]() Uses and restrictionsĪs per the MIT license, this is pretty much unrestricted in use and modification. A way of storing scenes in a ScriptableObject. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |