Inheritance is a really valuable tool, but I would highly recommend not limiting yourself to it. The other part of the equation is composition, and it's equally powerful, but often times it's can be the better solution to some of the problems you've pointed out. Especially when it comes to adding features, composition can go the extra mile that inheritance at some point just can't.
Well now I know what that inherited scene button does, really useful! Thanks! And in Godot you can do this in two ways, with Nodes/Scenes like shown in this video, and with Resources. Creating custom resources is a lifesaver, it allows you to store and edit properties in one file or file type, that multiple scripts can look at at will. For example, some common player stats: Health, ammo, score etc. Typically you store those on the player itself, but now if you change scenes, that becomes a problem. Your UI needs to know where the player is at all times, and so on and so forth. Those stats can be put in a custom resource instead, meaning that now it's one of your game files that can be accessed at runtime, so anyone who needs the information can access it even if the player no-longer exists. More advancedly, the Pokémon example. Outside of a base scene, you don't really need to create sub-scenes for every pokémon. That would mean that changing properties involves going through your list of nodes and opening all those scene. With a custom resource, you can create a list of all the properties that can be changed (with default values too), and then create your pokemon that way as files (ignoring the issue of unique pokemon at runtime which is also possible this way). Now you can edit only the important properties, and the base scene can just apply them to itself when needed. As complexity rises, you may need to layer multiple resources but it's better than trying to manage a complex scene. (For Unity, the equivalent is ScriptableObjects)
Wow, thanks so much for letting me know about resources. That sounds like a game changer! Definitely going to read up on it and see how I can implement it to my game. The examples that you provided is definitely insightful!
Isn't composition better for this in Godot? For example adding HP component may be more flexible because I can use it for many things, not only characters...
Thanks for pointing this out. On hindsight, this is a very poorly made video. It's true that composition would make components more flexible and reusable and in most case, that would suffice. Inheritance should only come into play when your instances share more similarities than differences. In such cases, adding more code to the base components would just create bloat and make it prone to bugs. While creating more components for the similar behavior creates a lot of repeated code. Using composition, one common approach would be to add MP signals and functions to the HP component and be done with it. Or to create a separate node to handle MP, even if there's reusable code in the HP component. Using inheritance, I would make the HP component generic, and create inherited scenes for HP and MP component. Both uses the same code to update X value, but both would have X defined differently, to be HP vs MP.
Inheritance is a really valuable tool, but I would highly recommend not limiting yourself to it. The other part of the equation is composition, and it's equally powerful, but often times it's can be the better solution to some of the problems you've pointed out. Especially when it comes to adding features, composition can go the extra mile that inheritance at some point just can't.
Thanks so much for pointing this out, going to be spending more time reading up on composition!
Well now I know what that inherited scene button does, really useful! Thanks!
And in Godot you can do this in two ways, with Nodes/Scenes like shown in this video, and with Resources. Creating custom resources is a lifesaver, it allows you to store and edit properties in one file or file type, that multiple scripts can look at at will.
For example, some common player stats: Health, ammo, score etc. Typically you store those on the player itself, but now if you change scenes, that becomes a problem. Your UI needs to know where the player is at all times, and so on and so forth. Those stats can be put in a custom resource instead, meaning that now it's one of your game files that can be accessed at runtime, so anyone who needs the information can access it even if the player no-longer exists.
More advancedly, the Pokémon example. Outside of a base scene, you don't really need to create sub-scenes for every pokémon. That would mean that changing properties involves going through your list of nodes and opening all those scene. With a custom resource, you can create a list of all the properties that can be changed (with default values too), and then create your pokemon that way as files (ignoring the issue of unique pokemon at runtime which is also possible this way). Now you can edit only the important properties, and the base scene can just apply them to itself when needed. As complexity rises, you may need to layer multiple resources but it's better than trying to manage a complex scene.
(For Unity, the equivalent is ScriptableObjects)
Wow, thanks so much for letting me know about resources. That sounds like a game changer! Definitely going to read up on it and see how I can implement it to my game. The examples that you provided is definitely insightful!
In my first custom Godot project I didn't even duplicated the node. I just made the same steps over and over (82 times) 😅
that's some high level patience!
Isn't composition better for this in Godot? For example adding HP component may be more flexible because I can use it for many things, not only characters...
Thanks for pointing this out. On hindsight, this is a very poorly made video.
It's true that composition would make components more flexible and reusable and in most case, that would suffice.
Inheritance should only come into play when your instances share more similarities than differences.
In such cases, adding more code to the base components would just create bloat and make it prone to bugs. While creating more components for the similar behavior creates a lot of repeated code.
Using composition, one common approach would be to add MP signals and functions to the HP component and be done with it. Or to create a separate node to handle MP, even if there's reusable code in the HP component.
Using inheritance, I would make the HP component generic, and create inherited scenes for HP and MP component. Both uses the same code to update X value, but both would have X defined differently, to be HP vs MP.
Interesting!
thanks!
'You are using Godot incorrectly' not wrongly.
That's a big negative, Frog Rider.
We use *BIG WRONGLY* in this illiterate household.
Guy's a Chink, look at his about page. The entire country is probably illiterate.
thanks for the correction!
1:40 Is that game with senkuu and the other characters from dr.stone an actual game? if so where can i get it?
that's actually a clip from Dr Stone S3E1, would be cool if there's an actual game!
@@gamedevaki damn that's cool, maybe in the future i'll try to make a clone