--- this is easily a paid course level of quality -- As always top quality this is one of the best tutorials ive come across on Interfaces You didn't even compare them to plugs and sockets once :P
A really well put together tutorial. From an architecture perspective, I would always try and work within the design philosophy of the framework or engine you're using. Unity is a component architecture, which is composition over inheritance based. Where you're using a base class, Unity prefers you to use a prefab. You then build your prefab with all the colliders etc and then attach that prefab as a child. For your interactable example, all the interactable logic would go in the prefab so you wouldn't have to set up the collider each time, it would already be there. You then overrride per object in the editor. Composition is favoured over inheritance because you can only have one base class and that base class can quickly become a dumping ground for methods that some of the derived classes need but not all and then you end up in a world of inheritance chains that are difficult to break out of. Where interfaces in Unity are tricky is that they cannot be used as Unity contracts. The interface can demand that a GameObject is the return value of a method but there is no way to force you to make sure that it is set. So it's a weak contract and must be used with care! Generally I've found that you do less rework if the things in your game are defined by the components on them and the child objects rather than the interfaces and base classes like you might do in other paradigms. Keep the tutorials coming!
Agree in general, though I do thinks there’s opportunities to use inheritance here and there for some big gains, the examples here are good ones. What you don’t want is a deeply nested tree of classes and subclasses making it impossible to customize a unique game object.
@@ItsDan123 like any tool, it needs to be used in the right context. I'm not saying never, I'm saying prefer. I think the first example (interactable) isn't a good example because it isn't a thing, being interactable is a behaviour. Behaviours are interfaces or components. Base enemy is a better example if all your enemies share the majority of their functionality. In a simple example like this then that works. I doubt that scales.
@@RobLang agreed second example is better, especially if you combine that technique with the video on using scriptable objects for plug and play behaviors. I tend to create an IInteractable interface and then implement a mono behavior with the most common implementation(s), leaving me room to make entirely unique interactable objects when needed
The prefab/variant setup you described only works for composed GameObjects. These points are not valid when you want variants of behaviors that have some overlapping common functionalities. Well-structured inheritance and interfaces allow you to refer only to the abstractions rather than specific objects or implementations, which then actually makes things more composable and modular. Done right it’s not an either-or (composition vs inheritance), but rather a synergy. It’s just a matter of using the best approach for the situation. Prefabs/variants, Interfaces and Inheritance are all just tools and it’s about picking the tool best suited for the job, rather than enforcing a convention just out of principle.
As someone who is a complete beginner (I started my game dev journey a couple Months ago) I don’t understand a lot in this video. I just recently finished my first “game” without watching a tutorial and it’s really just a main menu that takes you to a small game that keep the score of enemies you shoot and kill, basic 2D movement and collisions. There’s a game over screen and buttons to restart or go back to main menu but that’s it. That being said I can’t wait to come back to this when I actually understand what everything means. I tried to keep up but I definitely have a lot to learn before this makes sense to me. I’m excited and I love your videos ! Keep it up!
trust me it gets so satisfying when you finally wrap your head around everything: How to work with System.Action, how and when to setup interfaces/abstracts, how and when to use inheritance/component, clean code using SOLId/DRY method, etc. It all seems daunting at first and you may think you'll never be able to understand it, but keep working with it and it'll eventually click.
Tks for the vid!, for me the best thing about clean code is that it makes not so difficult to change. It's much easier to change the logic if your code depends on the Interface only, not the concrete implementation.
Thank you, Sir! Your content is truly remarkable. The tutorial was exceptionally lucid, and your method of explaining concepts with practical use cases is impressive. I now have a comprehensive understanding of the entire concept. Thanks once again!
Oh my gosh, this tutorial was a total game-changer! (literally!) I used to be that person copying and pasting code all over the place, but after watching this, I've totally revamped my game using inheritance and interfaces. Those examples with doors, switches, and enemy behaviors? Absolute gold. It's like this tutorial knew exactly the mess I was in and threw me a lifeline. Huge shoutout for dropping this knowledge bomb. Can't wait for more of this goodness! Keep rocking!
You did a good job explaining the topic, i think this will help beginners get into it. I got a little bit of advice on the use of inheritance and "clean code"(TM) for those who think about adopting more of it. Modern game engines went for a hybrid solution of component based design and inheritence for a good reason. In games, trying to solve everything through inheritence can lead to messy solutions. Not in simple examples, but as soon as the project gets bigger. In this case for example, the loot did not need to be part of the enemy, it could have been a loottable as a component on the enemy, so the loottable code could be used on different objects like enemies, destructable boxes, chests etc. Explaining to beginners /how/ to use something is easier than /when/ to wisely use something, because wisdom comes with time. The term "clean code" has a double meaning as both an adjective and as the Title of Bob Martin's famous book in which cases it refers to a specific philosophy of creating code, that also has it's issues. Don't get me wrong, the book has some really good points, but it also encourages to create a huge amount of sometimes unnecessary abstraction. So when people talk about "clean code" it has a double meaning which is often the source of irritation and disagreement. Is this one of the videos made before moving? ^_^
This is not good. Interactables should NOT be responsible for detecting input. Interactables should NOT be responsible for detecting the player. Interactables should NOT be responsible for activating the icon. Input and proximity detection is something that the player should handle and the icon should be something that reacts to events (eg. "OnBeginPossibleInteraction") For the enemies there is no point in creating a damagable or lootable interface. Both of these are better suited being a component with a abstract base class to inherit from and then just connecting them via events to the enemies. EG: Player will search for ADamagable when attacking. A ghost will have Health component which inherits from ADamageble. The component will keep track of the health updating and fire events as appropriate. And the lootable class should probably just be a LootDrop class that subscribes to an event (the event would be called "OnUnitDied" and would be fired by the health component). Not only do you avoid the problems unity has with interfaces sometimes not being null even tho the object is being destroyed. You also have a much more flexible architecture that requires less code overall.
Fascinating. Always had trouble wrapping my head around this concept. Your explanation makes sense but now I'm thinking, so we shouldn't be using interfaces much at all in Unity other than for a base class to extend? Goddamn I've recently learned about prefering composition over inheritance and have been almost religiously avoiding inheritance in favor of interfaces whenever possible but it seems that this is unnecessary for Unity since it has a component system.
Just starred this one for later. I think the biggest issue for me is getting confused or not being consistent with where to manage inheritance / references within Unity vs. doing it via the code. E.g. I'm not sure if it is more robust to just link the prefab in the inspector (or maybe that will break if the scene changes or something?) vs. using a lookup reference of some kind (for me usually looking to a parent or child for a component, everything is pretty separated and independently managed, with high level managres sharing needed details) vs. using prefabs and prefab variants (which was a recent approach I used and liked a lot.) I have different kinds of buildings, some generate shields some dont, some give credits to players some dont, some have unique animations). I've ended up with a relatively manageable approach, but it doesn't feel like i have a clear pattern for "use X when Y" or even "use X if constelllation of X Y and Z seems...", it's more like "Whose video did I just just watch?" :)
Hi Brandon! Love Your Videos, Love Tutorial Explanation, Love Your Coding and I Love You. You saved me a lot of time, by the way i'm a student, just began studying programming in unity, at the start I had a tough time on handling the issues and problems till I found you, Since my homeworks went correctly and I'm learning a lot from you than my classes. Now I can consider myself as a middle dev. So now I have another problems with my classes, its Unity DOTS and ECS. If you can, if you have time if you are able to do, can you make Tutorials on them, as I told you I learn from you more than form my classes. Thanks in advance, wish you all the best, wish you achieve all your goals. I apologize for my English, I'm from Tajikistan by the way. Hello from Tajikistan. Its in middle Asian.
nice tutorial for inheritance! but you could have chosen a better example as this has some flaws so I wouldn't use it in production. 1. What if I want to have multiple entities interacting with the world? NPCs, AI Agents, Multiplayer? You are hardcoded to one player input. 2. The performance impact of one interactable is neglectable but imagen having 1000 interactables! I prefer having the player check if something interactable is in reach and then trigger the Interact function. This way anything can interact with them and you safe yourself a bunch of if checks and Update calls each frame! I also like using events for this, so I just need one interaction component and then other components can listen to its events. So I don't have to use any inheritance which comes with some flaws in unity (as @RobLang pointed out). Same for damage. For loot have one loot component that has a scriptable object containing the loot information. Call it whenever it should generate loot. You can easily connect it to the health component's OnDeath event, if you use UnityEvents all you need is the inspector. If you actually need different behaviors for different enemies you still can override the loot component. In your example i would just create an inital velocity vector field in the inspector.
Hi Brandon, This video is awesome, Keep doing what you are doing it is really well made. I have been subscribed to your channel since the really early days . I subscribed because your journey seemed like it was going to be a very interesting one. And I must say that you did not disappoint. One thing that really impresses me is , how does an Accountant become so good at coding ? I definitely see the passion that you have for game dev and the community. What are some of the resources that you use in your learning process? I mean if you do courses what are some of the courses that you take? thanks again for sharing your journey and knowledge with us.
One thing you should have touched upon is when you would use one over the other. For me i would use inheritance if the objects are related. Say a tree, flower, bush would all need to grow so they would inherit from a class called Plant. But for something like interactable. They arent really related, like your door, the npc and the lever. So they would get an interface. Like to know your opinion on this.
Im doing the codemonkey kitchenchaos tutorial and it's the first time i've bumped into inheritance. He did it well, but it's not the focus of the course. This has really helped me understand ! Thank you so much.
What if I want some enemies to not be damageable, would I just remove that interface from my base class and instead add the interface to the enemy classes inhereting from the EnemyBase?
Recommended better naming practice for base classes is to remove the "Base" term from that and instead add a descriptor term to the names that derive from the base class. At least that's what they say in my programming books. \o/
Your hierarchy...is... beautiful...
--- this is easily a paid course level of quality --
As always top quality this is one of the best tutorials
ive come across on Interfaces
You didn't even compare them to plugs and sockets once :P
A really well put together tutorial. From an architecture perspective, I would always try and work within the design philosophy of the framework or engine you're using. Unity is a component architecture, which is composition over inheritance based. Where you're using a base class, Unity prefers you to use a prefab. You then build your prefab with all the colliders etc and then attach that prefab as a child. For your interactable example, all the interactable logic would go in the prefab so you wouldn't have to set up the collider each time, it would already be there. You then overrride per object in the editor. Composition is favoured over inheritance because you can only have one base class and that base class can quickly become a dumping ground for methods that some of the derived classes need but not all and then you end up in a world of inheritance chains that are difficult to break out of.
Where interfaces in Unity are tricky is that they cannot be used as Unity contracts. The interface can demand that a GameObject is the return value of a method but there is no way to force you to make sure that it is set. So it's a weak contract and must be used with care!
Generally I've found that you do less rework if the things in your game are defined by the components on them and the child objects rather than the interfaces and base classes like you might do in other paradigms.
Keep the tutorials coming!
Agree in general, though I do thinks there’s opportunities to use inheritance here and there for some big gains, the examples here are good ones. What you don’t want is a deeply nested tree of classes and subclasses making it impossible to customize a unique game object.
@@ItsDan123 like any tool, it needs to be used in the right context. I'm not saying never, I'm saying prefer.
I think the first example (interactable) isn't a good example because it isn't a thing, being interactable is a behaviour. Behaviours are interfaces or components.
Base enemy is a better example if all your enemies share the majority of their functionality. In a simple example like this then that works. I doubt that scales.
@@RobLang agreed second example is better, especially if you combine that technique with the video on using scriptable objects for plug and play behaviors. I tend to create an IInteractable interface and then implement a mono behavior with the most common implementation(s), leaving me room to make entirely unique interactable objects when needed
The prefab/variant setup you described only works for composed GameObjects. These points are not valid when you want variants of behaviors that have some overlapping common functionalities. Well-structured inheritance and interfaces allow you to refer only to the abstractions rather than specific objects or implementations, which then actually makes things more composable and modular. Done right it’s not an either-or (composition vs inheritance), but rather a synergy. It’s just a matter of using the best approach for the situation. Prefabs/variants, Interfaces and Inheritance are all just tools and it’s about picking the tool best suited for the job, rather than enforcing a convention just out of principle.
@@owencoopersfx it is after all usually said as “favor composition over inheritance” and not “require” it
As someone who is a complete beginner (I started my game dev journey a couple
Months ago) I don’t understand a lot in this video. I just recently finished my first “game” without watching a tutorial and it’s really just a main menu that takes you to a small game that keep the score of enemies you shoot and kill, basic 2D movement and collisions. There’s a game over screen and buttons to restart or go back to main menu but that’s it.
That being said I can’t wait to come back to this when I actually understand what everything means. I tried to keep up but I definitely have a lot to learn before this makes sense to me. I’m excited and I love your videos ! Keep it up!
trust me it gets so satisfying when you finally wrap your head around everything: How to work with System.Action, how and when to setup interfaces/abstracts, how and when to use inheritance/component, clean code using SOLId/DRY method, etc. It all seems daunting at first and you may think you'll never be able to understand it, but keep working with it and it'll eventually click.
Your content is top level, i think youtube has new brackeys.
Tks for the vid!, for me the best thing about clean code is that it makes not so difficult to change. It's much easier to change the logic if your code depends on the Interface only, not the concrete implementation.
As a heads up, later versions of Unity 2020 and onwards do support default interface implementations btw.
Thanks for the info! I wasn't aware of that
Oh thanks for that I had been confused by some of the documentation
ive found on -how to implement interfaces
Thank you, Sir! Your content is truly remarkable. The tutorial was exceptionally lucid, and your method of explaining concepts with practical use cases is impressive. I now have a comprehensive understanding of the entire concept. Thanks once again!
This video is SO INSANELY HELPFUL. Thank you so much. You just saved me so much time and effort in the future.
Love this, Thank you for the easy to understand examples!! Best video I have seen on this topic so far!
Top notch once again!!
Excellent job on the tutorial! Well organized and very well presented! And a couple nice tips along the way.
High quality tutorial alert!
Great video! my favorite of yours yet. I'll have to step through it slowly later. A lot ot learn here :)
This is a great concise video for explaining these topics that I wish I had two years ago 😂 Nice work!
Oh my gosh, this tutorial was a total game-changer! (literally!) I used to be that person copying and pasting code all over the place, but after watching this, I've totally revamped my game using inheritance and interfaces. Those examples with doors, switches, and enemy behaviors? Absolute gold. It's like this tutorial knew exactly the mess I was in and threw me a lifeline. Huge shoutout for dropping this knowledge bomb. Can't wait for more of this goodness! Keep rocking!
Very effective use of the 7 minutes between video release and your comment.
@@sealsharp Thanks! I've been working pretty hard to release my game and it should be ready in the next month or so!
this is just awesome! i'd love more tutorials like these
Just finished a year long project on something similar and you explained it so well
You did a good job explaining the topic, i think this will help beginners get into it.
I got a little bit of advice on the use of inheritance and "clean code"(TM) for those who think about adopting more of it.
Modern game engines went for a hybrid solution of component based design and inheritence for a good reason. In games, trying to solve everything through inheritence can lead to messy solutions. Not in simple examples, but as soon as the project gets bigger. In this case for example, the loot did not need to be part of the enemy, it could have been a loottable as a component on the enemy, so the loottable code could be used on different objects like enemies, destructable boxes, chests etc.
Explaining to beginners /how/ to use something is easier than /when/ to wisely use something, because wisdom comes with time.
The term "clean code" has a double meaning as both an adjective and as the Title of Bob Martin's famous book in which cases it refers to a specific philosophy of creating code, that also has it's issues. Don't get me wrong, the book has some really good points, but it also encourages to create a huge amount of sometimes unnecessary abstraction. So when people talk about "clean code" it has a double meaning which is often the source of irritation and disagreement.
Is this one of the videos made before moving? ^_^
This is not good.
Interactables should NOT be responsible for detecting input.
Interactables should NOT be responsible for detecting the player.
Interactables should NOT be responsible for activating the icon.
Input and proximity detection is something that the player should handle and the icon should be something that reacts to events (eg. "OnBeginPossibleInteraction")
For the enemies there is no point in creating a damagable or lootable interface. Both of these are better suited being a component with a abstract base class to inherit from and then just connecting them via events to the enemies.
EG: Player will search for ADamagable when attacking. A ghost will have Health component which inherits from ADamageble. The component will keep track of the health updating and fire events as appropriate. And the lootable class should probably just be a LootDrop class that subscribes to an event (the event would be called "OnUnitDied" and would be fired by the health component).
Not only do you avoid the problems unity has with interfaces sometimes not being null even tho the object is being destroyed. You also have a much more flexible architecture that requires less code overall.
Fascinating. Always had trouble wrapping my head around this concept. Your explanation makes sense but now I'm thinking, so we shouldn't be using interfaces much at all in Unity other than for a base class to extend?
Goddamn I've recently learned about prefering composition over inheritance and have been almost religiously avoiding inheritance in favor of interfaces whenever possible but it seems that this is unnecessary for Unity since it has a component system.
I would also make the virtual Start() method protected instead of public.
Just starred this one for later.
I think the biggest issue for me is getting confused or not being consistent with where to manage inheritance / references within Unity vs. doing it via the code. E.g. I'm not sure if it is more robust to just link the prefab in the inspector (or maybe that will break if the scene changes or something?) vs. using a lookup reference of some kind (for me usually looking to a parent or child for a component, everything is pretty separated and independently managed, with high level managres sharing needed details) vs. using prefabs and prefab variants (which was a recent approach I used and liked a lot.)
I have different kinds of buildings, some generate shields some dont, some give credits to players some dont, some have unique animations). I've ended up with a relatively manageable approach, but it doesn't feel like i have a clear pattern for "use X when Y" or even "use X if constelllation of X Y and Z seems...", it's more like "Whose video did I just just watch?" :)
Hi Brandon! Love Your Videos, Love Tutorial Explanation, Love Your Coding and I Love You. You saved me a lot of time, by the way i'm a student, just began studying programming in unity, at the start I had a tough time on handling the issues and problems till I found you, Since my homeworks went correctly and I'm learning a lot from you than my classes. Now I can consider myself as a middle dev. So now I have another problems with my classes, its Unity DOTS and ECS. If you can, if you have time if you are able to do, can you make Tutorials on them, as I told you I learn from you more than form my classes. Thanks in advance, wish you all the best, wish you achieve all your goals. I apologize for my English, I'm from Tajikistan by the way. Hello from Tajikistan. Its in middle Asian.
nice tutorial for inheritance!
but you could have chosen a better example as this has some flaws so I wouldn't use it in production.
1. What if I want to have multiple entities interacting with the world? NPCs, AI Agents, Multiplayer? You are hardcoded to one player input.
2. The performance impact of one interactable is neglectable but imagen having 1000 interactables!
I prefer having the player check if something interactable is in reach and then trigger the Interact function. This way anything can interact with them and you safe yourself a bunch of if checks and Update calls each frame!
I also like using events for this, so I just need one interaction component and then other components can listen to its events. So I don't have to use any inheritance which comes with some flaws in unity (as @RobLang pointed out).
Same for damage.
For loot have one loot component that has a scriptable object containing the loot information.
Call it whenever it should generate loot. You can easily connect it to the health component's OnDeath event, if you use UnityEvents all you need is the inspector.
If you actually need different behaviors for different enemies you still can override the loot component. In your example i would just create an inital velocity vector field in the inspector.
Hi Brandon, This video is awesome, Keep doing what you are doing it is really well made. I have been subscribed to your channel since the really early days . I subscribed because your journey seemed like it was going to be a very interesting one. And I must say that you did not disappoint. One thing that really impresses me is , how does an Accountant become so good at coding ? I definitely see the passion that you have for game dev and the community.
What are some of the resources that you use in your learning process? I mean if you do courses what are some of the courses that you take?
thanks again for sharing your journey and knowledge with us.
One thing you should have touched upon is when you would use one over the other. For me i would use inheritance if the objects are related. Say a tree, flower, bush would all need to grow so they would inherit from a class called Plant. But for something like interactable. They arent really related, like your door, the npc and the lever. So they would get an interface. Like to know your opinion on this.
Im doing the codemonkey kitchenchaos tutorial and it's the first time i've bumped into inheritance. He did it well, but it's not the focus of the course. This has really helped me understand ! Thank you so much.
What if I want some enemies to not be damageable, would I just remove that interface from my base class and instead add the interface to the enemy classes inhereting from the EnemyBase?
Great tutorial, with a bad title unfortunately! I think a better title would help more people to find this video via search.
I Hope one day i learn C# and unity to understand what you doing here
Recommended better naming practice for base classes is to remove the "Base" term from that and instead add a descriptor term to the names that derive from the base class. At least that's what they say in my programming books. \o/
First
I'm a bit of a code-golfer, might I suggest _isInteractable = collision.gameObject == player;