In a world of duplicate Unity tutorials of "HOW TO MOVE CHARACTER" where they put literally everything in a player controller class, your videos shine bright, man. Usually when I see a video on a topic I am already comfortable and knowledgeable with, I wouldn't click on it to learn about it, but whenever I see a video from you doing it, I know there's new shit in there that I haven't seen yet. You teach people the most important thing of all in programming- architecture- and I don't even know if you realize it. You may make a youtube video about /said/ topic, but you don't slap it together in a massive class and call it a day. You healthily separate it out, and show good architecture techniques. I appreciate it a lot that you are vulnerable with your own knowledge, and programming style- enough so, to take the time to make a tutorial on /said/ topic, and create it in a way that reflects how you would actually do it if you were making it for a big project. I struggled with that very thing for so long. I felt nauseous looking through tutorials of megalithic player controller classes, and half-ass singletons, until I finally found good youtubers like yourself, & Code Monkey, that can teach a programmer what they really need to really know. Yeah, it's nice there are super specific tutorials on the internet to teach people how to do /this thing./ But the way they are represented gives terrible impressions. You have new programmers watching a demo video where a programmer creates a Player singleton and implements the input, movement, shooting, animation all in one giant class, and references each enemy directly from that player class and just UGH. It's a god damn mess! And people actually take that shit as gospel, and get deluded and tricked into thinking that is acceptable, and wonder why they hate coding when they have to sort through an if statement nest that runs 15 if statements deep, then they quit. Don't get me wrong, brand new programmers need love too, and they're not worried about hierarchical architecture of classes, data, and functionality. That isn't the problem by any means, at all. It's the unbalance of it all. What about all the people who get past that phase, and know how to shoot a god damn raycast, but don't know how to separate the raycast from the object being hit? Do they put the OnTriggerEnter on the player or the object? These are serious questions that an aspiring programmer has in the very beginning, and there are not enough answers for them. They are shit out of luck on finding out the best ways to do it without having gigantic, pain in the ass, hacked together, singleton player controllers with a million if statement nests and not a single interface, all because they couldn't find a decent tutorial on the internet that wasn't trash.
Great to see more videos on the topic of scriptable objects. One important gotcha to point out : While scriptable objects can be referenced by objects in scenes and other scriptable objects, you cannot do the reverse. That is, you cannot reference a scene object inside a scriptable object that lives outside of the scene. It is possible to make references of scene objects to scriptable objects during runtime (and during edit time as well, but the references will be lost). An example of this is say we have a Player object in the scene and a Stats scriptable object in the project. The Player can reference the Stats scriptable object, but the Stats scriptable object cannot reference the Player object because the player lives in the scene. Prefabs can be referenced by scriptable objects though, as they also live in the project. So the Player object can be turned into a prefab and then the Stats scriptable object would be able to reference the Player object. Generally speaking, one wouldn't need object references in scriptable objects, but it goes on a case by case basis.
Very well done! So many people need to learn this! Scriptable Objects are incredibly powerful! I'd love to see you make a video about save/loading as well.
I always put every value i can on a scriptable object, and make it create a new gameobject for you, with a component that makes use of that scriptable object, and can hold local values like position. Also i mostly use abstract scriptable objects, so that the ones that i really use can derive from it and i get better control. (A hero and a minion might share common variables like max health, but a minion might not have access to the same mechanics as a hero)
Hey, I have been watching your videos for a long time. Amazing tips and tutorials for people like us! I didn’t know where to message you about Scriptable Objects. I will comment here instead so people get general idea. My question is about performance wise and bit of comparison to classes: 1. Due to serialization playing a huge part for SO, it’s usually very helpful for me to make list of items or any sort of data (where data or item is plain class) and add them to list via any means (can be custom editors).. is it going to hit the performance when we reference this SO for all the data in game? 2. This can be used as events and delegates kinda thing without the whole SO-event architecture for small stuff like Player UI updating by dragging same SO for player and UI. Is that better than SO event system or C#’s event and delegates? 3. Can we not do the same with classes except for serialization part and make state machines out of those? (Referring to pluggable AI videos on youtube) .. like I am really guessing plain classes have lower overhead than SO? Just few doubts I have, I really love the architecture with SO. I love making tools and do all kinds of modular stuff but also I don’t really want to use Items as SO. 100 assets for items in folder, nightmare to go through.. though I can add them to list in one scriptable object which acts like database but I feel like plain classes are the better for items and add them to SO database for simple serialization purpose. I can be totally wrong but I really want to answers to these. At least your take on it.
Instead of limiting yourself with limited number of types of stats changes with an Enum and a potentially large switch case code block. Why not just abstract that implementation detail into Modifier itself?
Yes, you can create them like so : ScriptableObject runtimeSO = ScriptableObject.CreateInstance(); This post has some more info, hope it helps! stackoverflow.com/questions/52377827/instantiated-using-the-scriptableobject-createinstance
I guess people are excited about ScriptableObject just because it's a different way of creating an object. But in reality, there is no difference to just use a plain c# class to create your object. The only time you would want to use ScriptableObjects is when you need an instance of a class at compile time. For example, when you're working with non-programmers on the project.
FWIW, I stopped watching this video a third of the way through. I kept having to stop, go back (elapsed time control or 'j' key) to try to stay in sync with the video. I finally realized that the author was talkiing and visually demonstrating much too fast for me. This caused me to not be able to effectively follow and understand the video. So, it made no sense for me to continue to watch. My advice: 1) Talk slower. Remember, you are (most likely) introducing new concepts to others. Pace it so that others can follow along and understand. 2) Proceed throught your visual demonstrations slower so that others can follow what you are doing. Talking slower will help with this. Just remember that some of us are new to Unity , its tools, script attributes ("[]") and Scriptable Objects. All this being said, I'll admit, there was no " ...for beginners..." in the title. Posted with repsct for the author.
Personally, I appreciate to have a youtuber who makes Unity tutorials that aren't meant for beginners for once. One thing I do when I find people speak too slowly is that I increase the video's speed in the setting; you could try slowing it down the same way? :)
In a world of duplicate Unity tutorials of "HOW TO MOVE CHARACTER" where they put literally everything in a player controller class, your videos shine bright, man. Usually when I see a video on a topic I am already comfortable and knowledgeable with, I wouldn't click on it to learn about it, but whenever I see a video from you doing it, I know there's new shit in there that I haven't seen yet. You teach people the most important thing of all in programming- architecture- and I don't even know if you realize it. You may make a youtube video about /said/ topic, but you don't slap it together in a massive class and call it a day. You healthily separate it out, and show good architecture techniques. I appreciate it a lot that you are vulnerable with your own knowledge, and programming style- enough so, to take the time to make a tutorial on /said/ topic, and create it in a way that reflects how you would actually do it if you were making it for a big project.
I struggled with that very thing for so long. I felt nauseous looking through tutorials of megalithic player controller classes, and half-ass singletons, until I finally found good youtubers like yourself, & Code Monkey, that can teach a programmer what they really need to really know. Yeah, it's nice there are super specific tutorials on the internet to teach people how to do /this thing./ But the way they are represented gives terrible impressions. You have new programmers watching a demo video where a programmer creates a Player singleton and implements the input, movement, shooting, animation all in one giant class, and references each enemy directly from that player class and just UGH. It's a god damn mess! And people actually take that shit as gospel, and get deluded and tricked into thinking that is acceptable, and wonder why they hate coding when they have to sort through an if statement nest that runs 15 if statements deep, then they quit.
Don't get me wrong, brand new programmers need love too, and they're not worried about hierarchical architecture of classes, data, and functionality. That isn't the problem by any means, at all. It's the unbalance of it all. What about all the people who get past that phase, and know how to shoot a god damn raycast, but don't know how to separate the raycast from the object being hit? Do they put the OnTriggerEnter on the player or the object? These are serious questions that an aspiring programmer has in the very beginning, and there are not enough answers for them. They are shit out of luck on finding out the best ways to do it without having gigantic, pain in the ass, hacked together, singleton player controllers with a million if statement nests and not a single interface, all because they couldn't find a decent tutorial on the internet that wasn't trash.
Totally agree. Architecture is the most valuable and unrepresented thing out here.
Exactly. Making it work vs making it scalable are totally separate things.
Super important while making a game for long run.
Great to see more videos on the topic of scriptable objects. One important gotcha to point out :
While scriptable objects can be referenced by objects in scenes and other scriptable objects, you cannot do the reverse. That is, you cannot reference a scene object inside a scriptable object that lives outside of the scene.
It is possible to make references of scene objects to scriptable objects during runtime (and during edit time as well, but the references will be lost). An example of this is say we have a Player object in the scene and a Stats scriptable object in the project. The Player can reference the Stats scriptable object, but the Stats scriptable object cannot reference the Player object because the player lives in the scene.
Prefabs can be referenced by scriptable objects though, as they also live in the project. So the Player object can be turned into a prefab and then the Stats scriptable object would be able to reference the Player object.
Generally speaking, one wouldn't need object references in scriptable objects, but it goes on a case by case basis.
I've found this out the hard way! It taken some figuring out to get my head around it.
Very well done! So many people need to learn this! Scriptable Objects are incredibly powerful! I'd love to see you make a video about save/loading as well.
Always thumbs ups for game architecture videos!
I always put every value i can on a scriptable object, and make it create a new gameobject for you, with a component that makes use of that scriptable object, and can hold local values like position. Also i mostly use abstract scriptable objects, so that the ones that i really use can derive from it and i get better control. (A hero and a minion might share common variables like max health, but a minion might not have access to the same mechanics as a hero)
OMG ! How can I miss this channel until now. This is GEM !
Thanks for the amazing content !
Definitely interested in a save system
Hey, I have been watching your videos for a long time. Amazing tips and tutorials for people like us!
I didn’t know where to message you about Scriptable Objects. I will comment here instead so people get general idea.
My question is about performance wise and bit of comparison to classes:
1. Due to serialization playing a huge part for SO, it’s usually very helpful for me to make list of items or any sort of data (where data or item is plain class) and add them to list via any means (can be custom editors).. is it going to hit the performance when we reference this SO for all the data in game?
2. This can be used as events and delegates kinda thing without the whole SO-event architecture for small stuff like Player UI updating by dragging same SO for player and UI. Is that better than SO event system or C#’s event and delegates?
3. Can we not do the same with classes except for serialization part and make state machines out of those? (Referring to pluggable AI videos on youtube) .. like I am really guessing plain classes have lower overhead than SO?
Just few doubts I have, I really love the architecture with SO. I love making tools and do all kinds of modular stuff but also I don’t really want to use Items as SO. 100 assets for items in folder, nightmare to go through.. though I can add them to list in one scriptable object which acts like database but I feel like plain classes are the better for items and add them to SO database for simple serialization purpose. I can be totally wrong but I really want to answers to these. At least your take on it.
Instead of limiting yourself with limited number of types of stats changes with an Enum and a potentially large switch case code block. Why not just abstract that implementation detail into Modifier itself?
Can I save and load data from scriptable objects?
Please, make tutorial on how to save
Can you make scriptable objects at runtime?
Yes, you can create them like so :
ScriptableObject runtimeSO = ScriptableObject.CreateInstance();
This post has some more info, hope it helps!
stackoverflow.com/questions/52377827/instantiated-using-the-scriptableobject-createinstance
I guess people are excited about ScriptableObject just because it's a different way of creating an object. But in reality, there is no difference to just use a plain c# class to create your object. The only time you would want to use ScriptableObjects is when you need an instance of a class at compile time. For example, when you're working with non-programmers on the project.
Nice video! Do you have this project in repository?
what is IStatType on your code?
he explained it in the video, it's just for unit testing
Thanks for your vid. Please, make vids with higher resolution.
PLEASE UPLOAD 1080P
Quick Tip: To make this video sound like it's at normal playback speed, set it to 0.75.
FWIW, I stopped watching this video a third of the way through. I kept having to stop, go back (elapsed time control or 'j' key) to try to stay in sync with the video. I finally realized that the author was talkiing and visually demonstrating much too fast for me. This caused me to not be able to effectively follow and understand the video. So, it made no sense for me to continue to watch.
My advice:
1) Talk slower. Remember, you are (most likely) introducing new concepts to others. Pace it so that others can follow along and understand.
2) Proceed throught your visual demonstrations slower so that others can follow what you are doing. Talking slower will help with this.
Just remember that some of us are new to Unity , its tools, script attributes ("[]") and Scriptable Objects.
All this being said, I'll admit, there was no " ...for beginners..." in the title.
Posted with repsct for the author.
For the love of God, slow down!! You're speaking far too quickly to keep up with.
Personally, I appreciate to have a youtuber who makes Unity tutorials that aren't meant for beginners for once.
One thing I do when I find people speak too slowly is that I increase the video's speed in the setting; you could try slowing it down the same way? :)