Rethink Everything with Scriptable Object VARIABLES 

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

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.

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.

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.

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

Appreciate it!

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

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.

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

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!

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.

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.

Thanks!

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.

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")]

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.

What? :D

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

Thanks, ima do my best 🙏

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.

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.

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

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.

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.