This! I'm a web developer, and I was scared to start a game dev project because I didn't understand what the architecture of the Godot project should be. Some UA-cam videos recommended inheritance, but that seemed so clunky to me. This video is just what I needed. The community needs more videos like this. That focus on teaching you how to build a complex project in a right way, and not just simple step by step tutorials.
Inheritance is always a terrible idea. It makes your codes rigid and difficult to maintain. This is why I hate UE's architecture since it relies heavily on inheritance. I like Unity's ECS and GameObject/Component paradigm and Godot's node system.
@@nguyenjack2658 You mean gm is superior because it only allows one solution, whereas godot and unity are stupid due to allowing multiple ways of structuring your code?
The best instructions/instructors teach you a way of thinking. A lot of programmers are trained in the OOP paradigm (myself included), so inheritance feels "natural" at first until it turns into a complicated mess. This makes a lot of sense to me, and it emphasizes breaking down a big project into smaller manageable pieces, like building a room-sized skyscraper in Lego.
Composition is still OOP and your second paragraph is exactly why OOP came up as a concept. Universities just have a hard on for inheritance for some reason.
@@SplitWasTaken because it is a massively important concept in many projects Even in this video it could be useful. It seems like the skull is from the Enemy class. If a group of enemies require a different pathfinding that they all share, then they can be a sub-type of enemy that ovewrites the original pathfinding. They inherit all the other nodes, but the pathfinding one they have a new one specific to their subclasses.
This is a great way of framing an approach to coding in Godot. I come from a web development / software development background, and I've almost always done inheritance. I found this video on my quest to code with inheritance and came to understand I was neglecting functionality of the Godot engine. Thanks for helping me understand that.
Love it. Godot has made me a firm believer in the concept of composition in software design, not just in games but also in the regular applications I help make at my job. One thing I found also to be nifty about Godot is being able to use Resources for much of your business logic. It makes it super easy to make unit tests by just making a scene with a single Node and give it the Reaources you want to test in its script... I'm geeking out. Godot is awesome.
Thank you for editing your video down! So many other tutorial videos are unedited, full of "umms", "ahhs", and long pauses that make it a chore to get information out of. This video was quick, to the point, and well-presented.
its always good seeing these kind of tutorials for godot bc its generally easy to get started but building good pratices comes a long way to organize the project and one day finish them.Good stuff.
The thing is, how do I actually build these as a Godot beginner? I understand the pattern and I actually think it's very good, but I wouldn't know how to create components from scratch. Like, are they all Node2D elements? Also I don't wanna copy the code from the video because I actually want to understand what it does. Thank you!
I’m rather new to this as well but it seems that since the task of everything is so specific there isn’t really a node for it beyond Node2D/Node3D, so most of these small nodes are just those. In a way I guess it’s like being able to attach multiple scripts to a single object in Unity or other similar engines with a script to manage the health, the movement and input, the combat ability, etc. Of course it isn’t all those base Nodes (the hurtbox was made with Area2D/3D as a base because collision is complex enough for Godot to have specific built-in functionality for it), so I’d say watch out for that. I’d appreciate the thoughts of someone with more experience, though, I’ve just scratched the surface with Godot and made basic projects in Unity. Hope this helps!
Very useful tutorial. I've been using composition for a couple of my nodes. I found it tedious to create at first but it makes creating new content later much faster and easier. I picked up a few tips from your video, thanks for sharing :)
Just started my godot journey and came across this video. One of the most informative videos out there on how to structure your scenes / nodes. Much appreciated for this and glad I found it early :D
needed this video today. was getting way over my head trying to figure out how to get things modular and nice with interfaces and whatnot. this makes so much more sense. and thanks for using c#
This might be one of the best videos I've seen for understanding how Godot nodes can and should be organized, period. You gave several use cases and examples that demonstrate the composition of disparate simple components. I've been a functional programmer for a long time, and understand composition from a raw software engineering POV, but Godot's node hierarchy in particular was confusing me: How do I know which node should be the root for any given component, and which should be composed "properties" of that root node? You've helped me piece it together from a higher conceptual level than any "Here's what all the nodes in the engine do!" video.
im from an industrial controls background and this video made it finally click for me - the composition method is the same as function block method. you design a function block with generic inputs and outputs and some kind of logic inside. and then you can repeteadly use it throughout the logic controller, as seperate instances for many different objects. makes coding a lot easier but also makes understanding very easy, as once you learn ONE function block (or component in this case) you know how the majority of your game is operating!
This channel is goldmine. You're one of the few godot youtuber who actually know what he's doing and know how to architecture a project beyond toy projects.
I was used to inheritance and it always brings me to a block when I have to make it a little different from its usual behavior. Looking at your video feels like this is a solution for my game so I have to save this video and keep watching this until this sticks to my mind. Although it is a little frustrating to start again from the start using composition but I think its worth it in the long run.
I have literally started Godot a few days and just abt to finish a very simple platform practice game. This video is awesome and came at the most opportune moment.
Wow. These are the concepts I want to see more of for game development. It's a slightly older video, but it's still very relevant and important to using a proper scalable system. I would absolutely love to see more content like this.
One detail of Godot that is highly relevant in this context is the explicit separation of scenes and scripts. When learning Godot, I was used to other engines, where the engine presents you with the option to attach scene components to a script at any time. It took me a few hours of confusion to understand that in Godot it's normal (even expected) to use scenes for typing rather than scripts (i.e. in-code types). Also, on the conversation of composition over inheritance, I think it's best said "(consider) composition before inheritance". Inheritance is still a powerful tool, it's just one that's less flexible (especially in the face of changing requirements) and therefore easier to misuse. For example it's great to extend base-class components to provide niche functionality. You could for example design a phased-health-component for bosses which allows you to retain an entity but use multiple healthbars and fire other triggers (while retaining the base class's existing death trigger).
I know I'm replying to an old comment, but there's an easy line to draw between composition and inheritance. If your concept can work without the other thing, it's probably composed. On the other hand, if it can't work without the other thing, then it's probably inherited. However, there are other methods that are sometimes better than inheritance still, for example dependency injection.
This is very similar to my thought process with my game engine. Make games, then turn them into components so every future game is easier to make. It'll be very, very, very slow at first, but will exponentially speed up. I'm gonna play around with godot a bit this year, and possibly publish one or two games with it. Need to finish learning a couple skills from Unity, then I can (probably) delete it forever. When I get to Godot, this will help me bridge my knowledge from designing my own engine. Thank you so much!
I'm new to Godot. Today i wrote a little node called "MovementValidator", which either returns a bool that shows if my player can move to the next tile. I actually made it as an own Node because i thought it might be nice if i could reuse it for different kind of units aswell. Wasn't sure how i felt about it. This tutorial has shown that i was on the right track all along! :)
I'm not even that good at Godot and kinda gave up, but I've known Roblox for years and now that I understand packages I am going to attempt to use composition through that. It's even better than Godot because packages have the option to auto update or not, they can be shared, they have version control. This is so beautiful, thank you for sharing! I'm sure that utilizing composition in ANY engine will make your game at least 2x more scalable.
Coming back to this, I've currently decided to never go back to Roblox again and stick to Godot for as long as possible. At least 10 years because I'd benefit more if I find ways to improve the engine myself instead of going for the new hype or industry standard. Currently I have a template project meant exactly for this - making assets and components in one place in order to make development faster by just prototyping in that template or copying it to a separate project.
Great explanation of composition. I was only familiar with inheritance from my studies since none of my programming classes mentioned composition at all. However, I've been seeing a lot of composition-related Godot videos recently and I thought that they were essentially the same thing. It's clear now that inheritance is really only top-down while composition is bottom-up. Thank you for the overview!
Thank you for this. This is a huge eye opener for me. Having purchased your Udemy course it's been a treat to see how a design goes from monolithic while testing to composition based and modular. I recently came across using custom resources in Godot 4, and they seem very similar in their use cases, just with storing data and not necessarily logic. I am struggling though because I find the node composition way easier to wrap my head around. I also ran into a bit of a footgun recently when I tried to make an inventory system and items out of resources. It all worked fine until I realized that resources are not unique....so updating one items quantity affected all other duplicate items in the inventory. Anyway, thank you! Sorry for the ramble!
It's useful to know that every resource will be default shared by reference, including resources that are assigned in the editor. You can get around this by duplicating the resource before making your changes!
This is one of those videos that have just such a sheer amount of volume in terms of knowledge and useful information that I flabbergastedly watch this in the hopes that I can absorb at least a fraction of it
Thank you! I’m just getting started with game dev. Following tutorials doesn’t help me figure out how to actually structure a game so this was incredibly insightful
This is so useful, a ton of Godot beginner tutorials tackle programing as a hierarchy project instead of a component one. I understand its because is easier to understand but it'll only hurt in the long run.
This is a great explanation and demo of this concept. I am not totally convinced that inheritance wouldn't be a comparably viable a solution, especially for the claim made at 3:17. A handful of of derived classes off of the base gun and bullet classes with the use of configurations and maybe techniques like dependency injection could get you comparably as far in a comparably scalable manner. Anyways, I am sure you've done what's best for your game. With how Godot is structured, you can never fully get away from composition (not that you even should!)
Absolutely, I wouldn't claim that inheritance isn't viable (apologies if it came across that way) and there are ways to mitigate the risks that come with inheritance. And there are scenarios in which inheritance is clearly preferable to composition. The beauty of programming is that there are multiple viable pathways to the same outcome, and we can choose a strategy that works best for our projects!
If possible, it would seem to me that the best solution would be a mix of inheritance and composition: using inheritance specifically for the _minimum common features_ of certain objects. For example, both types of guns appear to spawn new bullet entities, even if the behaviors of those entities are entirely different. and those spawned bullets will likely all want to use a hitbox to inflict damage on a target Of course, I'm not designing the game, so I can't say with absolute certainty what things will or won't be held in common. But putting the baseline commonalities in a class can still potentially save you some time
Yeah, ridiculous claims like "inheritance stops me from making a gun that shoots worms" only deepen my belief that all the Godot devs preaching this "inheritance is bad" mantra are just bad at inheritance. If inheritance is so bad, then why does Godot use it for all the built-in nodes?
I've been a developer for over a decade and have always taken code structure seriously. When I started out I made a bunch of games, but the more I got experience with other parts of the field, the less I felt I understood how to return to gamedev. Tutorial code always seemed unscalable. I just couldn't figure out how to translate good practices I've learned elsewhere to my projects. I was just working on trying to implement conveyor belts in a new game and trying to avoid tight coupling and having to implement "apply velocity per frame" behavior in every movable node's script... I knew this couldn't be right, so I googled "godot composition" and here I am. This video is really energizing, because it's one of the first I've found where the code shown looks production-quality and enjoyable to work with. I've been bouncing off gamedev for years because I cannot stay motivated when code feels messy. Your compositional style here possibly isn't unique or even that rare, but I'm grateful you took the time to give such a clear example as it's given me some hope I can finally 'click' with gamedev again. Purchased your latest course on udemy. Cheers!
This video is making a fine addition to my collection of Godot tutorials. So glad I found this channel. Really looking forward to doing projects with Godot!!
Very Impressive Tutorial! I was completely lost on how to manage node structures, then I saw this. All my doubts were then cleared in this 10 minutes video.
This was awesome! I’ve seen a lot of people talk about composition, but there is always some strange tethering. This did a great job of showing how to take composition to its natural conclusion.
Very nice explanation. I didn't think about adding nodes to a scene being composition. We can also create a script with a class_name in Godot to use where we only need to reuse a chunk of code. I ended up doing this after searching and watching your video.
A very nice breakdown with an explanation that really made sense to me. Thank you. I am just learning Godot and thinking of it as composition this way helps make the patterns of it seem more logical to me. Your lecturing style is also quite good, unlike some video makers who sound like they're making it up as they go along. You clearly have at least an outline or even a full script.
Statemachines are exactly where I use modularity :D I implemented my own state machine and have edges with conditions like "EndReached" within my AnimationTree that I can easily reuse. With inherited scenes I was able to get the best of both worlds where I use the scenes more like a template. Works well for my player characters so I have to check how it will work with my enemies :)
amazing video, this is exactly the kind of design i was looking for in my game. I just didn't grasp exactly how to make this kind of composition to also use godot features. With this I can make my game, you have my like and subscription
As someone that has used composition for quite a while, I'd suggest expanding on this topic by discussing communication between nodes in depth, to touch on dependency injection and inversion of control, since tightly coupling components defeats a lot of the purpose of composition.
I think Godot itself is structured a bit differently: - container nodes that are bags of stuff and that's where you reference everything; - 'functionality' nodes that work with the built-in systems but are mostly data. - core systems logic that manipulates the functional nodes It sort of looks like your structure, but your container nodes also contain your game systems, I think. I guess the game systems (scripts) living inside a container node is the only way to do it, so the shallower the container structure the more modular everything becomes.
As somebody so used to writing traditional OOP code with inheritance, this was difficult to wrap my head around. But it absolutely pays off, for Godot at least, this is such an easier way of creating a flexible and scalable project. Another great thing about making your components so granular and abstracted is that it makes them easy to reuse in later projects. Your health component for example, that could easily fit into pretty much any game you can imagine, in many different ways. You write it once and you're done.
Hello, here from the future. I love the explanation from this video because we can see things from 2 different perspectives: From one perspective we see the video topic, nodes and modularity making games a lot more scalable. Not only that, but you just trivialized making a new enemy from scratch by adding components and making it extremely easy, while taking the traditional route would make it easy for 1 time but a real chore for a bunch of times. At 8:08 we can see the different scripts, blue ones being pure composition and white ones being custom ones, allowing the creation of an enemy with minimal code. It really is only ironing out the details or defining specific behavior, as said when commentating on the state machines. From another perspective, as an object oriented programmer, this is the best example of classes vs objects: Having the structure in mind to define an enemy is one abstract class, albeit an incomplete one being made whole by "fake" interfaces in the form of node components. When constructing the whole scene with the base node we are "instantiating" the class into a defined structure, adding as many components as required and changing the values of said components as desired (HP, speed, tracking, etc.) In the end we are left with a specific entity to do a specific task, and even if it's duplicated it will be its own entity amongst others. In other words, its own object. Love the video, already liked and subscribed.
Interfaces are also a good shout for generalized modular components, your health component will sign the interface contract then you can make a different health component that works completely differently but so long as that component signs the same contract the rest of your code will treat them the same
this is great, I have no idea how to even begin to integrate this myself but at least it gave me a clear idea of a really good way to organise whatever I'm trying to do
This video has helped me a lot! I've been struggling with inheritance in my game for a while, having to create tons of subclasses to achieve my purposes, but now it's much easier. Thank you!
I came back months later after trying out things. I can in fact confirm something. The state machine should not be generic, I tried it, it's too hard lmao
Been dabbling in programming and making games for a long time as a hobby, more recently using c#. OOP is normal for me. This helped me better understand composition and why it was advantageous for Godot.
there is definitely a tradeoff here. I enjoy having all those "working statements" in one script. I see the difference though, as I do actually use inheritance. I'll consider it
ooh nah this just solved one of my biggest issues in my game rn. i wish i watched this video before starting so i could design my game like this from ground up. i am sadly to far in now
Tip: If you want to edit a specific behavior of one of your generic scene, in a way that's is not really great to use exported variables as options you can do the following: Let say with your HurtBox node you can do a signal that emit to ask the permission for taking damage and pass the variables in that signal. You connect this signal to your root node and add conditions, and if all the conditions are met you call the validate_damage function of your HurtBox node, like that you can even modify the damage etc... Just an idea, tell me if that's great or not ;D
Thanks for the video! I'm a Java developer and looking to get into game development as a hobby. I'm seeing similarities to Spring boot's (java framework) components - where you can string together services/components that handle certain behaviours e.g. caching service, token generation service. Probably not a really useful comment to people here but it's cool to find that familiarity where I wasn't expecting it!
As a seasoned web-dev I'm sure that OOP is mostly about working with Interfaces, and inheritance is very rarely needed (mostly for some design patterns that rely on abstract classes). If I see inheritance on code review it's almost certainly something is done wrong. And yet, in Godot I seemed to struggle with the same idea. It's so weird to see tree-like scenes and think "well, that's a good inheritance hierarchy", when it's actually not at all. And shifting a mindset from inheritance to composition in these terms to split logic to simple parts is pretty hard.
very cool I'm still watching a lengthy tutorial on godot so i haven't worked on my own game projects yet but I'll definitely keep that in mind i probably won't do something like this for my first projects since i wanna do game jams to gain experience but once I'm more comfortable and want to make bigger games, I'll definitely do something like that
This! I'm a web developer, and I was scared to start a game dev project because I didn't understand what the architecture of the Godot project should be. Some UA-cam videos recommended inheritance, but that seemed so clunky to me. This video is just what I needed. The community needs more videos like this. That focus on teaching you how to build a complex project in a right way, and not just simple step by step tutorials.
Inheritance is always a terrible idea. It makes your codes rigid and difficult to maintain. This is why I hate UE's architecture since it relies heavily on inheritance. I like Unity's ECS and GameObject/Component paradigm and Godot's node system.
@@NuttachaiTipprasert Inheritance is okay sometimes. It becomes a problem "when you only have a hammer every problem becomes a nail"
@@nguyenjack2658 You mean gm is superior because it only allows one solution, whereas godot and unity are stupid due to allowing multiple ways of structuring your code?
@@nguyenjack2658 faster doesn't equal better. git gud
@@nguyenjack2658 ok, then go ahead and upload a video of your game that you can make in a week to display your mindset, design, and your "creative"
The best instructions/instructors teach you a way of thinking. A lot of programmers are trained in the OOP paradigm (myself included), so inheritance feels "natural" at first until it turns into a complicated mess.
This makes a lot of sense to me, and it emphasizes breaking down a big project into smaller manageable pieces, like building a room-sized skyscraper in Lego.
I mean it's still OOP just a different "sub paradigm" as an alternative to inheritance
sounds like an ADs)
Composition is still OOP and your second paragraph is exactly why OOP came up as a concept. Universities just have a hard on for inheritance for some reason.
@@SplitWasTaken because it is a massively important concept in many projects
Even in this video it could be useful. It seems like the skull is from the Enemy class. If a group of enemies require a different pathfinding that they all share, then they can be a sub-type of enemy that ovewrites the original pathfinding. They inherit all the other nodes, but the pathfinding one they have a new one specific to their subclasses.
This is a great way of framing an approach to coding in Godot. I come from a web development / software development background, and I've almost always done inheritance. I found this video on my quest to code with inheritance and came to understand I was neglecting functionality of the Godot engine. Thanks for helping me understand that.
Love it. Godot has made me a firm believer in the concept of composition in software design, not just in games but also in the regular applications I help make at my job. One thing I found also to be nifty about Godot is being able to use Resources for much of your business logic. It makes it super easy to make unit tests by just making a scene with a single Node and give it the Reaources you want to test in its script... I'm geeking out. Godot is awesome.
any tips or recommendations on where/how to learn to use resources in Godot?
This is actually beautiful. Pure art in software architecture form
This makes a lot of sense. It also creates a lot less spaghetti and what you might call "over building" than just inheritance.
Thank you for editing your video down! So many other tutorial videos are unedited, full of "umms", "ahhs", and long pauses that make it a chore to get information out of. This video was quick, to the point, and well-presented.
its always good seeing these kind of tutorials for godot bc its generally easy to get started but building good pratices comes a long way to organize the project and one day finish them.Good stuff.
The thing is, how do I actually build these as a Godot beginner? I understand the pattern and I actually think it's very good, but I wouldn't know how to create components from scratch. Like, are they all Node2D elements? Also I don't wanna copy the code from the video because I actually want to understand what it does. Thank you!
I’m rather new to this as well but it seems that since the task of everything is so specific there isn’t really a node for it beyond Node2D/Node3D, so most of these small nodes are just those. In a way I guess it’s like being able to attach multiple scripts to a single object in Unity or other similar engines with a script to manage the health, the movement and input, the combat ability, etc. Of course it isn’t all those base Nodes (the hurtbox was made with Area2D/3D as a base because collision is complex enough for Godot to have specific built-in functionality for it), so I’d say watch out for that. I’d appreciate the thoughts of someone with more experience, though, I’ve just scratched the surface with Godot and made basic projects in Unity. Hope this helps!
Very useful tutorial. I've been using composition for a couple of my nodes. I found it tedious to create at first but it makes creating new content later much faster and easier. I picked up a few tips from your video, thanks for sharing :)
Just started my godot journey and came across this video. One of the most informative videos out there on how to structure your scenes / nodes. Much appreciated for this and glad I found it early :D
One of the tutorial channels that are actually fun to watch. I usually feel stressed while watching tutorials but this video felt relaxing
needed this video today. was getting way over my head trying to figure out how to get things modular and nice with interfaces and whatnot. this makes so much more sense. and thanks for using c#
This might be one of the best videos I've seen for understanding how Godot nodes can and should be organized, period. You gave several use cases and examples that demonstrate the composition of disparate simple components. I've been a functional programmer for a long time, and understand composition from a raw software engineering POV, but Godot's node hierarchy in particular was confusing me: How do I know which node should be the root for any given component, and which should be composed "properties" of that root node? You've helped me piece it together from a higher conceptual level than any "Here's what all the nodes in the engine do!" video.
im from an industrial controls background and this video made it finally click for me - the composition method is the same as function block method. you design a function block with generic inputs and outputs and some kind of logic inside. and then you can repeteadly use it throughout the logic controller, as seperate instances for many different objects. makes coding a lot easier but also makes understanding very easy, as once you learn ONE function block (or component in this case) you know how the majority of your game is operating!
This channel is goldmine. You're one of the few godot youtuber who actually know what he's doing and know how to architecture a project beyond toy projects.
I was used to inheritance and it always brings me to a block when I have to make it a little different from its usual behavior. Looking at your video feels like this is a solution for my game so I have to save this video and keep watching this until this sticks to my mind.
Although it is a little frustrating to start again from the start using composition but I think its worth it in the long run.
I have literally started Godot a few days and just abt to finish a very simple platform practice game. This video is awesome and came at the most opportune moment.
Wow. These are the concepts I want to see more of for game development. It's a slightly older video, but it's still very relevant and important to using a proper scalable system. I would absolutely love to see more content like this.
Well explained, great examples, super clean implementations. Everything is just perfect.
One detail of Godot that is highly relevant in this context is the explicit separation of scenes and scripts. When learning Godot, I was used to other engines, where the engine presents you with the option to attach scene components to a script at any time. It took me a few hours of confusion to understand that in Godot it's normal (even expected) to use scenes for typing rather than scripts (i.e. in-code types).
Also, on the conversation of composition over inheritance, I think it's best said "(consider) composition before inheritance". Inheritance is still a powerful tool, it's just one that's less flexible (especially in the face of changing requirements) and therefore easier to misuse. For example it's great to extend base-class components to provide niche functionality. You could for example design a phased-health-component for bosses which allows you to retain an entity but use multiple healthbars and fire other triggers (while retaining the base class's existing death trigger).
I know I'm replying to an old comment, but there's an easy line to draw between composition and inheritance.
If your concept can work without the other thing, it's probably composed.
On the other hand, if it can't work without the other thing, then it's probably inherited.
However, there are other methods that are sometimes better than inheritance still, for example dependency injection.
This is so well put together. Just spewing pure gold constantly, no time wasted. Well done sir
This is very similar to my thought process with my game engine. Make games, then turn them into components so every future game is easier to make. It'll be very, very, very slow at first, but will exponentially speed up.
I'm gonna play around with godot a bit this year, and possibly publish one or two games with it. Need to finish learning a couple skills from Unity, then I can (probably) delete it forever. When I get to Godot, this will help me bridge my knowledge from designing my own engine.
Thank you so much!
I'm new to Godot. Today i wrote a little node called "MovementValidator", which either returns a bool that shows if my player can move to the next tile. I actually made it as an own Node because i thought it might be nice if i could reuse it for different kind of units aswell. Wasn't sure how i felt about it. This tutorial has shown that i was on the right track all along! :)
I'm not even that good at Godot and kinda gave up, but I've known Roblox for years and now that I understand packages I am going to attempt to use composition through that.
It's even better than Godot because packages have the option to auto update or not, they can be shared, they have version control.
This is so beautiful, thank you for sharing! I'm sure that utilizing composition in ANY engine will make your game at least 2x more scalable.
Coming back to this, I've currently decided to never go back to Roblox again and stick to Godot for as long as possible. At least 10 years because I'd benefit more if I find ways to improve the engine myself instead of going for the new hype or industry standard.
Currently I have a template project meant exactly for this - making assets and components in one place in order to make development faster by just prototyping in that template or copying it to a separate project.
This is a very specific example with great explanation. Thanks a lot.
So helpful I never thought about how you can basically make your own nodes to use! Saves so much code!
Dude you rock!!! what a nice tutorial, I mean I know about composition, but you have opened my mind a lot for this!!!
Great explanation of composition. I was only familiar with inheritance from my studies since none of my programming classes mentioned composition at all. However, I've been seeing a lot of composition-related Godot videos recently and I thought that they were essentially the same thing. It's clear now that inheritance is really only top-down while composition is bottom-up. Thank you for the overview!
I spent alot of time learning patterns, but this video explained everything i needed. Thanks
Thank you for this. This is a huge eye opener for me.
Having purchased your Udemy course it's been a treat to see how a design goes from monolithic while testing to composition based and modular.
I recently came across using custom resources in Godot 4, and they seem very similar in their use cases, just with storing data and not necessarily logic. I am struggling though because I find the node composition way easier to wrap my head around.
I also ran into a bit of a footgun recently when I tried to make an inventory system and items out of resources. It all worked fine until I realized that resources are not unique....so updating one items quantity affected all other duplicate items in the inventory.
Anyway, thank you! Sorry for the ramble!
It's useful to know that every resource will be default shared by reference, including resources that are assigned in the editor. You can get around this by duplicating the resource before making your changes!
oh wait theres a udemy course? 😮 faak i want this guy to teach me godot 😢 (pardon my french)
This is one of those videos that have just such a sheer amount of volume in terms of knowledge and useful information that I flabbergastedly watch this in the hopes that I can absorb at least a fraction of it
Wish I found this video before starting my game. Awesome tutorial.
This is awesome! Changed the way I'm structuring my whole project that I recently started and probably the future projects as well, thank you so much!
You've also made me change from GDScript to C#. 👀
Thank you! I’m just getting started with game dev. Following tutorials doesn’t help me figure out how to actually structure a game so this was incredibly insightful
This is so useful, a ton of Godot beginner tutorials tackle programing as a hierarchy project instead of a component one. I understand its because is easier to understand but it'll only hurt in the long run.
This is a great explanation and demo of this concept. I am not totally convinced that inheritance wouldn't be a comparably viable a solution, especially for the claim made at 3:17. A handful of of derived classes off of the base gun and bullet classes with the use of configurations and maybe techniques like dependency injection could get you comparably as far in a comparably scalable manner.
Anyways, I am sure you've done what's best for your game. With how Godot is structured, you can never fully get away from composition (not that you even should!)
Absolutely, I wouldn't claim that inheritance isn't viable (apologies if it came across that way) and there are ways to mitigate the risks that come with inheritance. And there are scenarios in which inheritance is clearly preferable to composition.
The beauty of programming is that there are multiple viable pathways to the same outcome, and we can choose a strategy that works best for our projects!
@@FirebelleyGames Interfaces are also a great option to get polymorphism without the coupling that comes with inheritance.
If possible, it would seem to me that the best solution would be a mix of inheritance and composition: using inheritance specifically for the _minimum common features_ of certain objects. For example, both types of guns appear to spawn new bullet entities, even if the behaviors of those entities are entirely different. and those spawned bullets will likely all want to use a hitbox to inflict damage on a target
Of course, I'm not designing the game, so I can't say with absolute certainty what things will or won't be held in common. But putting the baseline commonalities in a class can still potentially save you some time
Yeah, ridiculous claims like "inheritance stops me from making a gun that shoots worms" only deepen my belief that all the Godot devs preaching this "inheritance is bad" mantra are just bad at inheritance. If inheritance is so bad, then why does Godot use it for all the built-in nodes?
the thing is that, dependency injection in some sense is just a way to mimick composition using inheritance.
I've been a developer for over a decade and have always taken code structure seriously. When I started out I made a bunch of games, but the more I got experience with other parts of the field, the less I felt I understood how to return to gamedev. Tutorial code always seemed unscalable. I just couldn't figure out how to translate good practices I've learned elsewhere to my projects. I was just working on trying to implement conveyor belts in a new game and trying to avoid tight coupling and having to implement "apply velocity per frame" behavior in every movable node's script... I knew this couldn't be right, so I googled "godot composition" and here I am.
This video is really energizing, because it's one of the first I've found where the code shown looks production-quality and enjoyable to work with. I've been bouncing off gamedev for years because I cannot stay motivated when code feels messy. Your compositional style here possibly isn't unique or even that rare, but I'm grateful you took the time to give such a clear example as it's given me some hope I can finally 'click' with gamedev again.
Purchased your latest course on udemy. Cheers!
This video is making a fine addition to my collection of Godot tutorials. So glad I found this channel. Really looking forward to doing projects with Godot!!
Very Impressive Tutorial! I was completely lost on how to manage node structures, then I saw this. All my doubts were then cleared in this 10 minutes video.
Useful summary, man - thank you - the state machine commenting was also very insightful. Kudos!
Dude, you basically answered all of my questions on composition in about 10 minutes. Mind: blown.
This was awesome! I’ve seen a lot of people talk about composition, but there is always some strange tethering. This did a great job of showing how to take composition to its natural conclusion.
honestly, this is really smart I'm suprised I didn't come up with that alone
Merci beaucoup. Je n'avais pas vu le développement de jeu sous Godot de cette manière. Thank you 🙏
Very nice explanation. I didn't think about adding nodes to a scene being composition. We can also create a script with a class_name in Godot to use where we only need to reuse a chunk of code. I ended up doing this after searching and watching your video.
A very nice breakdown with an explanation that really made sense to me. Thank you. I am just learning Godot and thinking of it as composition this way helps make the patterns of it seem more logical to me.
Your lecturing style is also quite good, unlike some video makers who sound like they're making it up as they go along. You clearly have at least an outline or even a full script.
Awesome video. Lightbulb moment, can't thank you enough.
Statemachines are exactly where I use modularity :D
I implemented my own state machine and have edges with conditions like "EndReached" within my AnimationTree that I can easily reuse.
With inherited scenes I was able to get the best of both worlds where I use the scenes more like a template. Works well for my player characters so I have to check how it will work with my enemies :)
I have been looking for something just like this! Thank you so much!
amazing video, this is exactly the kind of design i was looking for in my game.
I just didn't grasp exactly how to make this kind of composition to also use godot features.
With this I can make my game, you have my like and subscription
Will definitely be referring back to this as I delve into Godot 4. Always struggled with larger projects ballooning. Many thanks for the insight!
As someone that has used composition for quite a while, I'd suggest expanding on this topic by discussing communication between nodes in depth, to touch on dependency injection and inversion of control, since tightly coupling components defeats a lot of the purpose of composition.
I think Godot itself is structured a bit differently:
- container nodes that are bags of stuff and that's where you reference everything;
- 'functionality' nodes that work with the built-in systems but are mostly data.
- core systems logic that manipulates the functional nodes
It sort of looks like your structure, but your container nodes also contain your game systems, I think.
I guess the game systems (scripts) living inside a container node is the only way to do it, so the shallower the container structure the more modular everything becomes.
I started your course yesterday and found your channel right now by accident. You're a great teacher and I'm glad to be your pupil :)
As somebody so used to writing traditional OOP code with inheritance, this was difficult to wrap my head around. But it absolutely pays off, for Godot at least, this is such an easier way of creating a flexible and scalable project.
Another great thing about making your components so granular and abstracted is that it makes them easy to reuse in later projects. Your health component for example, that could easily fit into pretty much any game you can imagine, in many different ways. You write it once and you're done.
Hello, here from the future. I love the explanation from this video because we can see things from 2 different perspectives:
From one perspective we see the video topic, nodes and modularity making games a lot more scalable. Not only that, but you just trivialized making a new enemy from scratch by adding components and making it extremely easy, while taking the traditional route would make it easy for 1 time but a real chore for a bunch of times. At 8:08 we can see the different scripts, blue ones being pure composition and white ones being custom ones, allowing the creation of an enemy with minimal code. It really is only ironing out the details or defining specific behavior, as said when commentating on the state machines.
From another perspective, as an object oriented programmer, this is the best example of classes vs objects: Having the structure in mind to define an enemy is one abstract class, albeit an incomplete one being made whole by "fake" interfaces in the form of node components. When constructing the whole scene with the base node we are "instantiating" the class into a defined structure, adding as many components as required and changing the values of said components as desired (HP, speed, tracking, etc.) In the end we are left with a specific entity to do a specific task, and even if it's duplicated it will be its own entity amongst others. In other words, its own object.
Love the video, already liked and subscribed.
I didnt even know that one should prefer composition over inheritance. It makes sense to me now. Thanks much
For anyone who loves code, but is new in godot or gamedev, this video is just art. You open my mind, thx bro..
I'm still completely new to both coding/Godot but I have a feeling I'll be coming back to this tutorial when I get more confident!
was not ready for the worm gun
Interfaces are also a good shout for generalized modular components, your health component will sign the interface contract then you can make a different health component that works completely differently but so long as that component signs the same contract the rest of your code will treat them the same
this is great, I have no idea how to even begin to integrate this myself but at least it gave me a clear idea of a really good way to organise whatever I'm trying to do
Great video. Components accepting components (hurtbox taking health ftw) is good design.
I bought your Udemy course after watching this. Thank you for sharing your approach, it's been really helpful.
i have watched the tutorial a while back when i started with godot and didnt really understand
now however i did udnerstand and it was quite awesome!
This video has helped me a lot! I've been struggling with inheritance in my game for a while, having to create tons of subclasses to achieve my purposes, but now it's much easier. Thank you!
This just makes sense to my programmer brain. It’s like object oriented programming but for nodes.
I came back months later after trying out things.
I can in fact confirm something.
The state machine should not be generic, I tried it, it's too hard lmao
Icredible video! I use godot for a time and always struggled to understand that logic. Thanks A LOT, (and happy christmas)
Been dabbling in programming and making games for a long time as a hobby, more recently using c#. OOP is normal for me. This helped me better understand composition and why it was advantageous for Godot.
Very clear and useful example of composition 🤯
finally i understood this, itll be hard to implement when starting out but this is amazing
Thanks for this masterpiece!
This is exactly the video I needed my man.
Another amazing video !
Great explanation and example of how to use composition.
First video I've seen by you and honestly completely rewrote how I think about modular design. Totally subscribing.
This was so useful man! II really wanted to implement composition in my game project. Thanks to you it will be way easier now :) Cheers!
there is definitely a tradeoff here. I enjoy having all those "working statements" in one script. I see the difference though, as I do actually use inheritance. I'll consider it
Thanks for your work explaining and creating this Video. 💙
ooh nah this just solved one of my biggest issues in my game rn. i wish i watched this video before starting so i could design my game like this from ground up. i am sadly to far in now
Man made a Unity like architecture in Godot, I like it.
Im so happy I found this. I have such a hard time with this stuff and this was so helpful :D. Been trying to find a vid like this
Had to re-watch this once per month until it finally clicked. 🎉
🤯 your video is like discovering a secret treasure chest !
It'd be cool to see a larger example of an entity with state transitions.
Wow, this was great! Thank you.
Tip: If you want to edit a specific behavior of one of your generic scene, in a way that's is not really great to use exported variables as options you can do the following:
Let say with your HurtBox node you can do a signal that emit to ask the permission for taking damage and pass the variables in that signal.
You connect this signal to your root node and add conditions, and if all the conditions are met you call the validate_damage function of your HurtBox node, like that you can even modify the damage etc...
Just an idea, tell me if that's great or not ;D
I started working in a similar way a while ago... Your idea is way faster than mine tho lol, gotta use this structure, thank you for sharing fellow
very focused tutorial with specific examples, great!! subscribed.
I don't use Godot, but this tutorial was fantastic. Great job!
Great stuff. This makes a lot sense for me.
This is amazing. I'm definitely going to use this. Thanks!
This video has been really usefull I've been searching how scale game and this was perfect. Good Job!
Ive watched this video like 5 times its so helpful
Thanks for the video! I'm a Java developer and looking to get into game development as a hobby. I'm seeing similarities to Spring boot's (java framework) components - where you can string together services/components that handle certain behaviours e.g. caching service, token generation service.
Probably not a really useful comment to people here but it's cool to find that familiarity where I wasn't expecting it!
I actually do both! Compositing fro smaller mechanics and inheritance for more complex objects, e.g. different types of same enemy
This was amazingly insightful, thanks!
Great video, exactly what I was looking for )
Will be thinking now how to make mana and health components without duplicating code
As a seasoned web-dev I'm sure that OOP is mostly about working with Interfaces, and inheritance is very rarely needed (mostly for some design patterns that rely on abstract classes). If I see inheritance on code review it's almost certainly something is done wrong.
And yet, in Godot I seemed to struggle with the same idea. It's so weird to see tree-like scenes and think "well, that's a good inheritance hierarchy", when it's actually not at all. And shifting a mindset from inheritance to composition in these terms to split logic to simple parts is pretty hard.
very cool
I'm still watching a lengthy tutorial on godot so i haven't worked on my own game projects yet
but I'll definitely keep that in mind
i probably won't do something like this for my first projects since i wanna do game jams to gain experience but once I'm more comfortable and want to make bigger games, I'll definitely do something like that