Rethink Everything with Scriptable Object VARIABLES

[@oOAjjOo]

This is helping me understand the value of scriptable objects. When my games get more complex I get so frustrated because one missing piece can stop the entire game from working. You end up spending hours just to realise you didnt put an "s" in the right place, lol.

[@BMoDev]

Haha, yup - the better you get at programming the more you realize how important code design is

[@MercenarySed]

A game changer in game development for me was learning design patterns. Try the observer pattern in this situation. Trust me. Good luck!

[@VoonNBuddies]

I think it would have been nice to expand on Hipple's initial talk. Your presentational style is great and easy to follow! But there honestly isn't any information here that isn't present in the first talk. And that was 6 years ago. There are questions that this pattern raises: How do you handle multiple values? If there are more than one characters with health values, how do you handle that? How do you handle Scriptable Objects' data persistence when editing? How do you track down unused variables? It would have been nice to explore some of these questions or at the very least give an example of another use case besides the one that Hipple already gave. The quality of this video is high but at the end I'm left wondering, why make this video? I'd honestly rather hear your thoughts and ideas on the pattern than just hearing Hipple's again in your voice.

[@ParkingLotStudioGames]

same thought, this just slipped to my recommended after watching Ryan's talk and he just repeated exactly what Ryan said and used the exact same examples...

[@krishnarai4854]

@@ParkingLotStudioGames it is good for people like me who is absolute beginner.

[@trunghieu974]

totally agree. Nothing new, completely the same as Hipple's talk. There are alot of questions need to solve when we want to use scriptable object to architech our game like your mentions.

[@ourinterface7077]

I mean this could have some value simply because it's shorter than the talks its based upon (a combined 2h). however this specific video doesn't do a good job at condensing the info. Because it does not only not answer the very valid questions you stated it actively answers one of them, but very very incorrectly which is gonna confuse the HELL outta newbies. How do you handle multiple values (non-shared/non-global state)? You don't. You don't because you are literally not supposed to use this at all for non shared state in the first place and ironically this is stated very explicitely in the first of the two referenced talks (kzbin.info/www/bejne/bKfQg6qCjryBiNE), at 10:58 Richard Fine states (as one of the advantages to using scriptable objects): "in the matter of shared vs non-shared state ... having scriptable objects really encourages a strong seperation this stuff. So usually people end up using this stuff for shared-state only. so you have a mono behaviour that stores your non-shared state, your per instance state, that might then refference a scriptable object that holds all the shared state ..." and at 46:00 the speaker is actively avoiding using a SO variable for a buildings current health stating: "we are gonna store a health value, per building, obviously that's not a shared state" and he uses a good old normal ass float variable instead. So under the line. don't use these for non-shared/non-global state like player health as is shown here. in some cases it might even work out fine, like the current health of a player in a single player game, but the latest part where it all falls apart is when you do enemies, you have more than one of the same type of enemy at the same type at once and you try the same thing, because damaging the one oponent will also damage all other ones of the same type. so in the spirit of not getting used to rly shitty practices, you should probably also not do this for player health in a single player game as well, after all why would you want to code player health and enemy health in such fundamentally different ways (coding wise, not gameplay wise, obviously making player and enemy health work different gameplay wise makes a ton of sense in many types of games!) So under the line, while this video has some very good qualities, it rly fails because unfortunately the creator didn't understand a very important part of the concept this video is about, and only ends up spreading a straight up mistake to beginners that will probably be very confused by this.

[@GTZ-98]

Great summary of the Scriptable Object Talk from the Unite Austin!!!!

[@meatbag75]

Great recap of Hipples talk in a quarter of the time! Id be wary for new unity users to keep this in their toolkit until they need it. I can imagine bad debugging scenarios where variables aren't working as expected because they are nested in prefabs and are (or are not!) being overridden unexpectedly. Great technique, great summary, and you had me sold right up until this is how you "should" setup your projects.

[@TheCecchino98]

9:40 maybe someone already suggested it, but you could use operator overloading to still be able to call operations on the variable without referencing its value directly

[@GordonArber]

Wouldn't you be afraid of all the public variables and not knowing which script was setting it? I feel like this would be hard to debug.

[@doge9203]

In my case, I use specific scriptable objects for each function. For example I'll make a PlayerDataVariable containing both health, max health, and etc instead of FloatVariable. Calling it makes more sense too like, playerData,Health or playerData.MaxHealth.

[@mandamoon9149]

Dear Bmo Hipple, these floats will help me from drowning in script. Thanks my man 🤙

[@afifikani]

This is a great video that gave me the real value of using ScriptableObjects. Thanks.

[@Driedsf]

I have been thinking about ScriptableObject's potential in a direction of improving project structure and decoupling for quite long time. I have watched Ryan Hipple's talk entirely recently. But despite the fact he demonstrated some interesting sides of SOs, he also left a lot of questions about how actually to apply this effectively to a something bigger than "Pacman". Starting from a 3 different files just for 1 variable and manual assigning everything, ending with fragmented data and almost redundant possibility to have a state of object in a scene that could even not exist in it.

[@Preftt]

A wonderful tutorial. I started unity about 2 years ago as a small hobby, and I did not understand the value of scriptable objects. I watched the lectures on scriptable objects as well, but it did not click with me. This tutorial simplified it a lot, and has opened my eyes to how powerful scriptable objects can be! Bless you.

[@pmoneyish6869]

What's interesting with this is that these are basically global variables. Like if Unity gave you access to the game loop like other libraries do you'd get the same effect by making global variables outside the loop which would be frowned on by almost everyone. So it's kind of strange it's praised here in Unity which is throwing me for a loop. I clearly see the benefit here in Unity for it, but when you consider they are global variables you'd never do something like that in normal game code to share data because it would get messy fast. My gut tells me event systems passing data around are better for sharing data between systems. More work to setup but in general better than global variables to share data. IDK it's weird thinking about this like that.

[@TheCecchino98]

I guess the main difference is that you still have to pass them manually to the scripts that want to use them, they are not readily accessible from every part of the code, unless you load them from resources. Their main appeal for me is having a single place where the designer can look up and edit the variables I want him to be able to edit, and storing values that are used by the world UI so that I don't need to have it reference objects in whole other places in the scene hierarchy. These look like good tradeoffs for having something akin to global state, although I don't know how well this design would scale in a large project. I still try to pass around everything else using object references and events.

[@UC9o5XrlWjXFOZayVA5JCXcg]

Yep, my first thought was "dumping everything into global variables does not reduce coupling". Sure maybe it helps with testing, but this seems like an anti-pattern to me. Moreover, you could make the exact same "use constant" interface completely without the scriptable objects - so what's the purpose?

[@_Garm_]

I love your teaching style keep up the good work! :D

[@BMoDev]

Appreciate it!

[@callmedeno]

Major level up is using the implicit operator so that you can use it like a normal float (for addition etc.) inside your FloatVariable class public static implicit operator float(FloatVariable variable){ return variable.value; } now you don't have to use the .value every time

[@64imma]

Very interesting point. A problem I often have is trying to cram too much into a single script or object. This isn't necessarily an issue now since the games I've made thus far on my own are very small and simple. I know that as I eventually will make larger, more complex games, this will become an issue. I'm trying to get better about making, say, a player object composed of smaller pieces that control different aspects of that game object, rather than one massive script that multiple objects have to reference.

[@FullMe7alJacke7]

This is the type of content I'm here for!

[@andogrando487]

Still learning Unity so forgive me if this question is obvious, but what are the advantages of using these VariableSO's vs just using native C# event system to decouple these objects?

[@chrisflynn5192]

Different design patterns. Both have their pros and cons but can both do the job of decoupling really well. It actually works very well to use them in tandem

[@unitydev457]

This is great and super helpful but doesn't it end up scaling poorly for larger projects because they all need to drag and drop this variable via inspector? Does anyone have any examples of injecting this automatically?

[@kozavr]

As I understand, drag and drop via inspector is a designer-friendly way making a game.

[@louie2]

is the constant value purely for testing, or do you have an example of an in game use for it? thanks

[@nil7444]

Damn it, this is awesome. Thanks for explaining this so well

[@jacksibley1461]

Can anyone help me? At 6:40 he creates a float variable in his assets folder. When I right click in my assets and go to the create menu, I don't have the option to create a float variable. Has this option been moved or renamed or what??

[@blackstrings]

His float variable is a custom scriptableObject he named FloatVariable you have to write. So that’s not going to be available for you without first writing it. Then To make it available when you right click, all scriptable objects files must declare a special line above the class something like [createMenuAsset…] which you can look up.

[@desine_]

thank you, you've opened my eyes

[@frostymug3123]

This works perfectly for monobehavior scripts but I can't seem to get access to the scriptable object inside of a namespace. What am I doing wrong?

[@xoms_4712]

Why instead of using constant value for changeable health and scripted value for max (basically use one value), you`re using two values?

[@jimmyljr95]

Rethinking the process of rethinking Another solid video BMo.

[@accountdua9375]

Cool, it's the same with the conference talk, but it cut short for me to revise.

[@arjunkramesh]

Isn’t this just a fancy way of creating a global public variable? What benefit does this have over a static class which holds the same information?

[@BMoDev]

For one, you don't have to maintain that variable in code - anyone, you, a game designer, an artist, can all make and utilize a variable in your components without the need of writing any code (assuming you design your components to accept them).

[@louie2]

at 6:08 you mention you’ll show how to reset the value so it doesn’t persist, did you end up showing that? thanks

[@LesP56]

I'm really trying to learn this Scriptable Object stuff but I really don't see how it's saving me much on overhead or anything. Plus I still haven't figured out how to do a lot of stuff because there isn't much documentation on point. Even the Unity documentation throws errors. I can create a custom class quite easily and it seems it's a lot easier to work with. I've been working on it for several days now and I'll stick with it for a few more days but right now, it seems like it's a lot harder for me.

[@neverstepd7]

I am just watching your video to see if I can learn something more about Scriptable Objects, and saddly for me I learned this 5:45 the bad way, I ended up making a bullet pool in them and I had to work around that Either way the Scriptable objects were incredibly useful to allow many of my game's enemies to have a shared common value that affects all of them sorta like an inspector static value, that holds their death audio files, and the color they turn on whenever they are damaged (some enemies are red so that meant the damage color had to be green)

[@flashmanoz8543]

Very Useful stuff ,Please keep them coming

[@BMoDev]

Thanks, ima do my best 🙏

[@darkman237]

What if you incorporated events into this?

[@Noobularr]

This is super neat, I'm curious how this would work but in a multiplayer setting? or with multiple enemies, would they all have the same health if you use the same scriptable object, where you'd need to create specific Scriptable objects(being the health variables) for each player/enemy?

[@blackstrings]

Correct don’t reference the same scriptable object instance for multiple game objects who wishes to be different. You’d have to create a new hp SO instance for per enemy so not optimal to use for in that case.

[@UC9o5XrlWjXFOZayVA5JCXcg]

@@blackstrings That's one of the issues with this pattern. If you want to be able to test enemies using this pattern you need to be instancing SO's for each enemy. Then you have to wonder, it's a ton of work for little to no gains, isn't mocking easier?

[@blackstrings]

@@UC9o5XrlWjXFOZayVA5JCXcg agree. I see that scriptable objects are good for handling specific scenarios only and not a one solution for all. Such as for - single player games the main player stats UI - card deck game for certain shared UI - objects willing to shared same interfaces with limitations But not good where multiple instances have their own unique stats to display at runtime

[@halivudestevez2]

how can you group the values in the inspector? (sorry for the off-topic, I always feel the Inspector very limited)

[@halivudestevez2]

ahh, it is the ScriptableObject itself ...

[@cody_code]

​@halivudestevez2 Not sure if this helps, but I just learned recently that there's a Header property similar to [SerializeField] that lets you create named groups for your variables in the Unity editor, pretty handy if one script has a lot of public or serialized vars. You just pass it a string like so: [Header("name of the section")]

[@hernandonj]

Thank you!

[@ttrudeau83]

Wouldn't it be better to do this via events? Player takes damage and announces it. Everything that needs to know about the change then does something based on it.

[@superdahoho]

can you do an example with enums as scriptableobject please?

[@danielneves5814]

This changes everything

[@jacobs.7925]

is it possible to change all those SOs during runtime? there must be some downside for using them. I remember fiddling with it a bit - some things that worked inside the editor wouldn't work inside the real game once the build was compiled.

[@DapperNurd]

I know this is an old comment, but I'd say there are two main flaws: 1) Using this structuring system can become a bit messy to deal with at a larger scale. Of course, you still deal with the decoupling of game objects and is arguably worth it, but you'll end up with many assets to keep track of. Good organization really helps here. 2) As you hinted, scriptable objects do not save states for new sessions in a built project, despite doing this in the editor. This is not a massive drawback for them as there are plenty of other workarounds such as PlayerPrefs, however it can be quite confusing for someone new with it. CodeMonkey has a good video warning of this issue. Whether or not this makes it worth it, that's subjective. I think it is still worth it, but as stated in this video, it is not really for every project and everyone.

[@FyresGames]

Good stuff. I've used a similare way for events in my game to avoid a middle man singleton in the scene.

[@weckar]

Is this available on Steam?

[@TeurastajaNexus]

What? :D

[@weckar]

@@TeurastajaNexus it's a baby ago I don't remember

[@suicune2001]

Wow, that's cool! O_O I got confused with the coding around 8:30 since I'm not familiar with getters, let alone using ?'s in my code. lol. But I'll definitely watch those videos you recommended. :)

[@JTux_]

The question mark referenced here is the ternary operator, or conditional operator. It's basically an if else statement, except it returns a value. In this case, it's being used in a getter and being returned right away, but you may see it assigned to a variable like var result = condition ? valueIfTrue : valueIfFalse; A getter is basically a hidden method associated with a property. When he calls .Value, he's invoking the Value property's get functionality. It's the same as if you made a method called Value() that returned the constant or variable value. You can Google C# get accessors and C# ternary operators for the Microsoft Documentation which should be the first result.

[@suicune2001]

@@JTux_ Thanks a lot! :) Ok, so the ? is basically a shorthand if/then statement. It's probably because I'm still new but I would much prefer it being spelled out. It's just easier to read and understand. From my understanding, getters and setters are for variables you have to make public (like a singleton) but don't want anyone to fiddle with its values. So it's a "read-only" variable.

[@JTux_]

​@@suicune2001 Sort of, I'd say that's an okay understanding for a beginner. Generally a property has 3 parts, a "backing field" (the private field), a getter, and a setter. The setter is invoked when you say Property = ____; and a getter is accessed when you say _____ = Property;. The backing field is just hidden behind the scenes, but with no setter you're just using that read only variable, yes. The if/else spelled out definitely makes sense. It's one of those things that can definitely help make code smaller/easier to parse at a glance once you understand the syntax. Consider the following: private string GetCanVote(int age) { if (age >= 18) { return "You can vote!"; } else { return "You cannot vote."; } } While it's a simple example, this method takes an integer as a parameter and then decides if it's over 18 or not, and returns a string that can be returned to the user. This could be simplified to something like: private string GetCanVote(int age) { return age >= 18 ? "You can vote" : "You cannot vote."; } Alternatively, you could also create a field called age, a property called CanVote, and a property called Message like so: public int age; public bool CanVote { get { return age >= 18; } } public bool Message { get { return CanVote ? "You can vote!" : "You cannot vote."; } } While there are better ways to accomplish this, there are two properties and a field (age is a field because it doesn't have a getter or a setter) that demonstrate both the ternary (?:) and the getters. Some of this is not as applicable with basic Unity and plays a more common role in C# development in general, but I hope this helps. I probably went way overboard, but hey it's fun.

[@suicune2001]

@@JTux_ Not at all! It was great. :) It helps me a lot to see how the code can look different but do the same thing. Thanks a lot!

[@tonynussbaum]

Me: "oh! I get it!" Also me: proceeds to destroy entire project.

[@troyna77]

thank you. This has seriously helped me. immediate sub'd !!!

[@noisemaker0129]

Very good tutorials...

[@BMoDev]

Thanks!

[@Stompin40]

What would you suggest for a person trying to get into the field? Do they need to go to a 4 year university or is the environment so advanced that its hard to get into? Amazing video btw.

[@_Garm_]

short answer no, you dont need Uni .You only need passion and grit to get in to this field.. but its far from easy. Uni will give you a good and solid foundation and more or less give you a foot in to the market.

[@blackstrings]

If you got the skills and passion just build a personal portfolio around various projects showcasing your skills and you can skip university. Keep in mind the Game industry is vast. Pick your poison and concentrate your skills into a clear focus vs trying to do everything. You could do everything but they all better be strong and well balance otherwise focus on a central skill and showcase that instead in your resume and interviews.

[@raulr994]

I feel like this is basically like global variables or singletons. Yes they are much fancier and provide means to manage them from the editor but that's what they boil down to. I'm struggling to understand whether this is good or not. Usually globals and singletons are considered bad practice as they run into a lot of issues. How is this any different?

[@fakiirification]

my main takeaway is its pretty much singletons without the need for a gameobject in the scene for the singleton to live on. TBH i think event system is still a more robust way to handle decoupled passing of data. But this is a very easy beginner friendly way to do it, and being inspector based makes it good for non-savy designers and artists to do things without having to poke around in code.

[@Balakademi]

Thank you

[@allenz9486]

I think scriptableObject variables is an anti-pattern in most situations except for something singleton like single charactor or single stat, in a more common situation, such as multiply units and enemies, it's not extensiable and add unnecessary complexity

[@kulkalkul]

I do agree, but I also think making this for single value is overkill to my liking. While this is great for non-coders, I don't think it is worth in single developer projects. Though I do believe scriptableobjects can achieve same feats without these complexities, which I still try to understand and discover. I'd like to think them as "multiscene singletons" and still try to figure out a better way of handling all of this.

[@halivudestevez2]

Learn, experience more, you will see differently.

[@accountdua9375]

yup, try it first.

[@DarthMerlin]

What I don't understand is, what is the need for the FloatReference? Why can't I just use FloatVariable in the other two scripts?

[@BMoDev]

You can, the value of the FloatReference lets you use the ScriptableObject or just a constant value you can put in the editor, great for testing and debugging and also sometimes you have a case where you just dont need to make another asset for a variable

[@DarthMerlin]

@@BMoDev Cool. Thanks. I had watched Ryan's video a while ago, but couldn't wrap my head around how to actually implement what he was talking about. This made it easy to understand.

[@erikm9768]

There are much more powerful techniques than this one in Unity , but sure better than Monobehaviours

[@captainamado]

great video, very informative thank you for the information!!

[@mcjgenius]

ty

[@chromezephyr8959]

Writing to scriptableobjects is a bad practice tho. It's better to use them readonly

[@lambda-snail]

I can see using scriptable objects is a powerful way to architect your system! But it also looks a lot like a global variable to me. If I have 10,000 different objects and systems in my project, how do I ensure that only those who should have access to the player's health can actually access it?

[@monkey7218]

For something to have access to the "player health" you need to go into its class, add an exposed reference to the SO asset, then go back to the inspector and drag that SO asset onto the right field in the Inspector.

[@archibaldc.1833]

I'm starting to make games and right now I don't really see the value of this, but I'm sure it's only a matter of time before it becomes readily apparent.

[@fakiirification]

7 months ago. you should have seen the light by now, right? hehehe

[@brainshack9077]

This instantly breaks when you have another player, since they reference the same SO. You then have to start to add code to manage that which adds complexity. Plus wrapping simple types like floats in Objects that then also are persitet to the harddrive can't be great for performance. Would not recommnd using this approach.

[@monkeyrobotsinc.9875]

Yawn

[@disobedientdolphin]

You really should avoid the conditional (ternary) operator due to its lack of readability. The same goes with the arrow notation. Not everything fancy is also good.

[@BMoDev]

Bad advice!

[@disobedientdolphin]

@@BMoDev Bad attitude. Ternary operators are considered bad practice by professionals ever since they were invented.

[@alexsolovev228]

LMAO

[@christopher6267]

lol

[@simtrip6452]

There are a great many cases where I think they are easier to read, and some cases where I would agree with you. Most of the time, I find having to explicitly deal with the two states of a variable at the time of its declaration, makes it easier for me to reason about the state it should end up having as I'm reading the code. However, I would say that repeatedly assigning the same variable with the ternary operator within the same variable scope probably gets into some messy territory where it's really just an attempt to hide what should be necessary complexity. The same goes for nesting them, as most of the time the nesting ends up becoming equivalent to some much simpler boolean expression. That said, I don't think their misuse is any reason to write it off the way you have done. It's been around since C and it's clearly not going anywhere.