Follow-up: Should you be CAREFUL with Scriptable Objects? Read-Only or Read-Write?

[@CodeMonkeyUnity]

✅ Original Video: kzbin.info/www/bejne/a5KQq6eZasyWfNk Game Dev Show kzbin.info/www/bejne/mKHIfoihgqmMbdE Game Architecture with Scriptable Objects kzbin.info/www/bejne/qJK0ZJx-naqSgc0 🔴 RELATED VIDEOS 🔴 Be CAREFUL with Scriptable Objects! kzbin.info/www/bejne/a5KQq6eZasyWfNk Scene Manager in Unity kzbin.info/www/bejne/aXqYlWWoiq9jpqc My Game Dev Journey (40+ Games! | mIRC to Flash to Steam) kzbin.info/www/bejne/ZqvWlIOclLpkjLs Make your Games Designer Friendly! (Scriptable Objects) kzbin.info/www/bejne/bZvbhGt-ftOsabM Crafting Items with Scriptable Objects! kzbin.info/www/bejne/e2qUf4ysedamr5o Simple Saving and Loading with JSON to a File kzbin.info/www/bejne/bKawd3iDYtOUpqc

[@kaasronald3623]

making an entire video dedicated to correcting a mistake in the last video shows how reliable all your other videos are. thx for the hard work. feel like you've been at it real hard for the past year and i love all the news recaps and asset store highlights :)

[@enriquemorenotent]

Excellent video complementing the previous one. I am glad that you made it. I even learned a couple things I didn't know about SO! Good job, CM! 10/10

[@darkfafi]

Regarding the ScriptableObject unloading issue. You can prevent this by writing `hideFlags = HideFlags.DontUnloadUnusedAsset;` in the object's Awake I used a very dedicated ScriptableObject architecture while developing a game for a company. And this, along with a system to reset the values, made it a very strong tool. To reset values, I made it so in the editor, on Enter / Exit Play mode, I call a custom Deinit method which disposes any values and references out of the object.

[@lochraleon6660]

I went through the comments to make sure someone mentions this. Can confirm, SO are intended to unload for memory management and dontunloadunsedasset is how you make them persist between scenes etc.

[@QuangNguyen-lf4lu]

Thanks for the videos, these 2 videos help me a lot with my understanding about SO. Personally I think this is more of a "personal preference" than a "mistake". People just assumed "Be careful with" equals to "Do not use" and then decided that is "clickbait title". How funny that is! Dont bother with those who cant tell the difference, and keep up ur good work.

[@CodeMonkeyUnity]

Yup it really is personal preference, personally I would never use it but different people work in different ways

[@Paul-to1nb]

Great video! Another negative of using Scriptable Objects for runtime data (or small variables) is that they're essentially global objects - you can access them anywhere. At first it's an advantage. Quickly making codeless changes work. Editing values at runtime. Easy sharing data between objects. But, one of the first things we learn as coders is to avoid global variables because changes to them can become unpredictable, hard to track down, etc. In Ryan Hipple's system, every FloatVariable becomes a global variable. It can become very messy if not used with caution and care, especially on large teams. I have done this extensively in a project and it worked well for that project, but it was definitely a mess after I had thousands of scriptable objects. While I could definitely do it better a second time, knowing the pros/cons, I was much happier after I decided not to use Scriptable Objects like this in my later projects. So, I'm with Code Monkey on this, if you're a coder, just write code. It's much faster in the long run. I'll also highlight one negative he pointed out: using SOs for runtime data doesn't work well for having a dynamic number of units. Think anything where each unit has changing variables (like pokemon, FF7 materia, league units, etc). You could get around this by Instantiating SOs at runtime, basically copies of existing ones, but you lose many advantages of the SO system (drag and drop references). The natural extension is like the Gameplay Ability System in Unreal, where the SOs represent Attributes (health, atk, multipliers) and an AbilitySystem on an Object says which Attributes it instantiates. This seems like an interesting system to me that I haven't had a chance to use, but it's still fundamentally rooted in this global SO state. It can make things really messy, but extensible and allows designing without programming. Pros and Cons to everything.

[@pierredalaya444]

Happy to see that you added a video to try to correct the previous one. I would have added that this "quirk" as you say is not exclusive to SO, its the same for most assets, because that is how assets are supposed to work. Finally, another point that has to be corrected : you can totally prevent SO to unload from memory if you want to pass them between scenes even without keeping a reference to it, just add this: private void Awake() { hideFlags = HideFlags.DontUnloadUnusedAsset; } I know you are trying to help by posting instructional videos, but in this case, it feels like this can lead to confusing juniors developers that follow your channel.

[@ghwii]

I use ScriptableObjects all the time to define behaviours for my game elements. For example, if I want a special ability for the player, which can be changed during runtime, I have the method inside a ScriptableObject of class "SpecialAbility". This way, I can easily hook up the method to any players and swap them dinamically. Great video!

[@goldone01]

Thanks for making this video. I also felt like you had oversimplified your statements in the last video - great to see you following up and clarifying things!

[@jacobs.7925]

This is a great topic for discussion, we're all growing and learning from different opinions - lots of constructive feedback from our great community :) Well done!

[@shahzadansari849]

I Strongly Agree what you have said , Scriptable objects usage was not the title of the video you uploaded , the main focus of that video was to make people aware of its behaviour which you have explained perfectly , well done CM

[@Kaikaku]

I fully agree on that the comments section on your videos is often very helpful, with either you or someone else adding context or answering questions.

[@Cameo221]

The explanation of the cons in the video puts this very well and exactly aligns with my thoughts from the last video. Large projects can have up to thousands of objects for every project and can get really heavy, and the dev ends up entirely leaning into that system. Becomes more congested the larger a project gets, but will more often bring benefits in jam projects for instance. If there's any takeaway from this, it's to use a system if it proves to save time, and not due to hype.

[@phoenleo7798]

Thanks for the Scriptable Object video and this update video, I learned a lot of things both from your videos, and the comment sections Keep up the good work 👍

[@JohnWellingtonWells]

I used them heavily in one of my previous project for things like events and variables, but things just ended up being kind of needlessly complicated and hard to manage and debug I found. So now I'm back to pretty much exclusivity using them as static data containers(with a few simple methods for getting data and so on). In most cases I find that good use of composition and interfaces, a simple C# event or UnityEvent(especially nice for building UI) is way easier to manage once your game grows in size.

[@MathsPlusGames]

Amazing dedication to accurate information, much respect

[@amrosk]

For storing data like weapon stats I prefere to read from a JSON file so I don't tie it to unity, can edit it with whatever software I want including my own, and can event build upon this system to allow for mods.

[@CodeMonkeyUnity]

Yup if you want to make your game moddable then external JSON files is an excellent way to do it

[@mohakjain5802]

Making an entire video to correct your mistake shows how devoted you are 👍👍

[@devzozo]

Thank you for posting this clarification!

[@Gaban_]

Good job making a video to clarify the previous one and admiting you were wrong We need more content creators like you

[@GaryParkin]

Thank you for all the time it took to make your videos. I just found your channel (Subscribed). I'm binge watching tutorials, trying to get up to speed quick. I just started using Unity coming from Unreal and Godot and 15+ years in C#, 35 years as a developer. I'm unclear on how you persist a variable between scenes? I first used a Singleton, found out it works but is a lousy pattern, then a static class, again, it works. Next I watched that talk and tried Scriptable Objects, and I'm thinking about events, but all of these require references to each other. What's the right way please for a single developer?

[@CodeMonkeyUnity]

Welcome! I hope you find the videos helpful! The easiest way is make it static, either a static class or just a static field, normally that's what I use although I design my games to use pretty much a single GameScene. Alternatively you can use a regular GameObject with a regular MonoBehaviour and call DontDestroyOnLoad(); which will make the game object persist through scene loads.

[@GaryParkin]

@@CodeMonkeyUnity Excellent! Thank you. I'll try that this afternoon.

[@kruth6663]

Hi, how would you make an item database with hundreds or even thousands of item types, that has certain hierarchy of item categories (like in Terraria and many other games), and is easily expandable and updatable? I've watched many of your videos and some other videos. Adding code line by line into one c# script, or adding a scriptable object for each item type, neither of these seem quite right to me. (Also if possible, may I ask how would you build a save system for that.)

[@fornonplayers3668]

what a humble person, hats off to you CM!

[@Deadener]

You know what they say, if you want extremely detailed information on a subject, don't ask a question, just post slightly incorrect information in a confident manner, and the whole hornets nest will dive at you with information so detailed, it would make the documentation writers blush.

[@Gortart]

What CM said : SOs don't automatically save data to the disk in built app, but will do that in play mode, so be careful and test your game in built version too. Commenters : But you CAN save data with SO by using other external methods that any other classes(even good old POCOs) can use or a glorified global variable that all programmers discourage you from using so you don't make spaghetti codes! That wasn't even the point of the video. SOs are just assets that you don't get file access(just like other assets) and their whole point is to be a data holder. You can use it to hold runtime data(so you use it to store the pointer rather than the data itself) but in order to make them do more, you have to jump through hoops like instantiating new SOs which makes as much as sense to instantiating a new texture file. And at this point, you'd better off just using POCOs do the same job more smoothly.

[@oldcat1790]

Tbh that's a bad design when object works differently in editor and in builds, unless it's editor-only functionality such as custom inspectors.

[@DrHeinzDoofenshmirtz]

Is it correctly understood that if you change a non-serialized runtime value on a Scriptable Object, both in Play and Editor mode, the value will not be written to disc and only exist in memory?

[@CodeMonkeyUnity]

Correct, any non-serialized data, like a reference to a class object, will not be stored anywhere persistent, only in memory. The next time you hit Play that reference will start off as null.

[@phodaOG]

So inventory system is better used as static field? It wont be collected by garbage collector if no reference is used? Also easier access?

[@CodeMonkeyUnity]

If you wanted to keep the inventory in memory through multiple scenes then yes a static field will do that. If you wanted to clean it up you would set that field back to null.

[@bartomiejjarosz8979]

But you can still use SO and make a reference to inventory UI or/and grabbing system (to refer what inventory should be use). Or if you make a singleton from SO, you can add SO to "preloaded assets" in Player Settings. The static variables has weak points too.

[@undeadpresident]

I'm wondering if you could make a video about the things to know when programming a game for consoles vs pc's. Also something I've been wondering but can't seem to find much info on, is what to know about copy protection when you market your game. Like how does a website like steam prevent people from just downloading the game then refunding it but keeping the files and continuing to play it? I'm pretty new to programming (about 6 months) so there's a lot I don't know.

[@CodeMonkeyUnity]

Specific console dev things are usually hidden behind an NDA so you can't find much info on that. But for the most part the big difference is just input, Gamepad vs MouseKeyboard. If your game is already Gamepad based then it's pretty much just learning their SDK. Don't worry about copy protection, it's not worth your time, instead spend that time making the game the best it can be. People who really want to pirate your game will do it regardless of how much protection you try to put in, so don't waste energy trying to stop that, just focus on the people that will actually buy your game.

[@undeadpresident]

@@CodeMonkeyUnity thanks!

[@TheRealspoingis]

I have a question Lets say I have a WeaponItem scriptable object that has dmg value when the player picks up a new weaponitem it serializes a new one into the invenotry and changes the value from 1-5 so if i pick up 5 weapons they might all be different If I make a save system that saves the inventory would it not be able to save the weapons?

[@CodeMonkeyUnity]

Not sure what you mean by "serializes a new one into the inventory", Serialization means converting into text/bytes. Do you mean you add it onto a list? You would save some identifier for the scriptable object, and the damage amount. I covered a save system here kzbin.info/www/bejne/bKawd3iDYtOUpqc

[@joaopacheco2240]

Thats great! I was worried that my system of character costumization where I have a scritable object as a holder for each part of the body, also a scriptable object would not work at all in a build.

[@bluzenkk]

support~ gd job~ i just wish there is an easier way to save persistent data...on build...using SO...

[@lokosstratos7192]

hey code monkey have you had any experiences with making webgl games in unity and release it on sites like armorgames etc? is this worth doing?

[@CodeMonkeyUnity]

I only tried that about 10 years ago when I was making the transition from Flash to Unity, haven't done it since then. But it should be as simple as making the WebGL build then uploading a zip of that folder to their website

[@TheNoobGameDeveloper]

I'm now confused between both videos. Besides accessing read-only data, what are its uses now that I can't write to SO in the final build?

[@CodeMonkeyUnity]

The main thing to remember is that in a final build the data you save to the scriptable object will not persist after you quit the game. Whereas in the Editor it will persist. If you have a SO with an int with a starting value of 5 and you play the game and during runtime you save the value 7. If you restart the game in the Editor, the next time it will start with the value of 7, whereas on the build the next time it will start with the value 5. So basically you can do anything you can do with any other data in memory, like for example a regular C# class or a MonoBehaviour. Some people like to use SOs as data storage and modify that data in runtime. Personally if I want to modify data in runtime I just use a regular C# class or a MonoBehaviour instead.

[@bartomiejjarosz8979]

Like a person mentioned in video, I can answer. I like to use SO's like a "container to data exchange". E.g. my player has a health. I want to show the health value in UI. Player prefab and UI prefab are different prefabs. I need to make that UI shows Player statistic. How can I connect them? 1. I can make drag-drop reference on the scene. It's the easier way to do it but I think that it's bad practice. Because in prefab view I see that field is empty in the component and I need to remember that I need to connect the things on the scene. And I need to override the scene (problem for merging - if you need to override scene in any small case, then everyone want to override the scene and it makes conflicts). 2. You can use I SO like a "connector". You can add the SO reference directly to the Player and UI prefab. The artist can make a UI, connect the SO like a slider value, modify SO and see result in no-runtime mode. But if you put the Player to the scene and click "Play", the data is override by Player script and you see the proper value. 3. You can use custom scripts. But you need to write a lot of scripts for any use case. You can find Player because the Player is singleton (it's popular way but singletons has some weak points). Or you can use FindObjectOfType or Tag. But it have an impact of performance. Especially if the object is often spawned in runtime (eg. projectile which damage depends of your health value (in SO workflow you can easily change health to other statistic)) I don't want to say that using SO for this use case is the best option ever. Rather I can say that it is not. But the good developer should know a lot of possibilities to find the best solution for the problem. I think that the workflow is bad for multiplayer games (but still can be only good for local user UI - because iteration time for modify UI is great!). It can be bad for games with a lot of objects (like strategy games that your all UI must be dynamic). But it can be good for e.g. settings (even gameplay settings) because you can easily debug and modify data in Editor and made a custom window for that. So, you need to understand pros and cons SO and use them like a great tool ;)

[@ziyaadpetersen2743]

Thank you for making this video to correct the mistake

[@TurderaTommy433]

I use only for read only data...works good for 2D platformer game....probably for games more complex make other approach, but I prefer just for onlyread data

[@LookjaklooK]

I personally use Unity Atoms as my Scriptable Object Architecture plugin. It's the best one I've seen so far on the internet, and its free. If anyone interested.

[@stevesmith.software]

Sir, you are a fellow professional, for which Ii salute you. Please do reach out to me.

[@GamesAreArt1]

i didn't watch the previous video but i agree with all you said, personally i use SO as data container, Save/load System, event at runtime for Dynamic data, Testing, etc. my advice explore the SO more to take advantage from it trust me it will make things easy as long as you know what you are doing.

[@SaudBako]

Maybe the issue is the ambiguous video titles

[@BeardBarians]

If I wont the lottery, one of the first things I'd do is buy all the synty assets, they look AMAZING!

[@RayHorn5128088056]

Scriptable Objects are persistent while the game is running are they not?

[@CodeMonkeyUnity]

Persistence usually refers to the data stays when you quit the game and start again, they do not persist like that. The only "persistence" they have is while they are in memory, just like any other class or object. Once it's out of memory the data is gone.

[@CappySmack]

@@CodeMonkeyUnity If the data was purely in memory, there would be no file created for each scriptable object, yet there is, go figure.

[@ltecheroffical]

Quick note for the reason why he created a follow up: Editing a video in youtube after publishing is impossible as of writing.

[@CodeMonkeyUnity]

Yeah, I really wish they allowed that, I get that it can be abused but I doubt most serious channels would abuse it

[@SuperCaitball]

There I am Gary! There I am!!

[@S_Tadz]

I kinda thought you dropped the ball yesterday, but I think we are all so effin* ready to forgive you that slip, given the amount of stuff you do for the community. It's bound to happen to everyone every now and then, don't worry too much about it, mate! Have a nice day

[@EskChan19]

I really don't understand why people had this wrong idea though, he never said you can't write to SO, he only said they don't save between sessions, which they don't. And then comment section took that and decided he had said to never write to SO ever. The comments dropped the ball,not him. He just pointed out something that people should be aware of. He never said not to write to SO, just that you can't make a save system with them despite the Editor making you think you can. Everything else was just the comment section trying to put words into his mouth.

[@S_Tadz]

@@EskChan19 Nah man, I was in the bus just listening to the audio, not reading the comments at all, and I was going 'hum... that doesn't sound quite as right and rigorous as it should...' Sorry if I hurt your bf's feelings

[@h.m.chuang0224]

@@S_Tadz Are you high?

[@S_Tadz]

@@h.m.chuang0224 im sorry you think I insulted your godly-unfaillable boyfriend

[@saqibbro5297]

you are amazing

[@yakinmurat]

I do aggree you Code Monkey. The statement scriptable objects can be used to store save data is misinterpreting the nature of those objects, and therefore, irresponsibly misleading behavior. I first encountered such a claim in one of the videos of the developer about who you provided a visual. I was able to guess the misinterpreted behavior of the object in build and never used such a way to save my data. That was an old youtube video that I am talking about. Surprising that no one mentioned this problematic behavior until this time and until you. Again, surprising that only a few can see this disinformation or in best case untested, half information about saving data with scriptable objects. It is like night and day, and all of the other things are irrelevant. I personally thank you for showing the fact I have and could have never spent time to prove what I had been suspected. We need more like you who wants to talk about the whole truth, not half of it. For those broadcasted the half version: man, test it before the show, at least once; and do not only test in editor, also test in build, then speak to people! I expect a similar correction video like you did from those people, too. We will see if they are brave enough to mention their faulty behavior about this. Again, irrelevant all of the other uses... The subject is (and was in those videos) "you can save your data with scriptable objects". See that you can not! But it is too late, right? They did broadcast that untested information, and now the king is naked! Again, we will see if they will make an apologize video for their unprofessional behavior. Thank you Code Monkey, for revealing and sharing the truth. We need more like you.

[@322ss]

This info about SOs not persisting is well known, only that many KZbinrs and beginners watching these tutorials don't know this and will repeat and perpetuate this claim. I've personally mentioned this several times in comments (and I'm probably not the only one), like IIRC GredDevStuff's tutorials (maybe year or two ago), where he was building a save system, after this, the author realized he didn't know the fact that when he reloads the build, the values of SOs are reset back to what they are in the build files. He then mentioned this in the next video.

[@nTu4Ka]

That moment when trying too hard with clickbaiting title backfired.

[@CodeMonkeyUnity]

You're the third person to mention "clickbait" but where on earth is the clickbait? I'm very confused... The title says "Be Careful" and the thumbnail says "Warning", in the video I warn you to be careful about one particular quirk of Scriptable Objects. It literally describes what I'm talking about in the video, where is the bait?

[@googleuser4720]

I thought I was the only one disagreeing with you in a David vs Goliath scenario, but now that it is revealed to me that actual Unity developers wrote what I essentially put forward to you, it has reinforced me confidence that you indeed don't actually have the industry experience to make a game that's not just a small indie prototype. You'll understand when you get more experience working for other companies where you don't necessarily have the creative control comparable to owning your own business and have to work within constraints.

[@CodeMonkeyUnity]

I have no interest in working at a large company so that's not a question of "when" I'm perfectly happy building my own games using the tools in the way that make sense to me. Just because someone else uses a tool differently from you doesn't make it better or worse. The goal with a tool is to enable you to do something, if you can achieve your goals there's no such thing as "wrong" usage.

[@googleuser4720]

@@CodeMonkeyUnity Ok but your previous video is major clickbait. I think it was something like "Why you shouldn't use Scriptable Objects in your game" or something like that

[@CodeMonkeyUnity]

​@@googleuser4720 Um no, the video has always had the title "Be CAREFUL with Scriptable Objects", at no point do I say you shouldn't use them at all, exactly the opposite, I specifically say they are an excellent tool that you should use, just be aware of this one particular sneaky issue that will drive you crazy if you don't know about it.

[@googleuser4720]

@@CodeMonkeyUnity The back-pedalling is serious with this one!

[@abalorias333]

Ace! 🎉

[@ЭдуардКик]

great

[@vincewa2142]

How dare you make a mistake. I come here to be taught new techniques for free. Not told lies. Ugh I'm so disgusted. Love the video btw. As always keep up the great work. For those who can't tell sarcasm. The above was a joke. The part about loving the video. The other stuff I ment. J.k

[@SunSailor]

Tbh, I really would encourage you to delete both videos and make a proper one. I really respect your aim for correction, but I feel, even this video doesn‘t do the topic justice, especially with your courses in mind. There are several videos, even from Unity themselves, available, which Transport the potential of ScriptableObjects and so should you. Further, mixing ScriptableObjects up with the topic of game saves didn‘t help either.

[@322ss]

How about you make the video.

[@Lemon-dh4fz]

White theme youtuber😢

[@CodeMonkeyUnity]

Yeah, dark mode burns my eyes, sorry

[@jud.su.5developer895]

First

[@wolfrodah]

second

[@dannykay4649]

If you use [System.NonSerialized] on variables in scriptable objects, those variables aren’t saved.

[@EskChan19]

I really don't understand why people had this wrong idea though, you never said you can't write to SO, you only said they don't save between sessions, which they don't. And then comment section took that and decided you said to never write to SO ever. The comments dropped the ball,not you. You just pointed out something that people should be aware of. You never said not to write to SO, just that you can't make a save system with them despite the Editor making you think you can. Everything else was just the comment section trying to put words into your mouth. Still good to post a follow up so all the idiots who willfully misinterpreted you can eat their words.

[@bartomiejjarosz8979]

The first video at 7:45 - "use them only as a read-only data container". The summary can make someone wrong that e.g. "Game Architecture with Scriptable Objects" idea is incorrect. The idea of first video is "be aware that SO can works different in editor and build". And this is good advice in general. I remember that on gamejam, I decide to define all SO's in single *.cs file. And this worked fine in editor but not in the build. ^^