How to make your code more Modular using Scriptable Objects in Unity

[@SunnyValleyStudio]

I forgot to mention. This approach can be used for Enemies as well as for the player. For the Enemy AI (if we want to reuse the same component ex Health.cs) we generate the SO object using docs.unity3d.com/ScriptReference/ScriptableObject.CreateInstance.html - so if(SO == null) -> Create instance at runtime. We only want to create the asset in our project files for the values connected to the player as those are usually needed by other systems.

[@Thagitus]

This doesn’t make sense to me. For example if you had 100 enemies, you wouldn’t be creating a scriptable object for each single enemy would you? It will be a nightmare to manage..

[@SunnyValleyStudio]

Hey! You can create a new scriptable object on the fly. The precreated scriptable objects are for player only since most systems needs to react to that. Usually enemy health only influences its own AI. If you want to reuse the same character controller for an enemy (or the same Health.cs) all you need to do is have a if(healthS) == null) -> docs.unity3d.com/ScriptReference/ScriptableObject.CreateInstance.html. This way the HealthSO for the enemy only exists in the memory - you never save it as an assets as you have with the Player. Sorry for not mentioning it.

[@VoonNBuddies]

@@SunnyValleyStudio This is also a question I had when I saw the 2016 talk you mentioned. Thanks for laying out a potential solution! Great video by the way!

[@damonfedorick]

im knew to this, but from what i understand. you make data containers for all your code, so you can call the feature from that data pool. without rewriting a "move" or an "attack" method that is normally the same 100 times for all 100 enemy's. instead of writing it 100 times you just call that method from your data, if you were to make a different movement or attack pattern you'd make a new function from your data pool. i could be wrong.

[@SunnyValleyStudio]

@@damonfedorick Hey! Generally what you describes sounds a lot like abstraction concept. The data part (SO) is an extension of this concept that it is much easier for a game designer / other people on the project to ask you to crate a pool of SO objects that represent what they want to test. It is much easier to drag and drop this SO asset as a reference to some field than to add / remove a script. The other advantage is that you can create this data Folder and you can easily tweak those parameters from one place. It is just something that yo can do to improve your project in the long run but that requires a bit of upfront work -> not necessary for a prototype. Thanks for watching!

[@damonfedorick]

@@SunnyValleyStudio i think the guy must be thinking of writing all his Enemy AI with this concept, and that would get outa control. I think SO is a awesome way to store Data for items to easily store, pull them and change them. without them flooding your scene. (kept in data containers until used)

[@DanPos]

Excellent video! The timing is spooky too - yesterday I posted a video going over how to use Scriptable Objects as an event system, again based off Chop Chop - there's some really interesting techniques in the project.

[@SunnyValleyStudio]

We must think alike! Sorry for a duplicate - I had no idea that someone else was doing a video about it. I am trying to make more smaller videos as my longer series have much less views thank a single, shorter video. I was honestly not sure why we need SO if we can use UnityEvent and decouple the code. It ended up very beneficial - especially when you work with someone else on the project. Yeah ChopChop project seems cool. Learning a lot from it :)

[@DanPos]

@@SunnyValleyStudio yeah I'm the same my longer videos don't do a huge amount of numbers. I'm working on smaller videos too I think I'm going to try to build up my subs and then do a udemy course for some longer series

[@hhcdghjjgsdrt235]

There is always something new in your tutorials.

[@SunnyValleyStudio]

Thanks a lot for watching!

[@KayanSpamAcc]

you're a LEGEND

[@SunnyValleyStudio]

Thanks for watching 👍

[@fedorovilya8728]

Hello. Thank you for the useful videos that make take a fresh look at old tasks. If I understand correctly, SO data is stored on the hard drive. "Data that you save from Editor Tools to ScriptableObjects as an asset is written to disk and is therefore persistent between sessions." Using this approach, we are constantly writing and reading information from the disk, which obviously should affect performance. Have you researched this issue? When we use ScriptableObject.CreateInstance data is also written to disk or in this case it is stored only in RAM?

[@SunnyValleyStudio]

Hey! Great question. As far as I can tell the SO is loaded into memory so any overhead is at the start of the game. The data in SO is not persisted between game sessions (it is in the editor but is is not an equivalent of a save system). It seems counter intuitive and all the solutions that you make inside the code will obviously only work in Unity - but "when in Rome do as Romans do". SO live in the memory (I would unimagine as any object on the Heap) and they will be erased by GC if you have no references to those objects in your scene. At least that is my understanding. I hope it helps :)

[@Besttechnology]

i was wondering if i use the character 2 time that will make probleme becaus use the same scriptibale object?

[@SunnyValleyStudio]

With SO used as a "storage" for in-game values you want to create 1 for the player so that you can connect it to UI / whatever. With enemies you can reuse the same code by populating the SO with a custom scripts that uses "CreateInstance()" method. If you want to create coop game on the same machine you could again use CreateInstance method and some custom script assigning the ex 2-4 so to the new UI instances. I would really consider it using SO is wise in this case since if you are working in the code you could just as well not use SO and keep the values in code only.

[@TheKr0ckeR]

This is cool, but what if we have +100 enemies? Enemies will have all their own float value SO's? If so, how would i get the reference in runtime to the healthbar of enemies then? I really want to use that system with multiple objects with same behavior, but different hp's. For player, its okay. we have only one player. But for example i'll have a lot of enemies that will have HP. Using this structure for player but using different structure for enemies: I dont want that. :) How would you solve this? For example i spawn enemies, and we will have a Group UI that shows enemies health in some UI like we show our player's.

[@SunnyValleyStudio]

Hey! You can create an SO in memory using "CreateInstance". The method that I show here works for the player mainly because you usually have multiple scenes where you may need a reference to player health and the SO is a great way to connect it without having to find the connection. For the enemy you will probably have the canvas / Ui object inside the enemy but if not you can still work out a system that finds all the enemies on the screen and grabs their health so by GetComponent or a similar system. I hope it gives you some idea of how this system can be used with enemy objects.

[@aeku_69420]

This is so helpful!

[@mehmedcavas3069]

again a really good tutorial

[@SunnyValleyStudio]

Thanks for watching!

[@MrDom3D]

Basically ‘globals’ as ‘drag and drop’-able assets

[@SunnyValleyStudio]

Hey! I would not simplify it like this. There is surely nothing special in this approach considering that you drag and drop the references to monobehaviour the same way. The benefit is that So can be an object that not only stores data but also provides functionality like WeaponSO that knows what effects to spawn, how to detect a hit etc. Also when you work with others updating the SO code doesn't mean updating the whole scene and committing it to a collab or even that you can easily create a new SO/duplicate it change it and drag-n-drop it without losing the original setup.

[@mikarutv6075]

Thank you Master!

[@SunnyValleyStudio]

Thanks for watching 👍

[@dicousdev2592]

Now the Health component has a problem. The component Health depends on scriptableObject and it is not possible to increase the life capacity beyond 1 because in the Start method, it is set to 1 which is a problem if the enemy needs to reuse this component. Do you have any solution to keep using scriptableObjects ?

[@SunnyValleyStudio]

Hey! Thanks for your comment! Generally the idea here is that we can create a new instance of a SO using ScriptableObject.CreateInstance when we are creating the Enemies (if the SO value is not assigned. The value stored in the SO can live in memory alone or can be an asset. Being an asset allows us to connect it through the inspector - very easy to work with through the inspector. I indeed forgot to apply maxHealth value to the SO.value in Health.cs (sorry about that). Please do note that it is not a revolutionary new way to handle things in unity. It is just that when you develop games you end up with Singletons, Manager classes that needs to be persisted between multiple scenes to store the value such as player health. SO values allows us to store this data in the asset file instead so it is much safer compared to persisting a manager between scenes or counting that it was added to all the scenes and initialized properly. I just find it to be much less error prone soliton that allows me to utilize the Unity inspector. At the same time I still am testing this approach but I do think that it can be very helpful in the long run. Take care!