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.
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
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.
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...
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.
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.
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.
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.
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.
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.
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.
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?
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)
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?
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
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?
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?
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.
@@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?
@@jgnhrw 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
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.
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. :)
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.
@@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.
@@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.
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).
@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")]
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.
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.
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??
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.
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.
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.
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.
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.
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
@@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.
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?
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.
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
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.
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.
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?
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.
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.
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.
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.
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.
Haha, yup - the better you get at programming the more you realize how important code design is
A game changer in game development for me was learning design patterns. Try the observer pattern in this situation. Trust me. Good luck!
Great summary of the Scriptable Object Talk from the Unite Austin!!!!
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
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.
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...
@@ParkingLotStudioGames it is good for people like me who is absolute beginner.
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.
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.
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.
Dear Bmo Hipple, these floats will help me from drowning in script. Thanks my man 🤙
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.
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.
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.
thank you, you've opened my eyes
This is the type of content I'm here for!
Good stuff. I've used a similare way for events in my game to avoid a middle man singleton in the scene.
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.
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.
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?
Cool, it's the same with the conference talk, but it cut short for me to revise.
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)
I love your teaching style keep up the good work! :D
Appreciate it!
Thank you!
Damn it, this is awesome. Thanks for explaining this so well
This changes everything
Rethinking the process of rethinking
Another solid video BMo.
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?
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
Very Useful stuff ,Please keep them coming
Thanks, ima do my best 🙏
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?
As I understand, drag and drop via inspector is a designer-friendly way making a game.
is the constant value purely for testing, or do you have an example of an in game use for it? thanks
What if you incorporated events into this?
Very good tutorials...
Thanks!
can you do an example with enums as scriptableobject please?
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?
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?
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.
@@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?
@@jgnhrw 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
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.
Me: "oh! I get it!"
Also me: proceeds to destroy entire project.
Why instead of using constant value for changeable health and scripted value for max (basically use one value), you`re using two values?
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. :)
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.
@@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.
@@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.
@@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!
Thank you
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?
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).
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
how can you group the values in the inspector? (sorry for the off-topic, I always feel the Inspector very limited)
ahh, it is the ScriptableObject itself ...
@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")]
thank you. This has seriously helped me. immediate sub'd !!!
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.
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.
ty
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??
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.
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.
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.
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.
Is this available on Steam?
What? :D
@@TeurastajaNexus it's a baby ago I don't remember
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.
great video, very informative thank you for the information!!
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?
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
@@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.
There are much more powerful techniques than this one in Unity , but sure better than Monobehaviours
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?
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.
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
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.
Learn, experience more, you will see differently.
yup, try it first.
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.
7 months ago. you should have seen the light by now, right? hehehe
Writing to scriptableobjects is a bad practice tho. It's better to use them readonly
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?
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.
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.
Yawn
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.
Bad advice!
@@BMoDev Bad attitude. Ternary operators are considered bad practice by professionals ever since they were invented.
LMAO
lol
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.