Transcript: The scripting languages that Unity supports have a feature called Inheritance. Inheritance is one of the cornerstones of Object-Oriented Programming, or OOP for short. When a class inherits from another, it gains the features of the class it inherits from. When talking about inheritance, the class that is being inherited from is called the "Parent", or base class. The class that is inheriting is called the "Child" or derived class. The result of inheritance is that items that exist in the parent class will also be available in the child class. Therefore, methods and variables can be used in the child class as if it was the parent class. For example, assume you have a parent class called "Class A", which contains two methods: Dance() and Sing(). If you have another class, "Class B", which inherits from Class A, then Class B will also have the two methods, Dance() and Sing(). These methods do not need to be created in Class B because they already exist in Class A. When dealing with inheritance, there are three access modifiers to be aware of: Public, Private, and Protected. You should already be familiar with the concepts of the Public and the Private access modifiers. Just be aware that the features of a parent class that are Public will exist, and be accessible, in the child class, while features that are Private will exist , but not be accessible, in the child class. The Protected access modifier acts as a hybrid between Public and Private. All features of a parent class that are Protected will exist and be accessible in a child class, like Public features, but will not be accessible outside of the parent or child classes, like Private features. It is likely that most of the classes you have used so far in Unity have been inheriting. Indeed, all scripts which are applied as components to GameObjects are MonoBehaviours. This means they have inherited from the MonoBehaviour class. By default, scripts made in Unity follow this format: "public class", followed by the name of the class, followed by a colon, and the class name: MonoBehaviour. The colon in class name, MonoBehaviour, is telling the script that it inherits from MonoBehaviour. To make this class inherit from another class, simply change the name MonoBehaviour to some other class name. To change the class so it doesn't inherit from any parent class, simply remove the colon and parent class name. You might be wondering why our scripts inherit from MonoBehaviour. Items like GameObject, Transform, the Start() method, the Update() method, and more, all come from MonoBehaviour. Our scripts inherit from MonoBehaviour so that we have access to these features. The inheritance structure is hierarchical. A common way to think of inheritance is to think of the animal kingdom. In this example, we'd have a parent class called "Animal". This class would contain all of the definitions and properties necessary to make the class behave like an animal. >From this Animal base class, we might have a couple of child classes: Vertebrate, and Invertebrate. The Vertebrate class would then, in turn, be the parent class for more classes, such as Mammal, Reptile, or Amphibian. Each of these child classes would take the information given by its base class, and add to it. Just like our animal example, inheritance in Object-Oriented Programming is known as an Is-A relationship. This means that the child class is a parent class. A Reptile is a Vertebrate. A Mammal is an Animal. An example in Unity that you may have come across before is: A Capsule Collider is a Collider. This concept will be covered further in the lesson on Polymorphism, linked below. The idea of inheritance can be very useful, and applicable, in game development. We might, for example, have a class called "Humanoid". This class covers all of the things that humanoids should do in our game. We then have two child classes: Enemy and Player. These control the specifics of how players and enemies work in the game while already behaving like humanoids, because they've inherited all of the Humanoid class's members. We could then have two more child classes of Enemy: Orc and Goblin. These already behave like enemies, which in turn behave like humanoids. In this way, we have much less code to write to make Orcs and Goblins behave as we want them to, because we're reusing the code from Humanoid and Enemy. Constructors are an exception to what is inherited by child classes, as they remain unique to a class, and are never shared. When a constructor is called in a child class, however, the constructor of its parent class is called immediately before. Since classes can have many different constructors, we might want to be able to control which base class constructor is being called. We do this with the keyword "base". By following the parameter list of the child's constructor with a colon, you can explicitly call a specific constructor of the base class, using the keyword "base", in the base constructor's parameter list. If the base class's constructor is not called explicitly, then the default constructor will still be called implicitly. Aside from calling the base class's constructor, you can also use the base keyword to access other members of the base class. This is useful in situations where you wish to access the base class's version of something, because it is different than the derived version. This happens often when overriding functions. For more information on this, see the lesson on Overriding linked below.
How are these videos so easy to understand in comparison to tutorials by others?!?! One video by Unity gives me the straightforward information that ten other videos confused me with!
Cause other people on RUclips are trying to target the widest range of audience possible to the point where it gets unbearable to watch. They teach you programming basics in every videos.
most youyubers are self taught. this explanation is straight from textbook examples we saw in college. there is a lot more going on with inheritence than jus twhat's in this video, but it's an excellent primer! I love it!
It's probably a good description but no examples or applications. Why should I do this? Instead of attaching the base class of my script to my gameobjects for example
The conventional answer is that you would use inheritance for an is-a relationship (dog is an animal) and composition (giving the class an instance of the other class) for a has-a relationship (car has an engine). There is a movement now that hate inheritance and would say not to use it.
Many things, example: You have items in your game. You have an item class You probably want to differentiate between these items but make them share somethings You can just create another class for a specific item and derive it from the item class
I have a small question on this. Say you want a make a base class called 'TreasureChest' that gets hit by a player and will perform an opening animation or whatever. Then you want different scripts to determine what is inside the chest (money, item, enemy, etc). Is there a way to let the Player object call 'OpenChest' without knowing if the objet contains the "ItemChest" or "MoneyChest" script?
Sounds like you need a Chest parent object that can be opened. To take it further than that you can make a "Container" object. A different approach would be interfacing. IF you want something openable you simply create an IOpenable interface with an Open() method that any class implementing such an interface must override. If you want basic logic available across the board you'll want to go with inheritance. If you want to make sure something is implemented uniquely by each implementing class go the interface route. You can also do both. Have a Container that implements IOpenable and provide an basic implementation to Open() method in Container. Inheristing Chest objects can fall upon that methodology or override their own, and the fact that they're IOpenable, the Open() method can always be called. Above all else, ask yourself to what degree you want such freedom. Often times the simpler approach is best, and in the future a simple system can be refactored and expanded upon quite easily. The trick is to make sure you don't rely upon and couple tightly such a system throughout your project. Otherwise refactoring / restructuring code will not be so trivial.
If I have a public variables of type GameObject in parent class, why I have to assign them in parent class AND in child class as well? How can I use the base class version of the game-object variable?
@@napoleonbonerfarte6739 Actually once you have child object you don't have to attach the parent object on the game object. So just using a child script and assigning variables.
I have an unrelated but still under the subject question: I've watched a whole playlist of these videos a couple of years ago, so, why upload it again with a different thumbnail?
Intermediate?.......... So on a scale from 1 to 1,000,000 where every number describes a level of programming knowledge, intermediate starts somewhere around 6?
Intermediate not for programming, but for programming in Unity. It's very different. You could build a basic game literally by just knowing what variables and functions are and never getting close to the concept of class. A lot of stuff is managed by the engine and by the editor, and you just need to access the tools and functions that Unity provides.
@@DylanBurke Not so basic. I know the basics, i didn't know this, maybe you have a different definition of intermediate but for Unity this is just that, since it's not a fundamental concept. You can do tons of things without knowing this, wich makes this not part of the basics.
@@alessandromangaXD Or maybe you're suffering from not knowing how much you don't know? Just because you can "do tons of things" without knowing this doesn't mean this isn't basic knowledge; perhaps it means Unity can let you do a lot with little knowledge. Regardless of how much "work" you output in Unity, this video is very basic overview of a very basic concept. I can "do tons of things" by using a video camera, shooting a shot, stopping, shooting another shot, stopping, and so on.. However, that does not mean lining up and rearranging clips in Premiere is more than a basic concept.
![Kodak Black - Catch Fire [Official Music Video]](http://i.ytimg.com/vi/A4ch-olIuZo/mqdefault.jpg)
Transcript:
The scripting languages that Unity supports have a feature called Inheritance. Inheritance is one of the cornerstones of Object-Oriented Programming, or OOP for short. When a class inherits from another, it gains the features of the class it inherits from. When talking about inheritance, the class that is being inherited from is called the "Parent", or base class. The class that is inheriting is called the "Child" or derived class. The result of inheritance is that items that exist in the parent class will also be available in the child class. Therefore, methods and variables can be used in the child class as if it was the parent class. For example, assume you have a parent class called "Class A", which contains two methods: Dance() and Sing(). If you have another class, "Class B", which inherits from Class A, then Class B will also have the two methods, Dance() and Sing(). These methods do not need to be created in Class B because they already exist in Class A. When dealing with inheritance, there are three access modifiers to be aware of: Public, Private, and Protected. You should already be familiar with the concepts of the Public and the Private access modifiers. Just be aware that the features of a parent class that are Public will exist, and be accessible, in the child class, while features that are Private will exist , but not be accessible, in the child class. The Protected access modifier acts as a hybrid between Public and Private. All features of a parent class that are Protected will exist and be accessible in a child class, like Public features, but will not be accessible outside of the parent or child classes, like Private features. It is likely that most of the classes you have used so far in Unity have been inheriting. Indeed, all scripts which are applied as components to GameObjects are MonoBehaviours. This means they have inherited from the MonoBehaviour class. By default, scripts made in Unity follow this format: "public class", followed by the name of the class, followed by a colon, and the class name: MonoBehaviour. The colon in class name, MonoBehaviour, is telling the script that it inherits from MonoBehaviour. To make this class inherit from another class, simply change the name MonoBehaviour to some other class name. To change the class so it doesn't inherit from any parent class, simply remove the colon and parent class name. You might be wondering why our scripts inherit from MonoBehaviour. Items like GameObject, Transform, the Start() method, the Update() method, and more, all come from MonoBehaviour. Our scripts inherit from MonoBehaviour so that we have access to these features. The inheritance structure is hierarchical. A common way to think of inheritance is to think of the animal kingdom. In this example, we'd have a parent class called "Animal". This class would contain all of the definitions and properties necessary to make the class behave like an animal. >From this Animal base class, we might have a couple of child classes: Vertebrate, and Invertebrate. The Vertebrate class would then, in turn, be the parent class for more classes, such as Mammal, Reptile, or Amphibian. Each of these child classes would take the information given by its base class, and add to it. Just like our animal example, inheritance in Object-Oriented Programming is known as an Is-A relationship. This means that the child class is a parent class. A Reptile is a Vertebrate. A Mammal is an Animal. An example in Unity that you may have come across before is: A Capsule Collider is a Collider. This concept will be covered further in the lesson on Polymorphism, linked below. The idea of inheritance can be very useful, and applicable, in game development. We might, for example, have a class called "Humanoid". This class covers all of the things that humanoids should do in our game. We then have two child classes: Enemy and Player. These control the specifics of how players and enemies work in the game while already behaving like humanoids, because they've inherited all of the Humanoid class's members. We could then have two more child classes of Enemy: Orc and Goblin. These already behave like enemies, which in turn behave like humanoids. In this way, we have much less code to write to make Orcs and Goblins behave as we want them to, because we're reusing the code from Humanoid and Enemy. Constructors are an exception to what is inherited by child classes, as they remain unique to a class, and are never shared. When a constructor is called in a child class, however, the constructor of its parent class is called immediately before. Since classes can have many different constructors, we might want to be able to control which base class constructor is being called. We do this with the keyword "base". By following the parameter list of the child's constructor with a colon, you can explicitly call a specific constructor of the base class, using the keyword "base", in the base constructor's parameter list. If the base class's constructor is not called explicitly, then the default constructor will still be called implicitly. Aside from calling the base class's constructor, you can also use the base keyword to access other members of the base class. This is useful in situations where you wish to access the base class's version of something, because it is different than the derived version. This happens often when overriding functions. For more information on this, see the lesson on Overriding linked below.
How are these videos so easy to understand in comparison to tutorials by others?!?! One video by Unity gives me the straightforward information that ten other videos confused me with!
The difference of having amateurs trying to get views on RUclips vs professionals with quality assurance requirements
Perhaps because this video is made by Unity itself you know. Just maybe
Cause other people on RUclips are trying to target the widest range of audience possible to the point where it gets unbearable to watch. They teach you programming basics in every videos.
most youyubers are self taught. this explanation is straight from textbook examples we saw in college. there is a lot more going on with inheritence than jus twhat's in this video, but it's an excellent primer! I love it!
It's probably a good description but no examples or applications. Why should I do this? Instead of attaching the base class of my script to my gameobjects for example
the example is under the link in descrition
The conventional answer is that you would use inheritance for an is-a relationship (dog is an animal) and composition (giving the class an instance of the other class) for a has-a relationship (car has an engine). There is a movement now that hate inheritance and would say not to use it.
@Alan Au Or you can use scriptable Objects
Many things, example:
You have items in your game.
You have an item class
You probably want to differentiate between these items but make them share somethings
You can just create another class for a specific item and derive it from the item class
But they did give examples in the video? With the humanoid class inheriting enemy and player for example.
I have a small question on this. Say you want a make a base class called 'TreasureChest' that gets hit by a player and will perform an opening animation or whatever. Then you want different scripts to determine what is inside the chest (money, item, enemy, etc). Is there a way to let the Player object call 'OpenChest' without knowing if the objet contains the "ItemChest" or "MoneyChest" script?
Sounds like you need a Chest parent object that can be opened. To take it further than that you can make a "Container" object.
A different approach would be interfacing. IF you want something openable you simply create an IOpenable interface with an Open() method that any class implementing such an interface must override.
If you want basic logic available across the board you'll want to go with inheritance. If you want to make sure something is implemented uniquely by each implementing class go the interface route.
You can also do both. Have a Container that implements IOpenable and provide an basic implementation to Open() method in Container. Inheristing Chest objects can fall upon that methodology or override their own, and the fact that they're IOpenable, the Open() method can always be called.
Above all else, ask yourself to what degree you want such freedom. Often times the simpler approach is best, and in the future a simple system can be refactored and expanded upon quite easily. The trick is to make sure you don't rely upon and couple tightly such a system throughout your project. Otherwise refactoring / restructuring code will not be so trivial.
Great serie
That's great
This video was in the playlist but not added. So nobody gets the notification.
He watched it before getting the notification
If I have a public variables of type GameObject in parent class, why I have to assign them in parent class AND in child class as well? How can I use the base class version of the game-object variable?
Put it in the constructor I'm assuming ? I'm also assuming you figured this out.
@@napoleonbonerfarte6739 Actually once you have child object you don't have to attach the parent object on the game object. So just using a child script and assigning variables.
When we call derived class (child) however we get the all method from the base class(parent).
Gooooood 👏
Cool. You r a new brackeys now! Like it. Thank you
Great explanations
I have an unrelated but still under the subject question:
I've watched a whole playlist of these videos a couple of years ago, so, why upload it again with a different thumbnail?
they didn't just re-upload them with new thumbnails, all these videos have been redone and are updated versions of the older ones.
Intermediate?..........
So on a scale from 1 to 1,000,000 where every number describes a level of programming knowledge, intermediate starts somewhere around 6?
Yea, this is definitly programming fundamentals
Intermediate not for programming, but for programming in Unity. It's very different. You could build a basic game literally by just knowing what variables and functions are and never getting close to the concept of class. A lot of stuff is managed by the engine and by the editor, and you just need to access the tools and functions that Unity provides.
@@alessandromangaXD Yeah, I'd still call that pretty damn basic. I feel baited.
@@DylanBurke Not so basic. I know the basics, i didn't know this, maybe you have a different definition of intermediate but for Unity this is just that, since it's not a fundamental concept. You can do tons of things without knowing this, wich makes this not part of the basics.
@@alessandromangaXD Or maybe you're suffering from not knowing how much you don't know? Just because you can "do tons of things" without knowing this doesn't mean this isn't basic knowledge; perhaps it means Unity can let you do a lot with little knowledge.
Regardless of how much "work" you output in Unity, this video is very basic overview of a very basic concept. I can "do tons of things" by using a video camera, shooting a shot, stopping, shooting another shot, stopping, and so on.. However, that does not mean lining up and rearranging clips in Premiere is more than a basic concept.
And I OOP
haha
Kinda useless in my experience because i was pretty much always inheritting from mono behaviour
Intermediate my ass.
homeschool mom and teenager 💚✅
Do you have to do this on every single video?
Nobody cares