Be CAREFUL with Scriptable Objects!

Рік тому

📝 Further Clarification • Follow-up: Should you ...
🎮 Synty Store BLACK FRIDAY cmonkey.co/syntystore
✅ Get 70% OFF on Unity Black Friday! assetstore.unity.com/?aid=110...
📝 95% OFF on Cute Low Poly Assets cmonkey.co/humblebundle
🌍 Get my Complete Courses! ✅ unitycodemonkey.com/courses
👇 Click on Show More
🎮 Get my Steam Games unitycodemonkey.com/gamebundle
🎮 Get the Ancient Empires Asset pack cmonkey.co/synty_ancientempir...
🔴 RELATED VIDEOS 🔴
Make your Games Designer Friendly! (Scriptable Objects) • What are Scriptable Ob...
Crafting Items with Scriptable Objects! • How to Craft Items wit...
Simple Saving and Loading with JSON to a File • Simple Saving and Load...
💬 Scriptable Objects are an excellent Unity feature, they let you store data in discrete files, super useful for defining things like Items, Weapons, Skills or event some Level Data.
Definitely learn about Scriptable Objects if you've never used them.
However as amazing as they are, they are NOT supposed to be used to save data, they are intended only for Read Only data. If you try saving data in a Scriptable Object you're going to have some very confusing issues when you make your final build.
📝 Some Links are Affiliate links which means it costs the same to you and I get a nice commission.
🌍 Get Code Monkey on Steam!
👍 Interactive Tutorials, Complete Games and More!
✅ store.steampowered.com/app/12...
If you have any questions post them in the comments and I'll do my best to answer them.
🔔 Subscribe for more Unity Tutorials / @codemonkeyunity
See you next time!
📍 Support on Patreon / unitycodemonkey
🎮 Grab the Game Bundle at unitycodemonkey.com/gameBundl...
📝 Get the Code Monkey Utilities at unitycodemonkey.com/utils.php
#unitytutorial #unity3d #gamedev
--------------------------------------------------------------------
Hello and Welcome!
I'm your Code Monkey and here you will learn everything about Game Development in Unity using C#.
I've been developing games for several years with 8 published games on Steam and now I'm sharing my knowledge to help you on your own game development journey.
I do Unity Tutorials on just about every topic, Unity Tutorials for Beginners and Unity Tutorials for Advanced users.
You can see my games at www.endlessloopstudios.com
--------------------------------------------------------------------
- Other great Unity channels:
Unity - / unity3d
Brackeys - / brackeys
Dani - / @danidev
Jabrils - / @jabrils
BlackthornProd - / @blackthornprod
Sykoo - / sykootv
Jason Weimann - / @unity3dcollege
Jonas Tyroller - / @jonastyroller
--------------------------------------------------------------------
- Website: unitycodemonkey.com/
- Twitter: / unitycodemonkey
- Steam: store.steampowered.com/develo...

КОМЕНТАРІ: 297

@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 ukposts.info/have/v-deo/e5p7gpuwsJ6krKc.html 🎮 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) ukposts.info/have/v-deo/b5qph25_gKSqlIU.html Crafting Items with Scriptable Objects! ukposts.info/have/v-deo/fWligo-te6ek2mw.html Simple Saving and Loading with JSON to a File ukposts.info/have/v-deo/bqV-enuEZKSS0Xk.html

@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.

@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?

@gabagpereira Рік тому

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 11 місяців тому

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? 🤔

@gabagpereira 11 місяців тому

@@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 11 місяців тому

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

@gabagpereira 11 місяців тому

@@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.

@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.

@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!

@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.

@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?)

@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.

@randomragtags1021 7 місяців тому

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.

@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.

@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.

@MatthewChowns Рік тому

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

@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!

@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.

@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.

@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.

@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.

@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: ukposts.info/have/v-deo/qpGCZ59_n3uQrJ8.html 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.

@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.

@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.

@this-is-gamedev Рік тому

💯 agree, it's really better to keep SO and saved data separate. Much easier to manage and extend overall.

@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.

@That1GuyUHate 3 місяці тому

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 3 місяці тому

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

@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.

@Fyres11 Рік тому

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.

@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: ukposts.info/have/v-deo/qpGCZ59_n3uQrJ8.html

@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

@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....

@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

@coreyholt8522 10 місяців тому

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 10 місяців тому

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 10 місяців тому

@@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!)

@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.

@Luvseatshawty 8 місяців тому

Thanks! Now I can stop wasting time trying to find out how to make a save system for scriptable objects lol

@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.

@keropaci 2 місяці тому

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

@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

@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!

@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 28 днів тому

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

@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

@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.

@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.

@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.

@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.

@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!

@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

@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.

@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.

@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.

@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

@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.

@fakiirification 10 місяців тому

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 10 місяців тому

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.

@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

@joshswanson0 6 місяців тому

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 6 місяців тому

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.

@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.

@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.

@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

@titan2969 Рік тому

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

@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.

@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.

@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.

@strahinja1910 Рік тому

Cool, can you make tutorial on something like day-night cycle with scriptable objects

@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".

@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!

@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.

@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? ukposts.info/have/v-deo/qpGCZ59_n3uQrJ8.html

@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

@tomtomkowski7653 Рік тому

It's not a bug it's a feature - sounds familiar xD But the truth is that SOs are great for storing static data, like icons, prefabs, sounds, gold costs, attack power, the name of the object, enums of the type of object, etc. But wouldn't be perfect if Unity has such a built-in saving system, where you can create SavableObject which would be automatically serialized and saved with two save/load mandatory functions inside?.

@jud.su.5developer895 Рік тому

لا تغيب عنا 🌹🌹

@logiis2377 Рік тому

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.

@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

@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

@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?

@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() { } }

@TeppuTeppu Рік тому

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

@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.

@GypsyTinker2012 Рік тому

Check out "Scriptable Object Pro" on the Asset Store! Great dev and support too. I'm not affiliated with them at all, but also use their database product. Good stuff! Makes scriptable objects what they should be and allows more data types.

@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.

@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

@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!

@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.

@zak-ks7ee 10 місяців тому

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 10 місяців тому

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

@lime_68 Рік тому

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

@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?

@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

@romeu_ 10 місяців тому

I was about to make the money system of my game using ScriptableObjects, now I see it's a bad ideia, thanks!

@devforfun5618 Рік тому

i realized this fast, so i created a system making the scriptableAsset load data on start

@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!

@swoolfeek3709 Рік тому

Thank you I have save system on scriptable objects which I made 3 days ago

@darkenedsky665 Рік тому

Thanks! It was really helped.

@tobias8951 Рік тому

You didn't even watch the video.

@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

@kostaskompostas8046 Рік тому

Oops I was doing this! Thanks for the tip

@patek2385 3 місяці тому

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 3 місяці тому

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

@PTKDWA 3 місяці тому

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

@CodeMonkeyUnity 3 місяці тому

You can see how I used scriptable objects to define the building data in my Grid Building System video ukposts.info/have/v-deo/nKWdo6l_h6Jpk3U.html

@eterlan2538 Рік тому

Serialize the so to the json on disk would save properly.

@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.

@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 9 місяців тому

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 9 місяців тому

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