Public class Enem圜ontrol : MonoBehaviourįoreach (Transform child in ansform) We’ve also created a “Load Enemy” function that gets called from inside the Start function. This will allow the SO to be dropped into the inspector so the data can be used by this script. Now trying to keep things simple but still showing the usefulness of this pattern, we’ve created a “enemy controller” script that has a field for the enemy data. We need something to “handle the data.” We need a script that will do something with the data. Now this is all well and good, but the data is just sitting in a project folder… With that done, more copies of the SO can be created in Unity and the data populated for different enemy types. We can delete the Start and Update functions, as they won’t get called in Unity and we won’t be needing them.įor this example, we’ll then add a field for an enemy name, a description, a GameObject for the enemy model as well as a few generic stats for each enemy. With a copy created it’s now time to add some functionality!Īdding some basic fields will create an SO that acts like a data container. Subgroups can also be created by adding a forward slash after a group name. Public class EnemyData : ScriptableObject The filename of the newly created asset as well as where in the asset menu it should show up can be added as arguments to the attribute. While this has it’s uses, we’ve found that creating a project asset is the more general use case and can offer the most benefits.Īdding the “Create Asset Menu” attribute at the top of the script, will allow a copy of the SO to be created from the asset menu or by right clicking in a project folder. Instances can be created through code using the command ScriptableObject.CreateInstance and then specifying the type. public class EnemyData : ScriptableObject To create an SO simply create a new C# script, open it in Visual Studio and then change it’s inheritance from MB to SO. 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. If you’re not using them in your project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |