Be CAREFUL with Scriptable Objects!

[@CodeMonkeyUnity]

🔴NOTE: As people have pointed out in the comments you can use them for read-write, just not for persistent data. So they can be useful for shared-scene data (although personally I prefer static fields) Just be very very aware of this one particular quirk that behaves differently in the Editor vs a Build. 📝 Further Clarification kzbin.info/www/bejne/eZutf5ivrs2mgdU 🎮 Synty Store BLACK FRIDAY cmonkey.co/syntystore ✅ Get 70% OFF on Unity Black Friday! assetstore.unity.com/?aid=1101l96nj&pubref=carefulsos 📝 95% OFF on Cute Low Poly Assets www.humblebundle.com/software/low-poly-3d-software?partner=codemonkey 🌍 Get my Complete Courses! ✅ unitycodemonkey.com/courses 🔴 RELATED VIDEOS 🔴 Make your Games Designer Friendly! (Scriptable Objects) kzbin.info/www/bejne/bZvbhGt-ftOsabM Crafting Items with Scriptable Objects! kzbin.info/www/bejne/e2qUf4ysedamr5o Simple Saving and Loading with JSON to a File kzbin.info/www/bejne/bKawd3iDYtOUpqc

[@Rovsau]

There is actually a paid asset on the store which can make them work in a build like people have assumed. Scriptable Object Pro. There are a few mentions in the comments.

[@pierredalaya444]

They don't behave differently in Editor and Builds. They are assets, when you modify a material in Editor, the changes persist at runtime, but in a build they wont if you restart the application. Scriptable objects behave the same, they are assets! If you want there state to persist across sessions, you need to save it. I usually love your videos, but I find this one a bit misleading. Other assets to do it : Soap - Scriptable Object Architecture Pattern

[@CodeMonkeyUnity]

​@@pierredalaya444 I'm not sure I understand what you're trying to say, yes Scriptable Objects aren't special, they behave like any other project asset which does behave differently in the Editor and in a Build. If you modify a material in the Editor, then stop playing, and play again, it will keep the last state you saved. If you modify a material in the Build, then stop playing, and play again, it will revert back to the state when it was first built, not the state you saved in the last playthrough. Same thing if you modify a non-instantiated prefab, in the Editor the changes will persist, in the Build they will not.

[@pierredalaya444]

@@CodeMonkeyUnity Ok let me clarify, I may not have explained it very well. What I meant was, that this is how assets are suppose to work. It is not an different behavior per say, it is simply the way assets work in Builds, not only scriptable objects, but all assets. In the video, it seems that you imply that this an "issue" or a "quirk". I think that you wanted to emphasize the fact that people should pay attention to assets handling depending if they are in editor vs in builds, which is a great point. I misunderstood the phrasing so I just wanted to add clarification on this point as maybe other might have perceived it the same way.

[@sm4llbit]

@@pierredalaya444 You are 100% right here, runtime and editor behaviour is same. Only difference is, that saving as in editor (via Project save, or code : EditorUtility.SetDirty, then AssetDatabase.SaveAssets) is not available outside of editor. I occasionally use them as runtime containers (when I dynamically switch between static and semi - dynamic collections), and it works just fine.

[@pstudioDOTtk]

I just want to reiterate another issue this video shortly touches upon. You have to make test builds throughout development to test your game properly. You can't rely on solely testing in the editor. Even if your target platform is the same as your development platform, you can run into issues just like this video shows. Make builds frequently an test them so you don't end up at the finish line and suddenly discovers that a whole system doesn't actually work.

[@CodeMonkeyUnity]

Yup that's definitely great advice, test often on your target platform.

[@FileTh1rt3en]

I will add onto this that if you don't make builds often you may end up with a game that doesn't build for a bunch of reasons. So it's always a good idea to create test builds as you go. You might introduce scripts that only work in the editor for example and need to add directives like #if UNITY_EDITOR to certain scripts or parts of scripts to be able to build as one example of something that might break your build along the way. If you let them stack up you are going to have a fun time trying to make a build later.

[@jaososchefget3632]

ya, and on multiple machines if you have that available to you. UI and framerate issues might present themselves

[@kyoseoul]

Dude, I am just at that finish line and about to lose my mind after watching this video

[@wtflolomg]

Easy to remember rule with ScriptableObject: In editor, any changes are saved back immediately to the SO asset. In Runtime, the SO Asset is loaded into memory and never saved back to - meaning it is reset back on loading the game application. This behavior is fine for using the SO asset as a global memory store, as long as you understand the lifecycle. You can track data between scenes and such in the SO, just with the understanding it will get reset when the user runs your game again.

[@Sindrijo]

To avoid the difference of behaviour between a build and play mode in the editor, access your SO via an API that returns clones of the SO in the editor when in play mode, this way the behaviour is consistent between play mode in editor and in an actual build. If you need to serialize references to SO assets, instead of using a direct reference create a serializable wrapper class that has the serialized reference but only provides access to a clone of the SO when in play-mode.

[@janedrowned]

@@Sindrijo would simply using Instantiate suffice to clone a non-nested ScriptableObject that way?

[@That1GuyUHate]

As always, there's a Code Monkey video for exactly what I am looking for (is it safe to mutate SOs with Editor Scripting) Thanks for being a pillar of the unity community!

[@CodeMonkeyUnity]

Thanks for the super thanks, I'm glad you found the video helpful! With over 800 videos I have indeed already covered quite a lot of stuff heh

[@gabaguiarp]

I commonly use ScriptableObjects to carry persistent game data between multiple scenes. Then, through a dedicated save system, I store that data onto a file, as you've mentioned. To restore it back, I have a public method inside the ScriptableObject called "RebuildFromReference" where I feed the data loaded from file. Also, I always make sure to reset all data in the ScriptableObject to the default values as soon as the game is launched, so it does not carry the latest changes applied in the editor when playing a final build.

[@malokegames]

The save system I use in my games works exactly like that too. Runtime persistence between scenes, and if the player hit the Save Button it stores everything into a file to be loaded in a next session. Works perfectly!

[@Izzy-fr1zu]

But then whats the point of using a SO at all? Wouldn't it be easier to save this data directly into another file and skip the saving in the scriptable object? 🤔

[@gabaguiarp]

@@Izzy-fr1zu By using SOs you can see all the values that are being changed on the fly, inside the editor, and even modify those values for debug purposes, to quickly test specific scenarios without having to play the game extensively. This is more important than a save file, because it's where all the game data is referenced and multiple components can read from it. On the other hand, a save file is a mere "snapshot" of that data that is stored in the hard drive, so it can be retrieved in the next session.

[@Izzy-fr1zu]

@@gabaguiarp Ok I see your point, but couldn't the same be achieved with a regular class and serialized fields?

[@gabaguiarp]

@@Izzy-fr1zu You can serialize a class just for data, but it has to live inside a MonoBehaviour, which means that if you want to access that data from another component you need a reference to that MonoBehaviour as well. On the other hand, SOs are way more modular, because they are assets that live inside the project and can be referenced freely in the inspector, like any other asset. You can test both approaches and see how they are different in practice.

[@NoraNoita]

Oh, that's honestly good to know that one should also test outside of the editor. I'll keep this in mind.

[@asadickens9353]

I work with a system of scriptable objects where we have 100s of them and they need to be fetched via a specific key. When the proper one is found, the scriptable object is deep copied and returned. Doing this will create an exact instance of the Scriptable Object in memory and then you can assign what ever you want to the values and it wont reflect in the editor or in your builds. (Because you are no longer modifying the reference on disk) In this case we have used some of these scriptable objects to store some state that are important to them. An example is in an RPG I am building, we have abilities where their effects are scriptable objects. The scriptable objects let you configure the trigger conditions of varying effects as well as how the effect is catered to the specific context. Sometimes these effects need to know how many turns have gone by or how much damage you have taken since the effect was applied. The individual affect then stores that. When the effect is over the ScriptableObject is destroyed in memory along with all the changes. This may not be the BEST use case for such a feature, but ScriptableObjects have been a key element of separating responsibilities between designers and developers. So for potentially less efficient code, but more efficient process.

[@mintydog06]

Good video. I use scriptable objects to persist player values between scenes, such as health count or arrow count, then when the game gets saved I use a system with serialises the data and saves to another file. I also use scriptable objects as Pools. So they can pool objects such as bullets, and even create a cache of bullet objects upon level load, so they aren't being created during gameplay. One annoying thing though is that they will run every time the editor reloads, so if you save something the editor will reload and the SO will run, so that started creating a cache of weapons in my hierarchy every time. But I've just turned the code off for the cache for now.

[@jjones1032]

Had to learn this one the hard way. :) If I'd seen this video years ago, it would have saved me a lot frustration. Keep up the good work!

[@georgegordian]

You can absolutely make a save game feature with a scriptable object. It just needs to be responsible for getting and setting the data to its own datastore (DB, save game file, etc).

[@DreadKyller]

While this is true, at that point there's really no real reason to use a scriptable object over a normal C# class.

[@tomtomkowski7653]

Then you don't need a SO if this has to take data from some external file or DB.

[@abalorias333]

It can still quite handy, you can use scriptableObjects as a hub between the saving system and other game areas. There is actually quite a nice example about this in a unity talk

[@SunSailor]

@@DreadKyller You can't drag and drop regular C# objects, but you can do that with SOs. That makes a big difference in workflow.

[@NihongoWakannai]

@@DreadKyller a Scriptable object can easily be referenced by multiple scripts and stays between scene loads. It's an easy way to have a container for all the data you want to serialize.

[@pandaengine]

Nice and informative video! I just wanted to point out that ScriptableObjects can also be used as read/write objects in runtime, for example as event containers. I always use them like this to couple multiple objects (scene objects with prefabs etc.) loosely so I can add callbacks to UnityEvents from inspector. I'm sure you're familiar with it, the ScriptableObject architecture. It would be cool to showcase it to the masses as I don't see much mention of it.

[@3333218]

Code?

[@Xyckno]

@@3333218 check the Ryan Hipple talk, he also posted his test repo.

[@3333218]

@@Xyckno Thanks!

[@pandaengine]

@@3333218 you can also check out Atom. I use it almost everyday.

[@3333218]

@@pandaengine Link? (I sincerely don't know what Atom is; and I suspect you're not talking about that text editor are you?)

[@K-Anator]

Persistence is something that got me when I first learned about ScriptableObjects. I did the exact scenario portrayed in the video. Thankfully I didn't need to save much, so it was a quick hack to write everything to the playerperfs, but yea, it was a pain to figure out after having worked on the project for a while. Lately I've taken to using a Scriptable for global stuff. I probably shouldn't, at least not the way I am, but the things I'm doing make sense to me and I'm starting to be able to actually read my code without ripping my hair out if I leave it alone for a week.

[@devzozo]

You can still use SO's for a save system but you can't rely on the object itself to store that data once a session is over. A big advantage with modifying scriptable objects is that they DO retain that data between scenes. Meaning that SO's are still useful for tracking the active state of your game; No need for a persistent Singleton GameState/Manager object or Manager Scene everywhere. If you add methods to your Save object that writes and reads to a save file it will complete its functionality as a proper save system. I totally understand the reasons why you would not want to modify scriptable objects like ones that store item or enemy data, but to *never* do so is losing out on so much leverage you can put into scriptable objects. Please check out this Unite talk that addresses an approach to using ScriptableObjects in ways that help encapselate your classes and reduce dependencies by doing exactly what you suggest we not do. Unite Talk: kzbin.info/www/bejne/qJK0ZJx-naqSgc0 Open Source project that greatly expands the ideas from the Unite Talk unity-atoms.github.io/unity-atoms/

[@devzozo]

I should add that the save system is still flawed for scriptable objects for another reason; their behavior of saving their state from play mode into the editor makes debugging and testing rather annoying, and you would need to balance your testing workflow around that issue.

[@CodeMonkeyUnity]

Yup they are indeed useful for sharing per-scene data. Personally I prefer to use static fields but an SO works as well. I have seen that talk, really great, it's a very interesting architecture. As long as you know about this one limitation and you don't assume it will persist in a build like it does in the Editor then yup you're fine.

[@MaslinMonty]

I know you say don't use them for writing data, but I was starting my save system and thinking about using them so that the values can be scene independent. For instance, if a chest is opened, mark that bool as true. Then write the value of the bool to Json at a save point. I'll only have a save point every 6 - 7 screens. Is there a reason not to use this system if I'm just handling bools? I'm struggling to create a system that is expandable across scenes with ~120 scenes and 5 to 20 bools per scene.

[@CodeMonkeyUnity]

That's fine, as long as you are aware of this limitation and you don't assume the SO will behave persistently you can do that. So when the game starts, load the state of the SO from whatever persistent method you want, like a save file. Then before quitting, save the SO data to a file. If you do that and don't rely on the SO being automatically persistent like it does in the Editor then you are fine

[@rorysanchez]

I’m sorry CM, but as a professional programmer working on a studio where we use scriptables as the backbone of our very dynamic systems I have to disagree with you and I’m worried that you are discouraging new developers from using a powerful tool. Some other comments already pointed out Ryan Hypple’s Unite talk and I will recommend it too. It is true that you cannot persist data on SO’s alone, since their value will reset once unloaded from memory, but that is just a matter of understanding the lifecycle and using it to your advantage. Using SO’s to store static data only (such as stats or item info) is like using a Swiss Army knife to peel apples and nothing else, kind of a waste of a good tool. Please take this as constructive criticism, I use to recommend your videos, and I’ve learned quite a few things from you over the years, keep up the good work!

[@CodeMonkeyUnity]

Yes you're right when I said they should only be used for read-only I should have really clarified that the main issue was with persistent data, they are perfectly fine with read-write as long as it's not persistent. My main goal with this video was to highlight this one particular quirk where it behaves differently in the Editor and in a Build, but as long as you are familiar with that quirk and how they work, as long as you take care to initialize them every time and don't rely on the default Editor behaviour then yes they can indeed have many more uses. Thanks for the comment!

[@fakiirification]

so, you say not to save any data that changes. Im early enough in my project to correct this if its an issue, but i currently have a SO as a player stats container, and it does hold 'current' and 'max' values, and the current value is changed in real time, like when the player takes damage etc. BUT, I do not intend it to be a save feature. the actual stats will be saved out properly and loaded back into the SO at runtime. Is this a realistic use of SOs or should I track current values on a monobehavior in the scene somewhere?

[@CodeMonkeyUnity]

As long as you never assume that data will persist and you are aware of the difference in behaviour between editor and build then sure you can do that. Use a proper persistent saving system and on load set the data in the SO Personally I wouldn't use that, I would only store the max values on the SO and keep the current values on some Player script, but yes you can do that.

[@Gortart]

SOs are basically just binary assets with custom importer and custom editor-only editor that you can write(the SO class itself), just like textures, models etc. You don't actually get the file access to the SO in the runtime, only the data that Unity read from the disk. You could save using JSON or any other serialization method to save SO's data to a seperate file, but like you mentioned, SOs are not needed for that. I think just a static class should do the job a lot better if your save system is sensible and only have 1 concurrent save data at a time.

[@LionManBranc]

Actually, SOs and static variables modified in runtime while in the editor aren't really saved. You see, a "run" in the editor is not entering and exiting playmode. It is opening and closing the editor itself. Doing so would have reset your SOs and other static variables, which is exactly the same behavior in the final build.

[@nanaschi]

Man you potentially saved tons of minutes who check this stuff by building the project ty

[@F0r3v3rT0m0rr0w]

Hey, so i am about to program items into my game, i need the items to be able to decrease and increase player stats, also be stored in an inventory. each item will need a game object and a pick up script on that object, my question since you have brought this up *since i may want to save where items are in the world* what would be the best way for me to approach this ? do you have a tutorial on this ? thank you.

[@CodeMonkeyUnity]

The way I do it is just have some kind of Item MonoBehaviour that is attached to the item object, then that MonoBehaviour has a reference to an ItemSO that contains data on that item, like what prefab spawns that item, what icon, what name, etc. I used something like that in this crafting system unitycodemonkey.com/video.php?v=_aC3NVIQ-ok For saving, you just need to save the type of item and the world position. So I would make a SaveObject on the Item MonoBehaviour that would save the ItemSO.name and the transform.position unitycodemonkey.com/video.php?v=6uMFEM-napE

[@F0r3v3rT0m0rr0w]

@@CodeMonkeyUnity thank you! I will check this out today cheers ! Ive just been struggling a bit with this. So this will help.

[@joshswanson0]

I used SO to make my various weapon types in a game, but I also had an HP variable that I wanted to persist when the game exits...It was easy to put a load/write to a save file within the SO just for that variable...Was this a bad design choice? It hasn't led to problems in my small scale game

[@CodeMonkeyUnity]

As long as you remember that they will not persist by default, and you have a save/load system to handle that, then it's fine. Just be very aware of that limitation, otherwise when you make a build you will go crazy trying to identify why the build is behaving differently from the editor.

[@wrathfulslime1009]

Another detail of scriptable objects that can drive people crazy is if you make changes to them during playmode those changes will not revert when exiting playmode. This can be great when used intentionally but can also cause a lot of confusion and headaches.

[@RootGames]

Finally, someone shared that information! Yet, you can see so many "inventory" tutorials with Scriptable Objects that never go through the process of saving and loading.

[@GawainPlayz]

Do you have an alternative that would be more effective and would be able to be saved and loaded?

[@yevhen4330]

Thank you! Was about to try to implement saving settings info in a scriptable objects.

[@DavidZobristGames]

Another issue that might arise is in usage with the addressable system. If you have a prefab, tagged as addressable that you load into memory that is referencing a scriptable object it packs its own instance of that scriptable object into the loaded prefab. So they are no longer the same scriptable object instance, changing data on runtime on the scriptable object that you have linked in your prefab will not update to the one referenced by the addressable instanced prefab. There are ways around it but its good too know.

[@bartomiejjarosz7105]

Scriptable Objects can be useful even if they are read-write. You need to remember that the changes are not saved between sessions. I like to use SOs like variable containers. It can be a good way to connect gameplay with UI. More info here: kzbin.info/www/bejne/qJK0ZJx-naqSgc0

[@kaasronald3623]

I would recommend using SO's any chance you get and that goes way beyond just storing some read only data. They're perfectly fine to write data to and they are intended to do that or they wouldn't have that feature. If you want to save that data between build runs, you have to do save it to a file just like any other save system. There's not really a difference. But I can see it being a pitfall for beginners who think they figured out a neat trick.

[@SkeleTonHammer]

Yep, I made this mistake about 5+ years ago where it was kind of the opposite - I was accidentally writing SO data permanently to my SOs in the editor and I DIDN'T want that. I was so, so confused. In the end, I used scriptable objects as a way to easily handle crafting recipe data. Though, looking back, I would probably just rather do some sort of JSON implementation and a custom editor. I mostly only used a scriptable object at first because I wanted stuff to be easily edited in an inspector, but my lack of experience that led me to do that also worked against me when I was accidentally changing the SO data.

[@simonchen6698]

This was one of the things I realized early on, and to prevent that from ever occurring, I created a deep-copy method for all my SO's so that whenever I load from a cache at run-time, I make sure to instantiate a new copy, so that any values adjusted to my SO's will not overwrite template values I had from the original SO's. So far so good!

[@joysonst]

Yes, this was an issue I was facing while developing my game. I somehow managed to solve all the issues inside the game. One thing was downloading the saved data from the cloud and applying it to the existing users. I somehow managed to solve it by reading the save data multiple times and replacing the user data inside the game. But the problem still I'm facing right now is, If I update my inventory system with new tools by adding new items in the scriptableObject list and I try to push the game to the store. The existing user's data gets cleared. So all their previous purchase gets cleared. Is there any solution to this? Just because of this issue I'm afraid of pushing new updates to my game.

[@sabharishrinivas4895]

I have a scriptable object that stores all of weapon data like damage, extraHP, extraMana, weaponSprite etc. I also have a bool variable `isEquipped` that is manipulated in runtime to check if item is equipped and this information is written back to the SO. What's an efficient way to do this equip Item without having to write back to SO?

[@EskChan19]

That's absolutely fine to do via SO, CodeMonkey didn't say you shouldn't write back to SO's, he said that the game doesn't SAVE that. If you close your game and open it again, any changes will be gone. So if damage, extraHP, extraMana and so on never change throughout the game just keeping that for SO is absolutely fine. The only thing that won't be saved is "isEquipped". Can you have multiple things equipped? Or does equipping something else automatically unequip the other stuff? If it's the later, you could just add a "Equipped" variable to your player, that takes a ScriptableObject object and then save that variable.

[@sabharishrinivas4895]

@@EskChan19 the game has multiple items like boots, armour, shield, each of which has like 20 items and only one can be equipped. I'm thinking maybe save the name of the equipment that's currently equipped when the player exits the game and write the value back when player starts the game?

[@ludomancerstudio]

But I can still save whatever data between play sessions in a .json and just when I open again I can read the .json and write back at the SOs, right? It is how I intend to use, SO holding data stuff but with a .json save.

[@CodeMonkeyUnity]

Yes if you save it onto a persistent file before you quit the game and load when the game stats then yes

[@logiis6]

Lol just right now I am working on SO save system... But as you mentioned I use json for the actual saving... I chosen SOs, because I have multible systems accesing it and I didnt want static class. Is it realy that bad ? I always viewed it as monobehaviour without the need of a gameobject.

[@EskChan19]

As he said it's absolutely fine, it just won't be saved between sessions. If you can fix that, you can absolutely use SO's for that. Just keep in mind that you can't instantiate SO's. When you refer to an SO you always refer to the ONE SO. So for example, if you make a "Sword" SO with damage 1, and then make an upgrade system and just write back to your SO that damage is now 2, and your player finds another sword, that sword will also have damage 2 because there's only one SO "Sword" and any change to it affects it through any "instances" of it.

[@phodaOG]

But having inventory system designed as SO that can basically go to every scene because it persists through scenes, also any script that needs it, you just drag it into and always have it available. That seems fine to me, as far as you handle load and save correctly with other system. Or am I missing something and this is bad practice?

[@CodeMonkeyUnity]

You can do that, personally I would use static fields for multi-scene data but SOs can indeed be used for that purpose. Just be very aware of this one specific limitation, in the Editor the data will persist, in the Build it will not. As long as you initialize the Inventory correctly and use a proper persistent save method then you're fine.

[@JohnVanderbeck]

Funny thing is I DO have a save system built on SOs and it works fine. BUT it isn't just as simple as what is shown here, where the data is stored in the SO itself. The SOs only comprise one layer of the overall system, but at runtime the data is written out to JSON files upon saving, and loaded from the JSON back to the SOs when loading.

[@CodeMonkeyUnity]

So you're essentially just using it as structure, just like a regular C# class, yup as long as you handle the persistence through another method then it's perfectly fine.

[@JohnVanderbeck]

@@CodeMonkeyUnity Yeah the SO layer has all the logic. It is done this way because the SO layer acts as the designer level in the editor. This is where shared variables are set, where things can be set to be saved or not saved to eventual game files etc. It works, as we all know, as a gret design layer. So 90% of the work is done there and there is just that extra layer at runtime to actually (de)serialize the data to disk.

[@coreyholt8522]

I'm working my way through a few of your videos. Thanks for the great content. I'd like to use a UI scriptable object to populate data from an API call. Would you recommend that use case or is there a better unity feature?

[@CodeMonkeyUnity]

Why are you using a scriptable object? Are you using an editor script? If so then sure that works But if you're contacting that API only during runtime then I'm not sure why you want a SO instead of a regular object

[@coreyholt8522]

@@CodeMonkeyUnity I want a pop-up UI to spawn when a gameobject is clicked. The UI's contents will change based on the API call. It seemed like a similar feature as spawning scriptable objects. Would a normal game object be a better option? (Thanks for your replies!)

[@randomragtags]

Another issue I found in my last project is that when you have many instances of an SO, variables changes made via script might not keep between editor sessions. In my case roughly 6 out of 60 of them. I ended up having to go through all 60 SO's to double check their values and manually input any incorrect values before final build.

[@stephenboling2313]

Hey Señor Code Monkey, I was thinking about using Scriptable Objects to make a few types of levels of ai and they would be randomly assigned to enemies through a point system that the enemySpawner would spend points on the ai as well as the enemy type and attach them together. Would you say this is a bad idea to do with Scriptable Objects?

[@CodeMonkeyUnity]

You can definitely use Scriptable Objects to store the data that the AI requires. Things like targetFindDistance, movementSpeed, attackSpeed But only use it to store that data, for handling the logic which modifies the data do that in a regular MonoBehaviour which reads the data from any Scriptable Object of that type and applies the AI to the unit.

[@juicedup14]

Are there other things that vary from editor to build?

[@syriuszb8611]

Generally? A ton. My favourite trap is the order of script initialization (for example order of ScriptA.Start(), ScriptB.Start()), it's usually same in editor, but once you build it, the order can change. And if and how it will change, is random. It can change just by changing some code, so it may seem like you fixed it, you build it, it works, you commit the changes, and your coworker downloads your changes, builds and it does not work for him, because he got different order of operation.

[@juicedup14]

@@syriuszb8611 omg thats awful. Is it fixed if you manually set up script order?

[@syriuszb8611]

@@juicedup14 Oh, forgot to write, in the project settings, yes it fixes it.

[@CodeMonkeyUnity]

Performance is another thing that varies, although usually for the better UnityEditor also cannot be used in a build, I had this issue when I was working on one of my games and had a script to clear the console, I didn't include #if UNITY_EDITOR so when I tried making a build it broke. And yup script ordering can be semi-random, if not explicitly defined then sometimes Unity decides on one order, and sometimes a different order. My general rule for that is to use Awake(); to initialize objects, and only reference other objects on Start(); That way all objects should be safely initialized on Start(); regardless of what order Unity decides to use.

[@GW_KANG]

Hlo I'm new to unity and all these codings I have thousands of scriptable objects and i have to get them in a mesh or .fbx format is it possible

[@nwotyzarc]

But if I use them to store data, which is then serialized and saved into a database it will work right? I could load all the data from a database into the scriptable objects and read out of them during runtime, and when a value changes, I save it into the database again.

[@CodeMonkeyUnity]

Sure if you save it to a persistent database then yes it will work. But at that point it begs the question why are you even using Scriptable Objects instead of a regular C# object?

[@zerosaber2242]

The coupon discount code doesn't work. I already tried with a few bundles during the event and I didn't get the discount. It was over $100 (excluding tax) so I wouldn't count on using it.

[@CodeMonkeyUnity]

Did you write it correctly? CODEMONKEYBF22? Maybe it was a temporary issue with their servers, I've tested it myself and it worked, other people also seemed to be able to use it just fine

[@oooooo-ku1fp]

Hey Code Monkey! May I ask which keyboard you use? I love the click sound :D

[@CodeMonkeyUnity]

Heh it's a super old Samsung that has been with me for over 15 years. Actually just randomly stopped working a few days ago, I'll have to see if it's something that can be fixed or if it's finally gone for good

[@notlaw1567]

As always, thanks for the content! I just ran into a quick question after watching this video. In my case I'm using ScriptableObjects to open a custom editor window where I manage their data. The data seems to persist after closing the editor window, or the unity editor itself. I'm guessing there wouldn't be any weird behaviour once I build my game, right?

[@CodeMonkeyUnity]

When you make the build you will no longer be able to change that SO. But it sounds like you're using an Editor Window to just build content during development that will then just be used during the final game? If so yes that works fine, that's the intended behaviour and the Build will read that SO correctly. Just don't attempt to write to it in the final Build since that won't work.

[@notlaw1567]

@@CodeMonkeyUnity Yes, I'm using it for development but I want to use the scriptable objects data on the final build, which I've never tried before. Thanks for answering!

[@derpenz5376]

Is it possible for players to create their own items in the finished build with scriptable objects. For example a extra mod menu to add addition user made items or recepies?

[@CodeMonkeyUnity]

No, whatever scriptable objects you have when you make the build is what gets written to the disc, you cannot add more after the build is done. But you can definitely create regular files to hold that data, just like you would create a Save file. Specifically for mods Steam has their Workshop SDK Alternatively you could build your own using a Cloud service unitycodemonkey.com/video.php?v=qdE01Xg3y2A

[@derpenz5376]

@@CodeMonkeyUnity thanks for the quick response.

[@tsuaeghakihas469]

daaanng... so I shouldnt include things like character stats - Str, Con, Dex, Exp in these. Ive been working really hard on a project and scriptable objects seemed like a great way to create lots of Characters/Enemies/anything... didnt realize they were technically read only.. crap... Im super glad I saw this, THANK YOU!. back to the drawing board. glad I didnt get to a finished project... its intimidating sometimes with how much there is to learn about game Dev and one simple mistake could throw a wrench into the whole project. You and other content creators make this journey worth it! Not looking forward to re-doing everything I had so far with my scriptable objects, but in the end it'll be worth it and rewarding. Cheers CodeMoney!

[@tomasmaciasrivas5989]

Thank you for the video, very helpful as always! Just one question though: Will be ok to use the SO as kind of Singleton to get and save data during game but saving/loading its content with another script to a file or playerPrefs in order persist through different runs of the game? Thanks in advance

[@CodeMonkeyUnity]

Yup you can use it as a way to share data between scenes, just be very aware that it won't persist after you close the game

[@pandaengine]

That is a valid use case. I suggest you to check out ScriptableObject architecture.

[@STORM-qw2gq]

I need to setup Adaptive Performance for my mobile game. I got this error message from the package, what does that mean? [Adaptive Performance] No Active Loader was found. Make sure to select your loader in the Adaptive Performance Settings for this platform i need a solution

[@CodeMonkeyUnity]

Sorry no idea, I've never used that package.

[@MatthewChowns]

Thanks for this! You just saved me a big headache. I'm literally about to tackle the problem of saving my inventory system.

[@zendraw3468]

it seems perfectly fine to save data during gameplay and keep it betwean scenes but ofcorse for betwean plays it shuld be saved on the hard drive. so i think its better if you just dont talk about it as a warning but just clarify the SO`s behavior. SO`s are perfect for saving data in game and making it easy access to anything that has a refrence becouse you dont need an instance of it. So for anyone that reads, SO`s are kept in memory so any changes to them are lost after closing the game and SO`s are saved in your build with the last values theyr set with in the editor. so SO`s are for access and modularity. game saves are done aways on save files on the hard drive.

[@CodeMonkeyUnity]

I talked about that in the follow up video unitycodemonkey.com/video.php?v=CjJNeyyhsKs Yes as long as you are very familiar with how exactly SOs behave then sure, just don't expect that the behaviour you see in the Editor matches the behaviour in the Build because it will behave differently.

[@dasmaffin1633]

I use my SO as objects and nothing more E.g. I statrt the game I load the data from an SO and instantiate it the SO has data like HP which are ofc changed I save in an actual saveclass that derives from MB That problematic?

[@CodeMonkeyUnity]

Not a problem as long as you know about this one particular quirk. As long as you don't use them for persistent data it's fine

[@zak-ks7ee]

So just to make sure… is it that scriptable object cannot be used to make a save system, or that that they cannot be used to store data that changes in game?

[@CodeMonkeyUnity]

Once you close and reopen the game, the data you modified in the csriptable object is gone, it will not persist

[@nguyenhoangminhtrung2779]

What if I use ScriptableObject as a singleton? let's say I have an Inventory which will have Items in it. InventoryUI would use that SO to render data, another MonoBehaviours will use that to gets Items data such as stats etc or even create/add new data into Inventory.

[@CodeMonkeyUnity]

You can do that as long as you remember to load/save data from/to that inventory through a proper persistent method, like a save file. The only issue is you cannot expect the SO data to persist. Once it's out of memory the data will be gone in a final build.

[@TriNguyen-kq9iq]

Hi CodeMonkey, can u help me? I lost my ScriptableObject Data when exit and reopen Unity. So I have to recreate a new one that waste of my time. I dunno what to do.

[@CodeMonkeyUnity]

That's odd, is your Unity crashing? Did you save before exiting? The data should be saved when you press Ctrl + S or Save and Quit . Maybe your Unity doesn't have permissions to save data or something

[@512Squared]

I learnt this the hard way :D I was so confused that when I was changing my data during runtime that it was permanently changing the data in the SO too. I couldn't make sense how you were actually able to make use of SO if you couldn't even modify that data. But you can use the SO to simply load your data into instantiated variables and then modify and even save those variables and not affect the SO.

[@alexthebassist23]

Lol, I'm pretty sure I know exactly what this is about, having modified a scriptable object during run time a few weeks ago and wondering why my game was being so odd 😂

[@CodeMonkeyUnity]

Heh yeah it is definitely a very sneaky issue that can drive someone crazy until you can figure out what is going on.

[@patek2385]

So If I have two types of enemies that will only differ from each other by speed, damage and health. Player will have different clothes that will give player more or less health and different weapons with different dmg and health should I use scriptable objects?

[@CodeMonkeyUnity]

Yes usually scriptable objects are great for defining the stats of your equipment or enemy types

[@PTKDWA]

Any tutorials on that? I really can't get my smooth brain to understand those SO @@CodeMonkeyUnity

[@CodeMonkeyUnity]

You can see how I used scriptable objects to define the building data in my Grid Building System video kzbin.info/www/bejne/mqbPoKZ-hdFraKM

[@Radek_M.]

Well that is a good point. I didn't know about this and I suspect I would have figured it out, but in a very painful way....

[@gdtutorial]

Can I use open('filename.ext', 'r+') in unity....?

[@CodeMonkeyUnity]

Sure, that's just regular C# so yes it will run. Whether it will open the file depends on where that file is. If it's inside the game folder yes, if you're trying to access something like C:\ then it will probably fail with lack of permissions.

[@dantrix555]

Thank you for this really amazing video, you saved me of using SO for a save system hahaha, I though about it some days ago while coding some game mechanics for a little game but in my case I realized that creating a save system wasn't really necessary.

[@clarkmeyer7211]

damn thats actually crazy. makes sense why it doesn't work but if you had to try this it would definitely make a person mad not knowing why their save system isn't working.

[@KonradGM]

I love your content Monkey, but i feel you kinda missed on this one, or at least with title to content. YEs SO's are designed to not keep data, but knowing that they can exceed in data being held within multiple places such as player health etc. They are actually VERY GOOD for holding and updating data for saving. The way i would look at it , is that data that needs to be managed between states, scenes etc for saving such as player position, hp, level, etc can be always kept in SO, so long as that data is then updated / saved somwhere else weather it's db or custom save system.

[@nullx2368]

Easy way to explain it too a junior is, SO's should be considered as an asset. Even further considered as an Image. Typically you don't want to modify the image only display it and use the image as you like. Same goes for SO's they are mostly "getters" at runtime and you should avoid holding runtime data in them. Of course there are some usecases but I still would say at that point there are better ways than using SO's.

[@NihongoWakannai]

They are not just getters. Scriptable Objects are a great way for having different systems exchange data without being coupled. One system can write to the scriptable object, and any number of other systems can read the data from that object without having any direct references to the writer. Your systems which read will still function without errors even if you completely delete the writer from the scene. I don't know why people think they can only be read from at runtime. They are Objects, just like Monobehaviours, but they don't need a GameObject and persist between scenes.

[@nullx2368]

@@NihongoWakannai that's excatly why you shouldn't use them like that. Simple normal classes and a proper save system can do what you said without using scriptableobjects. But let's say you have a system where you created monster data, and made an "orc". Modifying that orc will change it to every orc you spawn, while if you seperate the responsibility of preruntime and runtime properly you don't need to think of this issue. Not having a proper system for controlling data will become bad as you scale your game, iv released a game using SOs in the way you are talking about, I wouldn't do it again.

[@NihongoWakannai]

@@nullx2368 That's not a problem with scriptable objects, that's a problem with you shoddy implementation. Of course you wouldn't edit the monster data at runtime and then be surprised that it affects all monsters, you just invented a scenario where you wrote bad code. Those fields should have had private set accessors. A scriptable object is an object, just like monobehaviours they are very generalized and can be used in many different scenarios. There are also plenty of ways to use them badly when you don't understand them. You say "normal class" but scriptable objects are perfectly normal and generic within unity, people treat them like they're some exotic thing but they really aren't. Writing to scriptable objects is a super convenient way to decouple systems from each other whilst still having easy data transfer between them

[@nullx2368]

@@NihongoWakannai "super convenient way to decouple systems from each other whilst still having easy data transfer between them" You don't need SO's to do this which is my main point. I use SO's a lot just not for this reason, I guess if it works for you then it's fine honestly you will likely came to the same conclusion after years doing it that way. Mixing Assets + Runtime data might look like decoupling until you force your systems to act in certain ways

[@NihongoWakannai]

@@nullx2368 have you watched this? kzbin.info/www/bejne/qJK0ZJx-naqSgc0

[@MathsPlusGames]

You should try Scriptable-Objects-Pro, not only does it overcome this problem, but you can integrate into it without losing your work. it is also faster and encoded. It also has autosave during build (optional), that will save even if you crash Greate video as always!

[@MaliciousTachyons]

Duuuuuude you just saved me days and days of headache. I was using SerializableObjects as savegames, but then switched over to a JSON-based save/load system. For anyone intending to do so, a little advice: Don't use JsonUtility.FromJson. FromJson can only write to base "classes" so if you inherit from either MonoBehaviour or ScriptableObject, you'll need to use JsonUtility.FromJsonOverwrite() instead.

[@FyresGames]

I did something else using scriptable object to build a modular AI with logics in each SO. It worked quite well untill I found out Issues with IEnumerator and Async. They don't break or give errors, but if multiple enemies got the same SO on them and they all trigger the Enumarator or Async at once, only one will work and other will just stop doing their stuff. Learned a lot about SO with that, changed for a Mixed animation state machine/AI and all work smoothly now.

[@skave7228]

You scared me ! I use SO for a save variable save system for a homework project, but our project just need to save variable inside one run Anyway thanks you probably saved many of my future projects

[@Wanfanel]

if you want not lose data between scenes in ScriptableObject you can use "private void OnEnable() => hideFlags = HideFlags.DontUnloadUnusedAsset;"

[@CodeMonkeyUnity]

Oh that's an interesting tip, I've never used that, sounds like it works similar to DontDestroyOnLoad for Game Objects?

[@Wanfanel]

@@CodeMonkeyUnity when Scriptable Object is not used by other objects will be unloaded and temporary data will be lost. Usually happens when you change scenes. reference your scriptable object in "DontDestroyOnLoad Game Objects" should no unload ScriptableObject from memory too, but i prefer not use "DontDestroyOnLoad".

[@timothymccune7047]

May you make a quick tutorial on how to plant crops in a farming game. Im having problem trying to find a way to code it.

[@eivis75]

You saved only position of player, do you need also to save what time it was saved ?

[@CodeMonkeyUnity]

You can save whatever data you want, it's up to you

[@Saleca]

but is it a different behavior? if you close and open unity has the same behavior. i do use scriptable to save games but just as a helper, to persist then i store it properly in a file

[@CodeMonkeyUnity]

Only has the same behaviour if you close Unity without saving. If you save the current scene it will save the changes back into the SO whereas on a build it won't

[@Saleca]

@@CodeMonkeyUnity i guess i never really account for that. thought it lost state when reseting session

[@vyse-sen]

somebody pay this guy. he has done so much for the community. i never undurstood most of unity featues until i found this channel. thank you codemonkey

[@nileshkumawat6730]

Thank you very much don't know about this.. Upgrade system works with scriptable objects ?

[@CodeMonkeyUnity]

Depends what you mean by that, you could definitely use a scriptable object to define the resources required for upgrading some kind of item.

[@shield_maiden_]

Ive used modifying scriptables in editor runtime after I made a puzzle creator tool and needed to store what I make as puzzles to be played by players.

[@SaeadaYudha]

Oh wow thanks for the information man, im still new using unity, and recently i use scriptable object to made something like Item data or Dialogue data

[@TheCricketNest]

Faced this issue when i was building my first game, Thankfully I recognized this problem while testing. Then I started using Scriptable Object to Maintain the persistent Data across multiple scenes instead of having a singleton class and I would save the data of scriptable object to a json file and populate data back to scriptable Object at Loading Times. Thank You for the video. Could you do a Video about best real case scenarios to use Scriptable Objects?

[@CodeMonkeyUnity]

I'm working on a clarification video talking more about SOs later today. For me I still use them as just data containers, so I use them for storing Weapon stats, Crafting recipes, Skill effects, etc But other people also use them for read-write as Event systems, or Variables, or multi-scene references. As long as you are very aware of this limitation, how they behave differently in the Editor and in a Build, then you are fine

[@BorisNovikov1989]

Also SO values gets deleted with UnloadUnusedAssets between scenes if there are no direct references to them. Be careful, keep all references in a list in NoDestroyOnLoad container.

[@After_Pasta]

Really cool if you think about it a game is really just a virtual machine that runs every time you start the executable --- really informative video

[@malghoul398]

This is very useful information thank you! In the project, I'm currently working on I store Character data such as Levels, current hp and inventory in scriptable objects. Thankfully I haven't gonna part the point of no return yet with changing the system up.

[@Hietakissa]

it's fine to store data in them, just keep in mind you shouldn't try to use them for saving the data and that the data persists after changing scenes

[@niuage]

What you're doing is great, dont change it because of this video. The scriptable objects can still be used for that and referenced by the different scripts that need them. BUT, you just need to have a separate system to persist the data for real, and load it back into the scriptable objects on game load or whatever.

[@EskChan19]

@@niuage It wasn't the point of this video at all to say you shouldn't use Scriptable Objects. The point is just that these aren't persistent. You can't use Scriptable Objects as a save system, despite the Editor making you think you can because in the Editor, changes to the SO are written back to the SO, but not in a build. That is the point. It's perfectly fine to use SO to store player data, you just need a separate save system to store and load the data from the SO.

[@CodeMonkeyUnity]

Don't be afraid to use SOs, by all means do use them for storing character data, but don't assume it will persist after you quit the game because it won't in a final build. Just be very aware of that limitation and you will be fine.

[@RoboGameOfficial]

Do DataContract's work with Unity? Because if they do, then that would be much nicer to deal with. Where all you have to do is mark a class you want data to save as "DataContract" and mark each member of the class you want to serialise as "DataMember"

[@pedrobelluzzo]

That's a important point. I've already stumbled upon a commercial project that was relying on scriptables to save data. As surprising as it may be, even professional programmers make that mistake.

[@LuukDomhof]

Like others have mentioned, ScriptableObjects can definitely be used for save data, they just have to be managed properly.

[@NihongoWakannai]

Was it an indie game, or an actual programmer on payroll? This is very basic unity knowledge when working with SOs that any professional should know.

[@keropaci]

Had this experience years ago. Thanks for clarifyiing that, I learnt that on my expense

[@emirr_yilmazz]

What if i store the last values/data of the SO in a json file and load it when game start again? Are there any "more correct" way than this? I'm asking this beacuse in my project I'm storing 20+ difrent weapon types with their values in SO and you can upgrade the weapons too. By the way thanks for the warning about SO, I didn't know that and I'm thankfull to saw your video before it's to late.

[@CodeMonkeyUnity]

If you serialize the data and save it on a proper file which you then load onto the SO during runtime then yup that works. Just always make sure you don't make the assumption that the data on the SO will persist by default

[@MechanizationStudio]

It doesn't work as the save system, but it is good enough that we can modify it with script, so that maybe I can change it with editor script so that I don't need to do things manually.

[@CodeMonkeyUnity]

Yup for Editor scripting writing to SOs is an excellent use case

[@Caldaron]

erm yeah if you don't know the fix for that i got someething for you: deserialize that info from a save file in the Start function right after you chose that save file. and do that for every user configuration you might have saved onto a ScriptableObject like keybindings etc that you used for a player, save or global scope

[@MaZyYTube]

The funny part is also the data in the editor is not saved. If you do changes in runtime it is not dirty. So if you restart the editor you will have the old data and not the new you habe used to save.

[@ekzac]

Wait wait wait, I was taking a look in the About section, and the local is... você fala português? '-' (not I would do that in comments, as I think English is more useful in this context, but I am very curious now haha)

[@CodeMonkeyUnity]

Heh yup sou Português!

[@stevesmith.software]

The reason I published ScriptableObject Pro was to solve this exact problem. 2 lines of code and 'hey presto' ScriptableObjects become savable at runtime. The data will even persist across builds if you want. If Code Monkey would like to update his video using my Asset just get in touch

[@kaasronald3623]

you tried

[@bambuccigames]

Why would you use SO for saving game data in the first place?

[@CodeMonkeyUnity]

If you just wanted to have one save file then it could be a good very simple system, no need to worry about managing files, having to WriteAllBytes(); or ReadAllBytes(); So for a beginner who is just getting started it seems like this data container would be a simple way to make a save system.

[@SunSailor]

You usally simply clone the SO while instancing it, then it won't save anything back. Problem solved. SOs are great tools, far beyond storing static data, you leave tons of potential out, if you reduce them to simple datastores. Further, if you start building your game at the end of the development process, you're already doing fundamental things wrong. Build early, build often. And test the final builds or even better, have automated test runs running automatically through the game.

[@Marconius6]

This is also the case for prefabs (and other assets), which you CAN change at runtime, but of course those changes won't persist. This is also a terrible idea in Editor, because every time you save you'll have new changes for your version control system... even worse if you have more than one dev, of course.

[@NihongoWakannai]

It's correct not to use it in this specific way as a save system, but to say that you should NEVER use scriptable objects for data that changes and that you should ONLY read from them at runtime is just completely wrong and disregards a massive amount of functionality that scriptable objects provide.

[@EnderElohim]

There is a way to use scriptable object as save object and in my current game i'm doing it. What i'm doing is using json to save changes from scriptable object and when game start load json and override scriptable object with it. So basically i'm using my scriptable object as mold

[@SinhtUpthereal]

but u can use them during runtime like some kind of cache and if u close the game or every interaction or so u serialize the values of the scriptable objects into Json and every time u start a new instance of the game u check if there is a savegame json and override the values of the scriptable object with it. isnt it ?

[@CodeMonkeyUnity]

Yes the only problem is if you assume the data will automatically persist which it wont. But if you just use it as a temporary cache and save the data to a proper persistent format then yes that works

[@rain4279]

I planed a game around scriptable object, and thought of using them to save the score of multiple levels at run time, fortunatly i saw your video.

[@ekzac]

Ah, the title was kind of a click bait for me ^^' But anyway, ScriptableObject is being pushed to its limits as responsive variable system. Unity-Atom project is a nice example, but this kind of usage still miss some features. Serialization of generic types by reference is a huge problem for this case, the impossibility to restart them on play in the editor, and they keeping state according to Unity Editor preferences is also a very very terrible thing! All of that require ugly workarounds :(

[@jobinjeeji3502]

I'm not a pro but I use it for sending events from one class to another without having any reference between these two classes. You could search for scriptable objects events a lot of videos show up. But the way I use it, I don't like to use unity events instead I'll use delegates that way I can pass parameters easily as well. also, it is tiresome to assign functions on different objects rather than via code in my opinion.

[@lime_68]

I would never think that someone would try to save a scriptable object in runtime

[@Crowbar]

There are multiple talks from Unity people and other industry developers who highly encourage using scriptable objects exactly what you advise against to create a much more modular and extensible game architecture.

[@CodeMonkeyUnity]

There's a million ways to make games. Personally for my particular use case I find the cons of that approach to be much more significant than the pros, if you analyze this architecture and come up with a different conclusion then great! Use whatever tools help you make your games!

[@Crowbar]

@@CodeMonkeyUnity 👍

[@Crowbar]

@@CodeMonkeyUnity I just saw that you actually made a follow up video answering comments who already brought up this "problem", I will watch that

[@DwightPotvin]

Since it appears that my original comment was deleted as I was replying, here is a simple structure to properly serialize scriptable objects at run time without risk of overwriting their default values, making them ideal for serialization the runtime data for saving : public class FloatScriptableObject : ScriptableObject, ISerializationCallbackReceiver { public float IntValue; [NonSerialized] public float RunValue; public void OnAfterDeserialize() { RunValue = IntValue; } public void OnBeforeSerialize() { } }

[@obviousgame]

@CodeMonkeyUnity people have send me this video and I will try to comment the best I can. It seems from the video that you never made a game using the Scriptable Object Architecture, if you did your message would be different. This video highlights only one aspect of ScriptableObjects (SO), the thumbnail is a click bait and it kind of gives a bad look to SO, even without the intention of doing so. SO are a tool, you can use in different ways, but using SO in Unity just for data storage is like driving a Ferrari in a parking lot. Your not using them at their full potential. For certain types of games and in a specific context, SO are the best solution for dev speed, dependencies resolution and modularity. I would be more than happy to discuss these claims on an open debate with you as I have detailed explanations and examples for each of these points. I would advise also anyone with an open mind to look into it, they are quite interesting, but maybe they will not match your game dev style! Feel free to check out my own version of the SO architecture : kzbin.info/www/bejne/oobFf4GFndyql6M PS: I sent you a voucher for my asset, but it seems you never used it. PS: you can totally use them for persistent data. you just need to handle saving and loading. PS: static fields... So I suppose you don't use the Editor Play Mode Option ? Best regards.

[@CodeMonkeyUnity]

Where is the clickbait in the thumbnail? It just says warning so you are aware of this one sneaky issue. No where in the thumbnail or title does it say "never ever use SOs!" I specifically said "Scriptable objects are great" Yes exactly it is a tool, and as a tool personally I only find it useful to use it as static read-only data storage. If you like using them for read-write that's fine, go ahead and keep using them. The only point of this video was to highlight this one particular quirk where they are persistent in the Editor but not in a Build, if you are already aware of that and you work around it then by all means keep using read-write SOs as much as you want, I'm not trying to stop you.

[@obviousgame]

@@CodeMonkeyUnity a warning sign is usually used to get the attention of people to warn about something dangerous. Maybe it was not intentional, but try to think of were such signs are usually used. That is not really the issue though, what I find disappointing is that you mention that "issue" and that you only use them as storage data. I remember when I started development, I would always follow youtuber tutorials (Brackeys) and followed everything that they said. Some people after seeing this video might stop to research and use SO in different ways just because that is the only information in this video. I see that your posted a second video and that, in that one, you mention Ryan Hipple's video, which Is great! I know it was not your intention, but when you expose an "issue" with a big warning sign on the thumbnail, make sure you put enough context and provide additional information so that people with limited knowledge don't get biased :).

[@lazysolutions]

I do want to just recommend a unity asset from a fellow publisher called "scriptableobject pro" by Steve smith, that by looking at is seems to do exactly what this video is about, saving SO at runtime. I have not tested it myself but still sharing the word here.