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?
Just the first 5 seconds of this video are probably the best piece of advice for Godot ever: you should think of your reusable nodes as if you were extending the engine itself. This way of thinking has made working in Godot so much quicker and more fun for me!
Single Responsibility Principle, where everything should only do one thing well in its own specific context. Excellent explanation of how this works. Very useful, thanks.
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.
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.
This might've been one of the most helpful videos I've found on Godot, I'm very used to working with Java so I was thinking about nodes as if they were Java classes instead of "building blocks" Like how I've seen other Godot devs call them. The example of creating a component and then having it be a field required by another component was particularly helpful in understanding how to use these, thank you so mucH!
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 blew my mind. I just started learning Godot a few weeks ago, and this is exactly what I need to start building toward. I’m wanting to build a game that has a lot of different enemies with some variations on each kind, as well as a lot of weapons for the player that all act differently. Thank you for these ideas on how to do that!
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.
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
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 :)
Literally the best coding tutorial I ever see, and I am not talking about only Godot nor only game development. The way you manage to use composition, which is a hard concept, is brillant.
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.
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 makes more sense to me, thank you. The issue I have with inheritance is that I'm not sure what common data a given base Object/Entity will need before I start exploring possible mechanics/variables, so I end up swip-swapping stuff around until it makes sense. The nice thing about this component approach is that you can manage the grouped data a bit easier in the scene tree. Lately I've been struggling with where to put custom Resources, because you can make a Resource "local to Scene" and mutate the variables away from their defaults, however, I feel like that could get out of hand quickly if I forgot which Scene changed things around.
@@HamRL1 Negative. If your component is added to a parent scene as a PackedScene like how Firebelley does it here, it will be an instance of that scene, which is unique and can be changed however you like for each entity that has one. A Resource, however, when modified, will change on all nodes that have it unless "Local to Scene" is checked. So far I haven't found a good way to use Resources yet, but it's probably worth remembering for later on.
The best way to differentiate between when to use composition and inheritance is to ask, "is it a X?" Like, this enemy skull in the video, "is it a healthbar?" No, it's an enemy that *has* a healthbar, the healthbar needs to be added through composition. "Is it a velocity?" No, it has velocity. "Is it a shadow?" No, it has it. "Is it a pathfinding algorithm?" No, composition. "Is it an enemy?" Yes! It can inherit from the base enemy node, all the enemies has a statemachine, so it can create that and add the initial state, the inherited enemies can override that state to add their own functionality. This is a perfectly reasonable point to have inheritance, and still focus overall on composition. Just make sure to not add something to the base class because "all enemies will *need* X," always ask "but *is* an enemy a X?" You can always add X through composition to the base enemy if all enemies will *have* an X. "Is it an AI?" No, it has an AI. In this video the AI component is so ubiquitous in all moving components that it's left as a function in the enemy itself; which is perfectly fine of course. But if many of them all just look for player then move to them, then you can create a node with that functionality and hook that in to reduce the number of places you need to alter if you make a change. Say that just moving on top of the player doesn't hurt them anymore, they need to "tackle" then it's a good thing if all HuntAndPounce enemies share their AI, allowing you to simply edit that one location to add them distance check and then pounce attack. Or maybe you want to add a faction like system, where there are player aligned survivors that you can rescue. Then if the logic for targeting the player is in a component you can change that one place to alter all the enemies at once. It doesn't even have to be a node on the enemy itself since it's a very tiny function. Just implement it as a static function on the base enemy object, or better yet, the AI components base class. It reduces the clutter in the enemies by having it be "var target = this.FindTarget();" instead of the chained "GetPlayer()?.GlobalPosition ?? GlobalPosition;" And now you can alter the single FindTarget when you realise having survivors of earlier expeditions could be a neat mechanic. Or you want to add a player pet. Or you want to have the tutorial spawn in guards that protect you.
@@SylfaWhile this is a reasonable approach, I can't fully agree with it. "Is it an enemy?" does not necessarily puts the object into another hierarchy. In fact, it's also another trait of this object, like hostility to somebody. If this seems strange to you, imagine you're going to add ability to your game, when a mirror character of your player is spawned as a hostile. You get problems, because your player "isn't enemy" and you can't just instantiate it as an enemy an easy way. But instead, you could just duplicate the player and give them "hostile" trait. In other words, the enmity of the object is also something it is composed of.
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!
I've spent basically my whole computer engineering career in an inheritance mindset. If you asked me, I would composition for godot was too busy. So many nodes for each little thing in each entity, for example. Inheritance melds better with how my mind works. That's why I think unity was so hard for me at first. My godot project is VERY inheritance based. I ignored all composition advice because I thought (and it's probably true that) 'I can do this with inheritance, whatever.' After watching this, I’m questioning everything lol. Great video!
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.
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.
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 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.
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!
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.
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!
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.
I've been looking through godot tutorials for a while now and they all show you how to develop a game from a single scene that has everything. All the functionality in one or few scripts. These 10 minutes gave me more than hours of tutorials before. The information I didn't know I needed.
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 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!
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'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! :)
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!
this is actually so wise and beautiful... i'm only starting to use godot but I hope one day I'll be good enough to create a somewhat big of a game that would include a lot of stuff that I watch on youtube
Man, please continue building courses. Your way of teaching is amazing and rare. You go through a lot of complex steps and make it easy to understand. You build real games and show how to do it. I miss courses where we are taught how to think (like this video here). Godot is for me the best engine for 2D in the market, but I couldn't learn how to build my own game yet because I don't have the strategic knowledge on how to structure a game idea (or break it into small components). But, I upgraded a lot following your course on Udemy! Thank you!
I always knew that this concept existed but it never really clicked until now. Going to have to change the way I conceptualize the architecture of my games to include this framework. Thanks!
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 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 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?
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.
I have been following a tutorial right now and he did show like a hitbox and hurbox scene that can be used multiple times but he kept the hp as just a basic player and enemy attribute. I think its a good idea to keep everything separate like you did, having this whole health component that only changes the health value with the associated signals does feel like an official component like the Timer or something.
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 :)
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
Worked with ECS, but I do enjoy the simplistic way you can achieve composition in Godot. Unity is sort of the same thing with Mono behaviors apart from not forcing you into one component per node. Very neat and concise video!
Thank you! I've seen a few videos explaining composition and this is the one that made it all click for me. Showing an actual game ready non-hypothetical result really helped. All the other explainers I've seen confused me because they just used example projects that where small scale
This is a sigh of relief. I followed a tutorial and as a web dev it was just frustrating me to see it all turn into spaghetti. I asked people around and seems like since most people just wanna get a game together, there's little concern over the code itself besides it just doing what it should, especially for lightweight games. Management was going to be hell for me that way. I am glad that I found this.
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
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.
This was very well explained. I now find myself glad I got into this when I did, as this is how I have always thought of code, and to find that it isn't how it normally is, makes me see why I always had these hang ups in understanding before.
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.
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.
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!!
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.
ngl this is a way better explanation of composition in godot just an extremely simple and straight-forward explanation and shows how powerful composition is.
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.
Just what i needed! - Mario I recently (last week) started my game dev learning journey, and i already have spaghetti brain, and as a result, spaghetti code. Now Godot is making more sense to me, and perhaps i can fix up my spaghetti code now. Thanks youtube man
I totally agree with duplicating code for the state machine. As Sandi Metz brilliantly said : “Duplicating code is better than getting the abstractions wrong”
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.
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.
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 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 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.
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
Thank you so much. THIS is the glue. Every tutorial out there covers a small miscelaneous detail and totally gloss over the important stuff. This is the way the engine was intended to be used, and I needed an explanation like this to understand it.
In general tutorials mostly focus on a specific mechanic in a simple toy environment. Overall architectural design is not that often brought up. (That includes how to handle a large amount of assets, source control, naming conventions, scene management, and things like that).
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
I both love and hate component based systems. When you create bigger, more concrete templates for realistic objects you are going to use, you will not end up having bloated scene but it will be harder to modify everything you might want in the future. On other side if you create smaller components, you might end up writing components you will use once or twice. It's important to write reusable building blocks and I believe in dividing these functionalities into something more generic but doing so prematurely can end up being waste of time. If you have clear design/goal in mind and you see yourself making each enemy so unique that it can't become a template on its own then maybe? It's just these small blocks are supposed to build into bigger ones and these further. So your Skull should ideally just already be instance of customizable Enemy type.
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"
Just the first 5 seconds of this video are probably the best piece of advice for Godot ever: you should think of your reusable nodes as if you were extending the engine itself. This way of thinking has made working in Godot so much quicker and more fun for me!
Single Responsibility Principle, where everything should only do one thing well in its own specific context. Excellent explanation of how this works. Very useful, thanks.
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 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.
This might've been one of the most helpful videos I've found on Godot, I'm very used to working with Java so I was thinking about nodes as if they were Java classes instead of "building blocks" Like how I've seen other Godot devs call them. The example of creating a component and then having it be a field required by another component was particularly helpful in understanding how to use these, thank you so mucH!
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 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.
This blew my mind. I just started learning Godot a few weeks ago, and this is exactly what I need to start building toward. I’m wanting to build a game that has a lot of different enemies with some variations on each kind, as well as a lot of weapons for the player that all act differently. Thank you for these ideas on how to do that!
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.
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
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 :)
Literally the best coding tutorial I ever see, and I am not talking about only Godot nor only game development. The way you manage to use composition, which is a hard concept, is brillant.
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.
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 makes more sense to me, thank you. The issue I have with inheritance is that I'm not sure what common data a given base Object/Entity will need before I start exploring possible mechanics/variables, so I end up swip-swapping stuff around until it makes sense. The nice thing about this component approach is that you can manage the grouped data a bit easier in the scene tree.
Lately I've been struggling with where to put custom Resources, because you can make a Resource "local to Scene" and mutate the variables away from their defaults, however, I feel like that could get out of hand quickly if I forgot which Scene changed things around.
When you modify the base component, does it change on all the nodes it is used on?
@@HamRL1 Negative. If your component is added to a parent scene as a PackedScene like how Firebelley does it here, it will be an instance of that scene, which is unique and can be changed however you like for each entity that has one. A Resource, however, when modified, will change on all nodes that have it unless "Local to Scene" is checked. So far I haven't found a good way to use Resources yet, but it's probably worth remembering for later on.
The best way to differentiate between when to use composition and inheritance is to ask, "is it a X?"
Like, this enemy skull in the video, "is it a healthbar?" No, it's an enemy that *has* a healthbar, the healthbar needs to be added through composition.
"Is it a velocity?" No, it has velocity. "Is it a shadow?" No, it has it. "Is it a pathfinding algorithm?" No, composition.
"Is it an enemy?" Yes! It can inherit from the base enemy node, all the enemies has a statemachine, so it can create that and add the initial state, the inherited enemies can override that state to add their own functionality. This is a perfectly reasonable point to have inheritance, and still focus overall on composition. Just make sure to not add something to the base class because "all enemies will *need* X," always ask "but *is* an enemy a X?" You can always add X through composition to the base enemy if all enemies will *have* an X.
"Is it an AI?" No, it has an AI. In this video the AI component is so ubiquitous in all moving components that it's left as a function in the enemy itself; which is perfectly fine of course. But if many of them all just look for player then move to them, then you can create a node with that functionality and hook that in to reduce the number of places you need to alter if you make a change.
Say that just moving on top of the player doesn't hurt them anymore, they need to "tackle" then it's a good thing if all HuntAndPounce enemies share their AI, allowing you to simply edit that one location to add them distance check and then pounce attack.
Or maybe you want to add a faction like system, where there are player aligned survivors that you can rescue. Then if the logic for targeting the player is in a component you can change that one place to alter all the enemies at once. It doesn't even have to be a node on the enemy itself since it's a very tiny function. Just implement it as a static function on the base enemy object, or better yet, the AI components base class. It reduces the clutter in the enemies by having it be "var target = this.FindTarget();" instead of the chained "GetPlayer()?.GlobalPosition ?? GlobalPosition;" And now you can alter the single FindTarget when you realise having survivors of earlier expeditions could be a neat mechanic. Or you want to add a player pet. Or you want to have the tutorial spawn in guards that protect you.
@@SylfaWhile this is a reasonable approach, I can't fully agree with it. "Is it an enemy?" does not necessarily puts the object into another hierarchy. In fact, it's also another trait of this object, like hostility to somebody. If this seems strange to you, imagine you're going to add ability to your game, when a mirror character of your player is spawned as a hostile. You get problems, because your player "isn't enemy" and you can't just instantiate it as an enemy an easy way. But instead, you could just duplicate the player and give them "hostile" trait. In other words, the enmity of the object is also something it is composed of.
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!
I've spent basically my whole computer engineering career in an inheritance mindset. If you asked me, I would composition for godot was too busy. So many nodes for each little thing in each entity, for example.
Inheritance melds better with how my mind works. That's why I think unity was so hard for me at first.
My godot project is VERY inheritance based. I ignored all composition advice because I thought (and it's probably true that) 'I can do this with inheritance, whatever.'
After watching this, I’m questioning everything lol. Great video!
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.
One of the tutorial channels that are actually fun to watch. I usually feel stressed while watching tutorials but this video felt relaxing
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.
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 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.
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!
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.
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!
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.
I've been looking through godot tutorials for a while now and they all show you how to develop a game from a single scene that has everything. All the functionality in one or few scripts. These 10 minutes gave me more than hours of tutorials before. The information I didn't know I needed.
This is a very specific example with great explanation. Thanks a lot.
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 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!
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.
Well explained, great examples, super clean implementations. Everything is just perfect.
Dude you rock!!! what a nice tutorial, I mean I know about composition, but you have opened my mind a lot for this!!!
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! :)
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!
this is actually so wise and beautiful... i'm only starting to use godot but I hope one day I'll be good enough to create a somewhat big of a game that would include a lot of stuff that I watch on youtube
Man, please continue building courses. Your way of teaching is amazing and rare. You go through a lot of complex steps and make it easy to understand. You build real games and show how to do it. I miss courses where we are taught how to think (like this video here). Godot is for me the best engine for 2D in the market, but I couldn't learn how to build my own game yet because I don't have the strategic knowledge on how to structure a game idea (or break it into small components). But, I upgraded a lot following your course on Udemy! Thank you!
Thank you! More courses are coming (eventually haha)
This is so well put together. Just spewing pure gold constantly, no time wasted. Well done sir
So helpful I never thought about how you can basically make your own nodes to use! Saves so much code!
I always knew that this concept existed but it never really clicked until now. Going to have to change the way I conceptualize the architecture of my games to include this framework. Thanks!
I spent alot of time learning patterns, but this video explained everything i needed. Thanks
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#. 👀
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 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 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.
Wish I found this video before starting my game. Awesome tutorial.
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.
I have been following a tutorial right now and he did show like a hitbox and hurbox scene that can be used multiple times but he kept the hp as just a basic player and enemy attribute.
I think its a good idea to keep everything separate like you did, having this whole health component that only changes the health value with the associated signals does feel like an official component like the Timer or something.
This video was extremely useful and this type of game architecture content is worth its weight in gold. Keep it up!
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 :)
Will definitely be referring back to this as I delve into Godot 4. Always struggled with larger projects ballooning. Many thanks for the insight!
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
Worked with ECS, but I do enjoy the simplistic way you can achieve composition in Godot. Unity is sort of the same thing with Mono behaviors apart from not forcing you into one component per node. Very neat and concise video!
Merci beaucoup. Je n'avais pas vu le développement de jeu sous Godot de cette manière. Thank you 🙏
Thank you! I've seen a few videos explaining composition and this is the one that made it all click for me. Showing an actual game ready non-hypothetical result really helped. All the other explainers I've seen confused me because they just used example projects that where small scale
This is a sigh of relief. I followed a tutorial and as a web dev it was just frustrating me to see it all turn into spaghetti. I asked people around and seems like since most people just wanna get a game together, there's little concern over the code itself besides it just doing what it should, especially for lightweight games. Management was going to be hell for me that way. I am glad that I found this.
Useful summary, man - thank you - the state machine commenting was also very insightful. Kudos!
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
Dude, you basically answered all of my questions on composition in about 10 minutes. Mind: blown.
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.
This was very well explained. I now find myself glad I got into this when I did, as this is how I have always thought of code, and to find that it isn't how it normally is, makes me see why I always had these hang ups in understanding before.
Awesome video. Lightbulb moment, can't thank you enough.
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 have been looking for something just like this! Thank you so much!
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.
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!!
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.
ngl this is a way better explanation of composition in godot just an extremely simple and straight-forward explanation and shows how powerful composition is.
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.
Just what i needed!
- Mario
I recently (last week) started my game dev learning journey, and i already have spaghetti brain, and as a result, spaghetti code. Now Godot is making more sense to me, and perhaps i can fix up my spaghetti code now. Thanks youtube man
I totally agree with duplicating code for the state machine. As Sandi Metz brilliantly said : “Duplicating code is better than getting the abstractions wrong”
Great explanation, such a clean way to create these bits of functionality. Looking forward to giving it a go!
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!
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 :)
honestly, this is really smart I'm suprised I didn't come up with that alone
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.
For anyone who loves code, but is new in godot or gamedev, this video is just art. You open my mind, thx bro..
Great video. Components accepting components (hurtbox taking health ftw) is good design.
Icredible video! I use godot for a time and always struggled to understand that logic. Thanks A LOT, (and happy christmas)
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!
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.
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
I didnt even know that one should prefer composition over inheritance. It makes sense to me now. Thanks much
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 am trying to learn how to architect my projects better. This is a great help!
Another amazing video !
Great explanation and example of how to use composition.
finally i understood this, itll be hard to implement when starting out but this is amazing
Thanks for this masterpiece!
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.
Thanks for this, I was struggling because I too seem to need many specific state machines, so your advice at the end was really helpful
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
Thank you so much. THIS is the glue. Every tutorial out there covers a small miscelaneous detail and totally gloss over the important stuff. This is the way the engine was intended to be used, and I needed an explanation like this to understand it.
In general tutorials mostly focus on a specific mechanic in a simple toy environment. Overall architectural design is not that often brought up. (That includes how to handle a large amount of assets, source control, naming conventions, scene management, and things like that).
@@vast634 thank you for taking the time and effort to address it.
I bought your Udemy course after watching this. Thank you for sharing your approach, it's been really helpful.
I love this design. I need to try this ASAP!
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
Stumbled on this and it really made Godot click for me, finally. Thank you so much for this.
Awesome I was waiting for your awesome devlog finally I can watch peacefully?
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
I both love and hate component based systems. When you create bigger, more concrete templates for realistic objects you are going to use, you will not end up having bloated scene but it will be harder to modify everything you might want in the future. On other side if you create smaller components, you might end up writing components you will use once or twice. It's important to write reusable building blocks and I believe in dividing these functionalities into something more generic but doing so prematurely can end up being waste of time. If you have clear design/goal in mind and you see yourself making each enemy so unique that it can't become a template on its own then maybe? It's just these small blocks are supposed to build into bigger ones and these further. So your Skull should ideally just already be instance of customizable Enemy type.