Hi everyone! I'd love to hear your thoughts/opinions on Binding as well as what else to include in the Inventory system - add your comments here or join us on Discord - links to last week's video, the source code, and Discord are in the description! 👍
Great video! The binding is new to me so I need to digest it by trying to use it in my project. As for what I would like to see as part of this series: drag/drop to an "equipment" or separate inventory view from this inventory. Would it have a separate model?
@@LimitedInput I've been thinking that might be the next video. There are a few different ways it could be approached, I'll be working that out this week!
Hey man your channel rapidly became my favorite channel. Thanks for the just spectaularly written code. This channel really helps fill the need for more advanced concepts. Id love to see stuff like saving systems covered, or advanced dictionary stuff. Keep up tje awesome work!
Thanks for the comment. If the Inventory system continues to attract viewers, we'll eventually get to data persistence. Otherwise, I will talk about it as a stand alone topic. Or both. I also have Serialized Dictionary on the list of topics. Cheers!
@@git-amend I actually posted a bit about this on one of your other videos. I think it's the accessibility. your code level is a bit intimidating(. especially if you are coming from a lot of the gamedev channels or Udemy classes littered with everything public and singleton. I was rewatching some of your design pattern videos when i thought maybe this would help... 1) make some shorts about intermediate but foundational things. stuff that you can cover in 1 minute. good examples of things you could cover like this would be Abstracts, Generics, interfaces, and maybe scriptable objects and hotkeys. You might even want to use them to explain some of your extensions(vector3.add would be a good one) as those would funnel people directly to your git. all of these shorts would essentially be Ads for you, but also function as primers for people to understand foundational stuff you use when they watch your videos. viewers would be coming to your full length videos with the understanding that your code level is higher.(side note the only reason i included SO in this list is it and the observer pattern seem to get a LOT of traction. the algorithm might feed you more people through it). 2) Provide source code for anything you are doing. Your style is really great as we don't need to type 10000 things for the 20th time, but if someone does need to spend some time on it to understand, they don't always have source code to go to. I was quite intimidated by your code at first, but i did the platform series and now Im comfortable with it. that was possible because The platformer course had everything i needed as source code, so i could digest it at my own pace. some of the design pattern videos only had links to extensions you use, and no direct reference code. links to the videos source code in every video could help people read and process what you are doing.
This is by FAR the best unity programming channel. Every other channel sticks to flashy prototype features, just quickly thrown together. The code in these videos is actually scalable large-codebase-ready, so valuable to watch these videos.
Why is the InventoryView a monobehaviour, instead of the Controller? As I see it, you'd put your logic in the monobehaviour part, so I'd think that the controller would be the attached component to the gameobject. Your channel has very quickly become my favourite channel, it's crazy how well you can explain stuff, while not dumbing things down!
The reason I chose to do it that way is because the view is the only part of the MVC that actually needs to use Unity functionality. The other parts do not. Technically you could move this entire system to Godot and you would only change the view with minimal changes.
This is great video! I had to check to the github code to understand it fully but still. Anyway in case of cross inventory drag/drop what apporach you recomend? Is it Event bus/Event channel/Mediator?
Ok, so I spent like an hour trying to write and essay on how I view the whole MV* craze. But I'll put it simple. Model - a separate entity, in all terms. View - the same thing (completely it's own thing, no strings attached). Adapter - the thing that BINDS the two together, or three, or a million, it doesn't matter. What matters is that in order to have reusable systems with separation of concerns you must mediate between them with a third thing that handles all the mapping (and goes to the configuration layer of your software thus not breaking any boundaries by design). That's how big applications work with any types of separated systems. And after all the years I've spent trying to "understand" MV*, the only logical conclusion is that all those UI patterns are just a bunch of ancient dinosaur poopoo. And you can see how, idk, Apple fights it, they have, what, a MVCVM now I think, and even a Coordinator pattern, which is peculiar, I like it. But thing is, there's no pattern beyond Adapter really. We've boiled it down to just that quite a while ago, as a species, yet we still grasp for the comfort of the outlined patterns presented in a multitude of frameworks. But really what I wanted to say, dude, don't bind your ViewModels to Models, please, I've been there, and I want out. I'll be rewriting my own Unity-MVVM package soon, because we, as a company, are stuck with bound views that cannot be reused or worked separately on, and I am sick of it. I kinda introduced it back in the days (way way back), and I'm the one responsible for breaking the habit. sad smiley face.
I was using a coroutine just in case I want to add some animation to the opening/closing of the Inventory panel later on... not strictly necessary for this video of course!
Thanks I was having some trouble understanding the UI Toolkit. And now it looks so simple after watching your video. In fact I have a question now. If a gamepad support were added, we will have to create and manage a "Selector" right? In order to do swaping etc. Or there is something inside the UI Toolkit that already add suport to gamepads?
Glad to hear that. There isn't anything that I know of in UI Toolkit that is specific to Gamepads. I think it really depends on what you hope to achieve. It might be useful to have a look at Registering for events like NavigationMoveEvent. You've given me something to think about.
Do you have a set of questions you ask yourself on whether you use something like your Event Bus implementation vs just normal events in the system? Or was it that you didn't want to mix that concern into this video as part of the example and might have used it here? I'm not sure I've seen you use the Event Bus in most of these other tutorials and wasn't sure if that was for video simplicity or intentional choice in these use cases. Thoughts?
Truth be told, I try my best not to mix concerns because it's hard for viewers that are new for the channel. I don't know that I have a specific set of questions that I would ask myself, but I almost always favor the Event Bus over other messaging systems because it's easy to use and powerful, but I only use it for messaging outside of a particular area - so if the Player Controller needs to send a message to a different system, I would use the Bus instead of coupling two systems with an Action or similar. I also tend to use a Service Locator for many projects as well for the same reason. Since I have my own library that's been built up over the years, I just share it with the project using a symlink (subject of future video) and then I have access to all my tried and true generic systems like State Machine and Blackboard so I can use them as I need without reinventing the wheel.
@@git-amend This makes sense to me and what I expected. For instance because the MVC generally are in close proximity and together you'd probably just use Actions since they are going to have references to each other in some degree anyways, but anything that you might want to be picked up by say a sound system might be put on the bus to be reacted to by that sound system elsewhere as an example. I think you hinted at a sound effect on the "put back in same place" use case being still done as a "fake swap". Definitely looking forward to your video on that symlink since I've found myself creating a lot of these files that I'll end up porting around between various test projects and would love a better method. Definitely learning a HUGE amount from your videos. Much much appreciated.
Thank you! I tried some of the open source databinding frameworks before, they either have too much overheads (complex context setup) or too many operations in the inspector. This is a very neat implementation. Also I'm on a look out for a lightweight mvvm framework, please drop a link here if anyone knows.
I agree, most are just too complex for straightforward implementations. Thanks for the comment, maybe a light MVVM framework should be a future project for the channel.
REALLY like those Builders, but requires a higher version of C#, past Unity 2019. I hope one day they up the C# language in 2019. However may not be possible!
Yes, I highly doubt Unity will make any changes to Unity 2019 ever again. Most of the time I will use the latest tech stream in videos for the channel so that we can take advantage of new features.
I noticed in your style sheet, you're getting the image by name under the "Url" section with a string. Strings are prone to human errors; and if I ever decide to change the name or location of my image asset, this will require me to track down all the string references and change them. Versus the legacy UI system where I can just define a serialized field and drag a reference. Is there a way to use injection in this way with the UI Style Sheets? Cuz otherwise, it doesn't seem very secure or futureproof.
docs.unity3d.com/Manual/UIE-USS-PropertyTypes.html I think the only way you can achieve that is going to be to either generate uss at runtime, or you can create inline styles and add them using C#
Hi everyone! I'd love to hear your thoughts/opinions on Binding as well as what else to include in the Inventory system - add your comments here or join us on Discord - links to last week's video, the source code, and Discord are in the description! 👍
College sucks. CZcams is only hope. Thanks for giving us hope 🙏
@@Tears_of_Nature Thank you!
Great video! The binding is new to me so I need to digest it by trying to use it in my project. As for what I would like to see as part of this series: drag/drop to an "equipment" or separate inventory view from this inventory. Would it have a separate model?
@@LimitedInput I've been thinking that might be the next video. There are a few different ways it could be approached, I'll be working that out this week!
Hey man your channel rapidly became my favorite channel. Thanks for the just spectaularly written code. This channel really helps fill the need for more advanced concepts. Id love to see stuff like saving systems covered, or advanced dictionary stuff. Keep up tje awesome work!
Thanks for the comment. If the Inventory system continues to attract viewers, we'll eventually get to data persistence. Otherwise, I will talk about it as a stand alone topic. Or both. I also have Serialized Dictionary on the list of topics. Cheers!
You should assume you will grow and continue to get viewers due to the high quality. So just make it:)
@@Albileon Hah, well this video is bombing compared to others, so we'll see.
@@git-amend I actually posted a bit about this on one of your other videos. I think it's the accessibility. your code level is a bit intimidating(. especially if you are coming from a lot of the gamedev channels or Udemy classes littered with everything public and singleton. I was rewatching some of your design pattern videos when i thought maybe this would help...
1) make some shorts about intermediate but foundational things. stuff that you can cover in 1 minute. good examples of things you could cover like this would be Abstracts, Generics, interfaces, and maybe scriptable objects and hotkeys. You might even want to use them to explain some of your extensions(vector3.add would be a good one) as those would funnel people directly to your git. all of these shorts would essentially be Ads for you, but also function as primers for people to understand foundational stuff you use when they watch your videos. viewers would be coming to your full length videos with the understanding that your code level is higher.(side note the only reason i included SO in this list is it and the observer pattern seem to get a LOT of traction. the algorithm might feed you more people through it).
2) Provide source code for anything you are doing. Your style is really great as we don't need to type 10000 things for the 20th time, but if someone does need to spend some time on it to understand, they don't always have source code to go to. I was quite intimidated by your code at first, but i did the platform series and now Im comfortable with it. that was possible because The platformer course had everything i needed as source code, so i could digest it at my own pace. some of the design pattern videos only had links to extensions you use, and no direct reference code. links to the videos source code in every video could help people read and process what you are doing.
This is by FAR the best unity programming channel. Every other channel sticks to flashy prototype features, just quickly thrown together.
The code in these videos is actually scalable large-codebase-ready, so valuable to watch these videos.
Thanks so much for the kind words!
Thanks so much for your hard work! I'll catch up on your past videos when I get a chance 👍
Hey great! Thanks for the comment!
This channel is underrated af.
Thank you for the insights!
I appreciate that!
Why is the InventoryView a monobehaviour, instead of the Controller? As I see it, you'd put your logic in the monobehaviour part, so I'd think that the controller would be the attached component to the gameobject.
Your channel has very quickly become my favourite channel, it's crazy how well you can explain stuff, while not dumbing things down!
The reason I chose to do it that way is because the view is the only part of the MVC that actually needs to use Unity functionality. The other parts do not. Technically you could move this entire system to Godot and you would only change the view with minimal changes.
Insightful video as always!
Thanks!
Once again, awesome stuff!
Thanks!!!
I love your contents, might as well cover MVP and MVVM too?
Thanks for the comment, I'll give that some consideration!
This is great video! I had to check to the github code to understand it fully but still. Anyway in case of cross inventory drag/drop what apporach you recomend? Is it Event bus/Event channel/Mediator?
Thanks! I personally favor the Event Bus - but an Event Channel might work well too.
Ok, so I spent like an hour trying to write and essay on how I view the whole MV* craze. But I'll put it simple. Model - a separate entity, in all terms. View - the same thing (completely it's own thing, no strings attached). Adapter - the thing that BINDS the two together, or three, or a million, it doesn't matter. What matters is that in order to have reusable systems with separation of concerns you must mediate between them with a third thing that handles all the mapping (and goes to the configuration layer of your software thus not breaking any boundaries by design). That's how big applications work with any types of separated systems. And after all the years I've spent trying to "understand" MV*, the only logical conclusion is that all those UI patterns are just a bunch of ancient dinosaur poopoo. And you can see how, idk, Apple fights it, they have, what, a MVCVM now I think, and even a Coordinator pattern, which is peculiar, I like it. But thing is, there's no pattern beyond Adapter really. We've boiled it down to just that quite a while ago, as a species, yet we still grasp for the comfort of the outlined patterns presented in a multitude of frameworks. But really what I wanted to say, dude, don't bind your ViewModels to Models, please, I've been there, and I want out. I'll be rewriting my own Unity-MVVM package soon, because we, as a company, are stuck with bound views that cannot be reused or worked separately on, and I am sick of it. I kinda introduced it back in the days (way way back), and I'm the one responsible for breaking the habit. sad smiley face.
I finaly understand how bindings works in ui toolkit thanks!! juste a question, why do you use a coroutine to initialize the inventoryView ?
I was using a coroutine just in case I want to add some animation to the opening/closing of the Inventory panel later on... not strictly necessary for this video of course!
Thanks I was having some trouble understanding the UI Toolkit. And now it looks so simple after watching your video.
In fact I have a question now. If a gamepad support were added, we will have to create and manage a "Selector" right? In order to do swaping etc.
Or there is something inside the UI Toolkit that already add suport to gamepads?
Glad to hear that. There isn't anything that I know of in UI Toolkit that is specific to Gamepads. I think it really depends on what you hope to achieve. It might be useful to have a look at Registering for events like NavigationMoveEvent. You've given me something to think about.
@@git-amend Great, I'll take a look and play with that. Thanks for the reply.
Freaking good tutorial!!
Glad you think so!
Hey, do you think you could show an example of item tooltips when hovering over?
Good idea, I’ll keep that in mind
Do you have a set of questions you ask yourself on whether you use something like your Event Bus implementation vs just normal events in the system? Or was it that you didn't want to mix that concern into this video as part of the example and might have used it here? I'm not sure I've seen you use the Event Bus in most of these other tutorials and wasn't sure if that was for video simplicity or intentional choice in these use cases. Thoughts?
Truth be told, I try my best not to mix concerns because it's hard for viewers that are new for the channel. I don't know that I have a specific set of questions that I would ask myself, but I almost always favor the Event Bus over other messaging systems because it's easy to use and powerful, but I only use it for messaging outside of a particular area - so if the Player Controller needs to send a message to a different system, I would use the Bus instead of coupling two systems with an Action or similar. I also tend to use a Service Locator for many projects as well for the same reason. Since I have my own library that's been built up over the years, I just share it with the project using a symlink (subject of future video) and then I have access to all my tried and true generic systems like State Machine and Blackboard so I can use them as I need without reinventing the wheel.
@@git-amend This makes sense to me and what I expected. For instance because the MVC generally are in close proximity and together you'd probably just use Actions since they are going to have references to each other in some degree anyways, but anything that you might want to be picked up by say a sound system might be put on the bus to be reacted to by that sound system elsewhere as an example. I think you hinted at a sound effect on the "put back in same place" use case being still done as a "fake swap".
Definitely looking forward to your video on that symlink since I've found myself creating a lot of these files that I'll end up porting around between various test projects and would love a better method. Definitely learning a HUGE amount from your videos. Much much appreciated.
Nice
Thank you! I tried some of the open source databinding frameworks before, they either have too much overheads (complex context setup) or too many operations in the inspector.
This is a very neat implementation. Also I'm on a look out for a lightweight mvvm framework, please drop a link here if anyone knows.
I agree, most are just too complex for straightforward implementations. Thanks for the comment, maybe a light MVVM framework should be a future project for the channel.
@@git-amend That would be grand!
REALLY like those Builders, but requires a higher version of C#, past Unity 2019. I hope one day they up the C# language in 2019. However may not be possible!
Yes, I highly doubt Unity will make any changes to Unity 2019 ever again. Most of the time I will use the latest tech stream in videos for the channel so that we can take advantage of new features.
@@git-amendThanks for the reply, sorry was just thinking about my situation, and can't stand the new Unity. Was NOT suggesting ANYTHING else for you.
I noticed in your style sheet, you're getting the image by name under the "Url" section with a string. Strings are prone to human errors; and if I ever decide to change the name or location of my image asset, this will require me to track down all the string references and change them. Versus the legacy UI system where I can just define a serialized field and drag a reference. Is there a way to use injection in this way with the UI Style Sheets? Cuz otherwise, it doesn't seem very secure or futureproof.
docs.unity3d.com/Manual/UIE-USS-PropertyTypes.html
I think the only way you can achieve that is going to be to either generate uss at runtime, or you can create inline styles and add them using C#
@@git-amend Would it be better to couple the style sheets with scriptable objects or some other form of code to inject the actual images?
@@MarushiaDark316 I'm not sure how exactly you would go about doing that, but it might be an interesting experiment.
Does anyone know what is this color theme?
What program do you use for the diagrams
I use the ExcaliDraw plugin for Obsidian
How are you so good?
Can you do a face reveal at 10k subs with some back story?
One day I'll make a video like that.