Be CAREFUL with Scriptable Objects!
Vložit
- čas přidán 28. 08. 2024
- 📝 Further Clarification • Follow-up: Should you ...
🎮 Synty Store BLACK FRIDAY cmonkey.co/syn...
✅ Get 70% OFF on Unity Black Friday! assetstore.uni...
📝 95% OFF on Cute Low Poly Assets cmonkey.co/hum...
🌍 Get my Complete Courses! ✅ unitycodemonke...
👇 Click on Show More
🎮 Get my Steam Games unitycodemonke...
🎮 Get the Ancient Empires Asset pack cmonkey.co/syn...
🔴 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.steampow...
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 unitycodemonke...
📝 Get the Code Monkey Utilities at unitycodemonke...
#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: unitycodemonke...
- Twitter: / unitycodemonkey
- Steam: store.steampow...
🔴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 czcams.com/video/CjJNeyyhsKs/video.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) czcams.com/video/7jxS8HIny3Q/video.html
Crafting Items with Scriptable Objects! czcams.com/video/E91NYvDqsy8/video.html
Simple Saving and Loading with JSON to a File czcams.com/video/6uMFEM-napE/video.html
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.
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
@@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.
@@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.
@@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.
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.
Yup that's definitely great advice, test often on your target platform.
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.
ya, and on multiple machines if you have that available to you. UI and framerate issues might present themselves
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.
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.
@@Sindrijo would simply using Instantiate suffice to clone a non-nested ScriptableObject that way?
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.
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!
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? 🤔
@@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.
@@gabagpereira Ok I see your point, but couldn't the same be achieved with a regular class and serialized fields?
@@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.
Oh, that's honestly good to know that one should also test outside of the editor.
I'll keep this in mind.
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.
Code?
@@3333218 check the Ryan Hipple talk, he also posted his test repo.
@@Xyckno Thanks!
@@3333218 you can also check out Atom. I use it almost everyday.
@@pandaengine Link? (I sincerely don't know what Atom is; and I suspect you're not talking about that text editor are you?)
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.
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).
While this is true, at that point there's really no real reason to use a scriptable object over a normal C# class.
Then you don't need a SO if this has to take data from some external file or DB.
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
@@DreadKyller You can't drag and drop regular C# objects, but you can do that with SOs. That makes a big difference in workflow.
@@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.
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!
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.
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.
Man you potentially saved tons of minutes who check this stuff by building the project ty
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.
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!
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
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:
czcams.com/video/raQ3iHhE_Kk/video.html
Open Source project that greatly expands the ideas from the Unite Talk
unity-atoms.github.io/unity-atoms/
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.
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.
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 😂
Heh yeah it is definitely a very sneaky issue that can drive someone crazy until you can figure out what is going on.
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.
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!
Thank you! Was about to try to implement saving settings info in a scriptable objects.
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.
Do you have an alternative that would be more effective and would be able to be saved and loaded?
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.
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.
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.
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!
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!
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
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: czcams.com/video/raQ3iHhE_Kk/video.html
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!
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
you tried
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
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!
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.
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....
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.
Had this experience years ago. Thanks for clarifyiing that, I learnt that on my expense
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.
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.
Are there other things that vary from editor to build?
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.
@@syriuszb8611 omg thats awful.
Is it fixed if you manually set up script order?
@@juicedup14 Oh, forgot to write, in the project settings, yes it fixes it.
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.
Thanks for this! You just saved me a big headache. I'm literally about to tackle the problem of saving my inventory system.
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.
Hey Code Monkey! May I ask which keyboard you use? I love the click sound :D
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
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.
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
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.
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.
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.
@@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.
@@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
@@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
@@nullx2368 have you watched this? czcams.com/video/raQ3iHhE_Kk/video.html
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.
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.
if you want not lose data between scenes in ScriptableObject you can use "private void OnEnable() => hideFlags = HideFlags.DontUnloadUnusedAsset;"
Oh that's an interesting tip, I've never used that, sounds like it works similar to DontDestroyOnLoad for Game Objects?
@@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".
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
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.
Like others have mentioned, ScriptableObjects can definitely be used for save data, they just have to be managed properly.
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.
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?
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
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.
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.
@@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.
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.
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.
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.
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.
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.
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
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.
@@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.
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.
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?
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
@@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!)
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.
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
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.
💯 agree, it's really better to keep SO and saved data separate. Much easier to manage and extend overall.
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?
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.
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"
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
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 :(
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.
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
I am not sure why many developers have strong opinion against using Scriptable Objects for anything other that a data holder.
Scriptable Objects are basically an asset that contains code, which means, it can be used in various and creative ways.
The "standard" usage of a scriptable object is boring, but what about forgetting about it and actually using the tool for what it can do extremely well:
- solve dependencies between your classes
- transfer data between scenes
- make your code more reusable
- increase the speed of the development
Most people I have seen advocating against scriptable objects don't like them for personal reasons, and that is totally understandable. I mean it is a different style of using Unity and its not everyone cup of tea. But once your know them well and use them for what they do best, they can empower and solve a lot of issues.
I find it weird to advocate people to not use a tool in a certain way. Try it yourself, brake it, and then decide to use it.
An excellent asset for using Scriptable Objects practically to save time and solve dependencies is Soap:
assetstore.unity.com/packages/tools/utilities/soap-scriptableobject-architecture-pattern-232107
PS: You can totally save the value of variables using SO and make them persists in between application session! I have been doing that for years... You just need to be careful about your initialization flow.
That probably made me kinda confused....?
I probably mean do I use it
@@gdtutorial Well you should try !
What Code Monkey is suggesting here is quite misleading, and I strongly disagree. ScriptableObjects should not just be used for "static data that never gets modified". It can be very well used for systems like inventories or any other kind of systems.
What he is actually trying to say is that, SO should not be used to **PERSIST** data between game runs. A "SO InventorySystem" needs to be initialized from a save file when the game is loaded, and its data needs to be serialized and persisted inside a savefile when the saving process occurs. But to jump from there, to saying "never mutate the values of a SO during runtime" is a huge leap, and in my opinion, terrible terrible advice.
Using SOs as systems is a GREAT idea, and it is not only me who says it. Do not take my word for it. Unity staff itself has recommended it. Look at this workshop from the Unite 2017 conference (link direct to the relevant section of the talk):
czcams.com/video/raQ3iHhE_Kk/video.html
Yes you're right you can use them for data that changes as long as you are very aware of this limitation and don't assume that it will persist in a build like it does in the editor.
That talk is indeed great, I have seen it several times, it's an interesting architecture although as with anything there are pros and cons.
So personally I stick with read-only SOs, if I want to modify the state I store the state in a regular MonoBehaviour, if I want to share data between scenes I use static variables.
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
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
That is a valid use case. I suggest you to check out ScriptableObject architecture.
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() { }
}
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.
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.
Yup for Editor scripting writing to SOs is an excellent use case
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.
I dont understand why someone would want to use a scriptable object as a saving system. Making a binary save file is just as easily done and I would assume more protected.
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.
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.
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!
@@CodeMonkeyUnity 👍
@@CodeMonkeyUnity I just saw that you actually made a follow up video answering comments who already brought up this "problem", I will watch that
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.
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
@@CodeMonkeyUnity thank you! I will check this out today cheers ! Ive just been struggling a bit with this. So this will help.
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?
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.
@@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!
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
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.
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?.
the idea never came up to save the progress of the game in a scriptable object.
good
I feel like every unity developer tries turning SOs into a save system at some point. It's like a right of passage.
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)
Heh yup sou Português!
Serialize the so to the json on disk would save properly.
Cool, can you make tutorial on something like day-night cycle with scriptable objects
it always boggles me what the unity dev team are thinking...
Unity has been arround for 18 years..
and there is still not an official all round solution of a save system for their games...
all the current solutions that i know are tweaks around a flaw design.
PlayerPrefs - blah ..everyone says dont use it...and got frown upon when caught using it.
JsonUtility - extra work
EasySave 3 - $$$
SQL - $$$ or suicidal
when they made this scriptable object, everyone (at least normal ppl like me) would think it can be use to save file on build...but no... they decided they have to stop there....why.....unity ...why....
Any developer who pushes out a mechanic without testing it in the final environment needs some serious help.
Heh it can definitely happen as the release date approaches and you're rushing to get everything done
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.
Thanks! Now I can stop wasting time trying to find out how to make a save system for scriptable objects lol
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?
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.
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
you are one of the best unity user
I would never think that someone would try to save a scriptable object in runtime
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?
Once you close and reopen the game, the data you modified in the csriptable object is gone, it will not persist
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.
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
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?
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.
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.
Yes if you save it onto a persistent file before you quit the game and load when the game stats then yes
i realized this fast, so i created a system making the scriptableAsset load data on start
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.
I was about to make the money system of my game using ScriptableObjects, now I see it's a bad ideia, thanks!
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?
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.
@@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?
Can I use open('filename.ext', 'r+') in unity....?
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.
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.
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.