-- DEMO PROJECT -- Many people have been asking for a demo project. Here it is! 👉github.com/WhoStoleMyCoffee/ComponentsDemo 2:50 CORRECTION: The subtitle made it seem like Bevy was outdated or something. What I meant was that "Bevy is the 2nd most popular game engine on Github" might be outdated. I hope this helps you on your journey :)
Agree. It does seem like there's a small confusion there, just from how he puts emphasis on Entity Component-systems, as opposed to Entity Component System, which has three strict parts and is about separating the data from the behavior, but a well put together video regardless.
"The problem with OOP" you listed problems with deep inheritance, which is not a necessary part of OOP. This is not the '90s anymore, components and interfaces have been the standard for OOP for a long time. "Composition over Inheritance" (which is the concept you described here) was mentioned in the book "Design Patterns: Elements of Reusable Object-Oriented Software" back in 1994. As you can tell from the title of the book, composition/components are a technique of OOP. "ECSs" You're not describing ECS, you're just describing components. You're using OOP with components, this is not ECS. Unity functions in the exact same way with built-in components as part of the engine, and it is OOP. ECS is mainly about optimizing the update loop so that similar things are grouped together which reduces CPU cache misses. A common misconception is that ECS is just "a system with entities and components" but an Entity, a Component and a System are three separate things which have specific uses within the paradigm of ECS. You can do regular OOP with entities and components. One talk I would recommend is "Bob Nystrom - Is There More to Game Architecture than ECS?" which discusses the misunderstanding of what ECS is and how to instead implement well structured OOP architecture. You can also look up "Game Programming Patterns" by Bob Nystrom which is free online and explains a bunch of different programming patterns which you can use to solve issues with game architecture.
Ahaha i was just gonna write about this, i love OOP and one of my pet peeves is when people look down on OOP just because of deep inheritnace, which is not even a problem anymore as literally every material on OOP says use composition on a "Has a" relationship and use inheritance on a "Is A" relationships. Example - A car "has a" wheel(s) vs a car "is a" vehicle. A car here would inherit from a vehicle class, but be composed of wheels
I was gonna say how I would have pushable be a child of the gridobject script, and interactable be its own script, and attach both. But this is way more fleshed out.
Aye. As soon as the video mentioned "let's have everything inherit GridObject", I already knew this was just going to be the age-old composition vs. inheritance discussion again. It's good for people getting started with _learning programming_ in general, but it's not something specific to _learning Godot._
Was going to say the same thing. Starting the video I was just thinking "I learn this back in 1996 when I first started dabbling in C++!. Surely this can't be a new thing again. And don't call me Shirley!"
Doesn't change the fact that OOP is just a bad concept which works great in simple examples but falls miserable and creates unmaintanable mess with anything even remotely complex.
The thing about this approach that everyone keeps talking about, is that if you want to make a DataType (ie: an enemy, boss, item, etc) that's slightly more complex than the rest, you'd have to make another node with another new script to implement that functionality... And then later on add another one for that particular functionality of that particular DataType, and so on until you have a bunch enemy nodes on screen with 10 component nodes each with it's separate instances of those scripts (and in Gdscript at that, which is not optimized for this) during runtime. To hammer it in more clearly, this is a very CPU-taxing way of implement common and unique functionality. What I usually do if you're wondering, is just make a C# script for every DataType I want to add to my game (usually enemies or items), and make them inherit some interfaces for common functionality. Then if I want to add unique functionality to that particular DataType, I just have to change the script attached to it instead of adding another script. With this setup instead of having thousands nodes with tens of thousands of script instances, you get a few dozens nodes with more-or-less the same amount of script instances. Good video though, just saying this cuz I keep seeing people w this exact same setup and complaining it runs poorly
@@ClockworkGearhead It's not about the size, but about the functionality. If you're making a game where lots of functionality needs to be interchanged regularly, then modular design is great. But if you're just making a platformer or something, it's very over-engineered and a waste of time.
1:54 - "Object oriented programming would tell you that's not possible". Stopped watching here. I don't understand why people feel the need to speak dishonestly when they could just get to the point they want to make. Setting up a bad object hierarchy and then blaming object oriented programming for allowing you to write bad code is a strange strawman to use here. It's like if I wrote positive integer addition recursively in lisp and then blamed functional programming as a whole for being slow.
Instead of using child nodes, you could create instances of the component classes on the parent class in-code. This can simplify the tree structure so it isn't cluttered visually. Perhaps you could have one single EntityComponentSystem class that all classes inherit from, and which includes the logic for attaching child components to new parent classes using factories, and also invokes the frame-by-frame processing logic for each of the child components so that each child component is guaranteed to be invoked during regular processing or some other events.
I wouldn't invent a whole new system if the engine's built-in works just fine. Less maintenance fee and kinda the whole point of using an engine. I agree child nodes isn't a requirement in a way, but it's just a clutter of tree vs inspector if you need exported variables. Could also group all the script components in a single node and hide it away.
This is very helpful! I have to say -- I really love the presentation in this video. I've recently been very interested in storytelling in things like teaching/marketing, etc., and this is one of the best examples of practical storytelling I've seen in a programming video for some time, compared to the myriad "hey guys, here's how you do the thing" presentations. This was super engaging.
The flexibility of godot blew my mind when I swapped from Unity. I can use a component architecture while being more consistently to OOP. I started programming with C++ so OOP is just the way I think, but i recognize the benefits of a component system Having the ability to just use a component base thought process on command when i find it convenient is amazing to me
Nice video! A baba is you type game was a great way to broach the topic. While I love the components over inheritance approach godot promotes, I do sometimes find myself wishing godot had other OOP features like generics and multiple inheritance.
thanks im obseesd with components so I really loved the part where you tell me I can use both idk why I get so fixated on a single approach when i learn about it lmao.
Excellent video, thank you for your neatly edited explanation. I've had this issue for quite some time and thansk to your video I will now use more composition than I did before
Great video! This method seems to be the most logical way to remove dependencies in godot. I wish there was a tutorial on using Metadata for this use case.
I've read an article about composition recently and I've gotta say they didn't explain it as well as you do. It made me more confused as to why someone would create a bunch of vague classes that just gonna pollute the namespace. Good job!
The usual manner to do things in OOP without deep inheritance for everything is using Mixins, basically taking the idea of the inheritance and making them into ingredients which you can mix together to get combined behavior in the class. (Godot doesn't inherently support Mixins out of the box, but emulating the behavior in Godot is not hard)
This is why I think in programming in general without double inheritance, when deciding what to inherit or compose you focus on what methods exist in both but differ including initializers but then you run into not all programming languages allowing initilizers to be inherited. Multi inheritance makes inheritance as a concept mutch more powerful.
great video, even though I don't know how to use the game engine this way of thinking can be implemented to most projects without being limited to one game engine. Not to mention you explain everything well, Thanks!
I like your video, I agree with your ideas. Somewhere I read the following thought: "imagine that you are improving the engine by adding your own nodes" - this influenced me, I began to write very simple primitive components, if you put them together, some kind of complex structure will work, it's quite fun. I remember I started with Sprite3d, expanded it to FollowSprite3d, it showed where the RayCast3D node encountered a collision, you can add/remove this node at any time and it will not affect the work in any way, it is a pleasant experience. After that, I made the interaction, it's just 2 nodes, a raycast and a receiver, 1 "connection" signal and a link to the object, that's all, it gave so much room for logic, while it remained at the level of the simplest node components.
There's an unofficial extension for Godot called Godex which adds support for ECS as a subsystem. You'd have to compile the engine from the source though. All of this signifies that while Godot may imitate ECS, it cannot fully embody it. If you find yourself in this situation, consider switching to an engine that is built on ECS principles from the ground up. Doing so could save you from a lot of frustration.
I did something similar to this in my game where I have an enum that tells effects when they should happen in battle. These timings get applied when the effects are initialized. The function that gets passed into the constructor will execute when the listed time comes, so ONTURN will execute on turn and ONATTACK will execute when the entity attacks. I also paired this with ONWHOM which basically says which party it’s going to act on. It’s a neat little thing and I have yet to finish all the 11 different timings but I think it’s something that’s worth while, especially for differentiating between poison, burn, and bleed.
What about interfaces/traits? One object can inherit from many interfaces. So you can have like, partial class Box : Node2D, IPushable, IInteractable, and partial class Lever : Node2D, IInteractable where IInteractable and IPushable are interfaces
1:06 what exactly makes the parameters/methods useless? I worked on a puzzle game where I used the technique you described; every puzzle item derived from the same type and I simply configured its settings differently to enable or disable different traits. One of the benefits of this approach is its ability to allow me to transform state really easily; when a wood block is disintegrated by a fire ball, I simply switch canPush to off. How would your system handle this? Would it not entail adding/removing components? Surely this would be more difficult to manage.
Using both is the correct option, like you said. The moment I learnt about ECS, I upgraded my pawns to use 2 simultaneous state machines. you can see the results you know where
I have been struggling to reasoning over exactly how to do something like this. Ie having a unit, which is either ranged, melee or a mix of them. This is a great option for adding those clasifications and adjusting their targeting based on it. Thanks!
I clicked on this video only because of the thumbnail. I started using this seemingly useless node while making my last game jam game by just adding a script to it and having it exist in the main scene tree. like for a sound manager or a score manager which I later found out that can be done by auto loads. then I started to add scripts to them in the way that you described first with out the metadata. I am no programmer and my code is worse than spaghetti but it is great to see that I was on the right track. GREAT video! very well explained Please keep doing what you are doing .
when this clicked for me it really made my dev so much easier, especially since you can reuse those components, that you for sharing the meta trick, I was always using get node, but using that is muuch better❤
One question, if I had multiple nodes of the same component class under a single node (ie. multiple damage modifiers applied to a weapon), I assume I would have to handle the meta differently? (Maybe using an array/dict for the value, instead of the node itself?)
Love it, been getting into component based programming recently. I would love to see a full tutorial series for that game you showed using components and how to balance composition vs inheritance Thanks!
It is worth noting that ECS isn't just the use of modular components. It also focuses on separating the data (the components) from the logic (systems), which your system does not do. Also, other people have mentioned this, but your annoyance is with deep inheritance, not OOP. Godot _is_ object oriented, which makes it all the more annoying that GDScript is missing some very important object-oriented features, like generics and interfaces
WOW I've just come up to the same way of implementation for my game 24 H ago. And I've received the video in youtube recommendation which describes the same topic, which was posted 21 H ago. TH-cam recommendation algorithms are scary.... Thank you =)
what is the difference between using node paths and setting the metadata? isn't it basically the same thing to do %Interactible with a unique node name and get_meta(&"InteractibleComponent") ?
The & symbol is used to denote that the string "InteractableComponent" is a StringName instead of a regular String. It's a shorthand for: StringName("InteractableComponent") What are StringNames? StringNames are like Strings but way faster and less flexible, which makes them good for stuff like IDs. Unlike Strings, two StringNames with the same value are -- to the engine -- the same object. For example, when you compare 2 Strings, you'd normally have to go character by character and check if they're the same. Well, since 2 StringNames with the same value are the same object, the engine can just check if the memory location are the same. This makes comparing them really fast (especially for long strings)! The downside is that it's slower to mutate (e.g. join 2 StringNames or add characters) because Godot has to create a new String first.
has_meta returns nothing for me. a have a meta data on an object by default with the name "Type" and value(string) "Block". when checking node.has_meta("Type") it returns false. why?
I didn't get the description "GDScript is object oriented, but we have such a powerful tool (nodes)[...]". Components and Inheritance are not opposite approaches, on the very contrary, they are complementary approaches. We use inheritance all the time in Godot to extend component's behaviors, for instance.
I use this for different enemy behavior systems. It's especially useful when your components are not just node classes but scenes, i.e. collections of nodes. I don't quite see the need in the step with the meta data though. I'd build it in a way where the entity never needs to be aware of its components. it's fine for the component to use the owner reference to take care of everything that pertains to the component.
Clearly spoken and well explained! Loved the pixel art diagrams, gives me ideas for my own videos too! Overall really well edited video that's concise and to the point! Looking forward to more from you!
for an ECS, you probably want a dictionary of named strings, where each character in the string represents a component. then you can spawn those in by parsing the string, and adding the component trait data to various global arrays, that are used in systems that update specific traits in those components. Each spawned in component, would get a unique ID, and that is the index location the traits are stored in the arrays. The global arrays group similar traits for faster processing, which is efficient for large simulations because it reduces branching code.
I'm a bit confused like why should we use the node to store script???? Why don't we just implement some customs Resource and used it as component for the main node??? Is it's to avoid having too the env var to keep the Resource??? But that still doesn't make sense caz we can just have the ArrayOf as an component for the Entity. I think I don't understand the fundamental different between two approach. Can you explain me a bit further??
Good point! You could also do that. The main difference between the two approaches is that Node-based components can *directly* interact with the scene tree, while Resource-based ones can't. For example, in the Resource based approach, you'd have to always keep a reference to the parent node (the Node that has the component) or the scene tree if you want to interact with them. Compare that to Nodes where you just have methods like `get_tree()`, `get_node()`, `create_tween()`, `_process()`, etc.. right at your fingertips when you need them. The other advantage of using Nodes is that you can easily add, configure them in the editor. For example, you could have a component which extends `Node2D` or `Label`. Then, you could position them as you wish in the editor! E.g. changing the position of the `Node2D`, or setting the text on the `Label` But yeah, you could totally just have something like `@export var components: Array[Component]` if that's more convenient for you I hope this helps!
Im new so sorry if this is a super simple question. If you did make your game like this using nodes that have blocks of code in them and using them to mod other nodes, would you have to make sure that all the nodes you do that with are autoloaded?
No, you don't. That's the nice part: there's no autoloading! You just add the component nodes as direct children of whatever node you want to affect (aka "mod"). It's similar to how some nodes work in Godot out of the box! For example, to add collision to an Area2D, you just give it a CollisionShape2D node. Or how PathFollow2D nodes work as children of Path2D nodes. I hope this helps :)
@@tienne_k Yeah this helps. It makes sense. I think I was getting confused because I was using something similar to handle audio by making a node and basically putting all the sound in there in a key and then calling, or whatever, that node and the specific sound from the key that I needed, but because I am doing it like that it needs to be autoloaded but I assume that because you are actually attaching the node you create as a child to each thing you use then you dont need it to be autoloaded. Very neat stuff, gonna give it a go in a bit and see what I can do with it, thanks for the video!
One thing that people get consistently wrong is that OOP is not about inheritance. Inheritance is just a tool to save duplicating code (and a crappy crutch to achieve limited form of polymorphism). The structure of OOP is really just the one of encapsulated organs talking to each other by emitting signals (and it's obvious that a different organ can react differently to the same signal, so the idea of polymophism becomes self-explanatory and general). Just don't use inheritance if it prevents you to achieve that goal. Modular Components is also a perfectly valid way to achieve that. Hope it helps :)
Great video. Hilariously, as a low-level programmer with only moderate knowledge/experience in programming, I figured this out intuitively when I learned Godot and it makes so much sense to me. It's the best of both ECS and OOP and it should be embraced more, absolutely. There's a lot of little tricks I see rarely talked about, in general, that makes certain aspects of ECS and OOP creation easier to manage and create.
Ohhhh, registering in the parent's metadata. That's clever. I just started using metadata in Marker2Ds to provide NPC tasks with an animation_name which the NPC consumes and plays at the task. I think metadata doesn't get nearly enough attention. Nice use of it here!
Hey, just found your channel and really found this advice quite useful. I have used these techniques once or twice, but never really knew when to use it, since my purposes were rather niche. However, the way you explained really is eye opening on how this method is distinct in its purpose from inheritances and such. Also quick question: Are your songs free to use in personal or commercial projects? Music is an area I am limited in, and I absolutely love the vibes of the songs on your channel!
so like... why not just check when the player collides with something and it is in group pushable, push it? is the idea here... to simply add extendability? for example objects can push other ones etc...
Really enjoyed the video! How would you make custom interaction code per object? Switch and Tree are both interactable - how can you make it so Switch opens door and Tree gives you Apple for instance? I relied on interfaces in unity/c# fir this before
godot really makes me feel like I was spoiled by interfaces in C# and Java. I'd implement default functions in an interface and use it for pseudo multi inheritance.
I've been using a system for my PVZ inspired game where there is a giant "Machine" (Like plants in PVZ) script that has an array called "Properties". Depending on the properties listed in the array, the script has certain behaviors. But as you mentioned in the video, this means that all machines have a lot of wasted code and I didn't really think about this. On the other hand, Machines can any number of properties. So I'm wondering, is listing them all as nodes attached to the game object more or less convenient then just having a shared machine script with individual "if properties.has(*specific property*)" conditions??
Thanks. I was going nuts making a sword in my game about guns. Sword needed the methods used by weapons, but also damage methods used by bullets. "Sword is a bullet that can be fired" was how I got it working for a while. I changed it so that there's a "damage component" which contains all the methods for damage. However, now every single bullet needs a "damage component" since this isnt part of the base logic. Is there any way to improve this?
0:55 i don't understand this argument, the whole point of OOP is to not have to rewrite the same code for every object, you just inherit from the base object. The objects don't "own" the code, they don't get bigger in size because of code that they don't use. There is nothing wrong with having unused code, Being able to do the thing but not actually doing the thing. Also one argument from me in favor in OOP: override - with components you can't really have an object that works 99% like the others, but has small deviation. You would have to code specific condition for this one object in the component code or create identical component with slightly different behavior in that 1%. But with OOP you just override that one function from base object that differs from the other objects. I guess you could make new component and inherit from the base one, then override, but if you need this only once, per specific object, it might be tedious
Please is there a tutorial to learn how to make this kind of grid based movement? I swear this thing is so weird to make in Godot, I never understood it.
Seems like it should be simple: On input move the character object a fixed distance, then as long as each player object is placed inside a grid square initially it should never deviate so long as everything else that moves it -like pushback from getting hit- also only moves it that same amount in whatever direction it's supposed to.
That is amazing and I’ll totally be implementing that! But I do have a question, how could this solve the fire + life-steal bullet problem? If a fire bullet has one animation for the bullet, and the life-steal has another animation, then how do you make a combination of animations? If components are completely independent of each other, they can’t have their own “fire + life-steal” animation, right?
I'm probably wrong, but wouldn't you use an animation tree to set up custom animations for each situation? Unless you mean just spawning multiple different particles in the same place, which you should be able to do through code.
Hmm, this type of problem in understanding game engines is why I learned to code with no engine. I'm happy to see that modern game engines are allowing those interactions. It's too late for me to join in, but at least others can have an easier time going into game dev.
To the Softwaredevelopers: i am a Java Developer since 2009, developed with Angular and C# too. So OOP has been a part of half of my life. Is this Component-Style just for people who came over to gamedevelopment without knowing other Languages and OOP is "too complex to understand"? Or do you think, the ComponentSystem is a good way also for people who Objectify everything since 15 years?
I believe that every design has its own advantages and disadvantages. What we need to do is choose the one that suits us better, rather than choosing it just because of a specific advantage
-- DEMO PROJECT --
Many people have been asking for a demo project. Here it is!
👉github.com/WhoStoleMyCoffee/ComponentsDemo
2:50 CORRECTION:
The subtitle made it seem like Bevy was outdated or something.
What I meant was that "Bevy is the 2nd most popular game engine on Github" might be outdated.
I hope this helps you on your journey :)
Thank you
I think you are mixing up two terms. Composition over inheritance and Entity Component System.
Or ECS falls under composition umbrella, so he skipped right to it.
Agree. It does seem like there's a small confusion there, just from how he puts emphasis on Entity Component-systems, as opposed to Entity Component System, which has three strict parts and is about separating the data from the behavior, but a well put together video regardless.
@@quickgaming2466 But there literally is no ECS in Godot. There is even a page on the Godot website that explains why they opted not to use ECS
"The problem with OOP"
you listed problems with deep inheritance, which is not a necessary part of OOP. This is not the '90s anymore, components and interfaces have been the standard for OOP for a long time. "Composition over Inheritance" (which is the concept you described here) was mentioned in the book "Design Patterns: Elements of Reusable Object-Oriented Software" back in 1994. As you can tell from the title of the book, composition/components are a technique of OOP.
"ECSs"
You're not describing ECS, you're just describing components. You're using OOP with components, this is not ECS. Unity functions in the exact same way with built-in components as part of the engine, and it is OOP.
ECS is mainly about optimizing the update loop so that similar things are grouped together which reduces CPU cache misses.
A common misconception is that ECS is just "a system with entities and components" but an Entity, a Component and a System are three separate things which have specific uses within the paradigm of ECS. You can do regular OOP with entities and components.
One talk I would recommend is "Bob Nystrom - Is There More to Game Architecture than ECS?" which discusses the misunderstanding of what ECS is and how to instead implement well structured OOP architecture.
You can also look up "Game Programming Patterns" by Bob Nystrom which is free online and explains a bunch of different programming patterns which you can use to solve issues with game architecture.
Ahaha i was just gonna write about this, i love OOP and one of my pet peeves is when people look down on OOP just because of deep inheritnace, which is not even a problem anymore as literally every material on OOP says use composition on a "Has a" relationship and use inheritance on a "Is A" relationships.
Example - A car "has a" wheel(s) vs a car "is a" vehicle. A car here would inherit from a vehicle class, but be composed of wheels
I was gonna say how I would have pushable be a child of the gridobject script, and interactable be its own script, and attach both. But this is way more fleshed out.
Aye. As soon as the video mentioned "let's have everything inherit GridObject", I already knew this was just going to be the age-old composition vs. inheritance discussion again.
It's good for people getting started with _learning programming_ in general, but it's not something specific to _learning Godot._
Was going to say the same thing. Starting the video I was just thinking "I learn this back in 1996 when I first started dabbling in C++!. Surely this can't be a new thing again. And don't call me Shirley!"
Doesn't change the fact that OOP is just a bad concept which works great in simple examples but falls miserable and creates unmaintanable mess with anything even remotely complex.
The old as world "composition over inheritance"
The thing about this approach that everyone keeps talking about, is that if you want to make a DataType (ie: an enemy, boss, item, etc) that's slightly more complex than the rest, you'd have to make another node with another new script to implement that functionality... And then later on add another one for that particular functionality of that particular DataType, and so on until you have a bunch enemy nodes on screen with 10 component nodes each with it's separate instances of those scripts (and in Gdscript at that, which is not optimized for this) during runtime. To hammer it in more clearly, this is a very CPU-taxing way of implement common and unique functionality. What I usually do if you're wondering, is just make a C# script for every DataType I want to add to my game (usually enemies or items), and make them inherit some interfaces for common functionality. Then if I want to add unique functionality to that particular DataType, I just have to change the script attached to it instead of adding another script.
With this setup instead of having thousands nodes with tens of thousands of script instances, you get a few dozens nodes with more-or-less the same amount of script instances.
Good video though, just saying this cuz I keep seeing people w this exact same setup and complaining it runs poorly
In other words: good for small games, not for big.
True there is a big difference in how this scales
@@ClockworkGearhead It's not about the size, but about the functionality. If you're making a game where lots of functionality needs to be interchanged regularly, then modular design is great. But if you're just making a platformer or something, it's very over-engineered and a waste of time.
Wouldn't mind a video about this
@@NihongoWakannai So pretty much what I said. Large games, in practice, rarely have lots of interchangeable functionality.
1:54 - "Object oriented programming would tell you that's not possible". Stopped watching here. I don't understand why people feel the need to speak dishonestly when they could just get to the point they want to make. Setting up a bad object hierarchy and then blaming object oriented programming for allowing you to write bad code is a strange strawman to use here. It's like if I wrote positive integer addition recursively in lisp and then blamed functional programming as a whole for being slow.
Could have a dedicated node to keep the functionality nodes in and skip the metadata.
Instead of using child nodes, you could create instances of the component classes on the parent class in-code. This can simplify the tree structure so it isn't cluttered visually.
Perhaps you could have one single EntityComponentSystem class that all classes inherit from, and which includes the logic for attaching child components to new parent classes using factories, and also invokes the frame-by-frame processing logic for each of the child components so that each child component is guaranteed to be invoked during regular processing or some other events.
I wouldn't invent a whole new system if the engine's built-in works just fine. Less maintenance fee and kinda the whole point of using an engine.
I agree child nodes isn't a requirement in a way, but it's just a clutter of tree vs inspector if you need exported variables. Could also group all the script components in a single node and hide it away.
I've heard about components before but this has been easily the best intro yet. Good job
This is very helpful!
I have to say -- I really love the presentation in this video. I've recently been very interested in storytelling in things like teaching/marketing, etc., and this is one of the best examples of practical storytelling I've seen in a programming video for some time, compared to the myriad "hey guys, here's how you do the thing" presentations. This was super engaging.
The flexibility of godot blew my mind when I swapped from Unity. I can use a component architecture while being more consistently to OOP. I started programming with C++ so OOP is just the way I think, but i recognize the benefits of a component system
Having the ability to just use a component base thought process on command when i find it convenient is amazing to me
I'm so happy to know that I've been using this method all along and it's one of the best!
Great video 🙌
Nice video! A baba is you type game was a great way to broach the topic. While I love the components over inheritance approach godot promotes, I do sometimes find myself wishing godot had other OOP features like generics and multiple inheritance.
thanks im obseesd with components so I really loved the part where you tell me I can use both idk why I get so fixated on a single approach when i learn about it lmao.
Good explanation. I always recommend people reading about inheritance vs composition.
You juse summarize everything which I did in a last few projects. Cool explanation but cool to know and learn more about all of this.
This is cool, I’ve seen this used in the openxr addon for godot, I will definitely try implementing this in my game.
Excellent video, thank you for your neatly edited explanation. I've had this issue for quite some time and thansk to your video I will now use more composition than I did before
Great video! This method seems to be the most logical way to remove dependencies in godot. I wish there was a tutorial on using Metadata for this use case.
I had no idea such a thing existed.
I've read an article about composition recently and I've gotta say they didn't explain it as well as you do. It made me more confused as to why someone would create a bunch of vague classes that just gonna pollute the namespace. Good job!
you legend! I am such a beginner at godot and programming this is going to make my future projects way better
The usual manner to do things in OOP without deep inheritance for everything is using Mixins, basically taking the idea of the inheritance and making them into ingredients which you can mix together to get combined behavior in the class. (Godot doesn't inherently support Mixins out of the box, but emulating the behavior in Godot is not hard)
This is why I think in programming in general without double inheritance, when deciding what to inherit or compose you focus on what methods exist in both but differ including initializers but then you run into not all programming languages allowing initilizers to be inherited. Multi inheritance makes inheritance as a concept mutch more powerful.
Wow, simply explained with nice flow and content dense, straight to the point. THank you!
great video, even though I don't know how to use the game engine this way of thinking can be implemented to most projects without being limited to one game engine. Not to mention you explain everything well, Thanks!
I like your video, I agree with your ideas.
Somewhere I read the following thought: "imagine that you are improving the engine by adding your own nodes" - this influenced me, I began to write very simple primitive components, if you put them together, some kind of complex structure will work, it's quite fun.
I remember I started with Sprite3d, expanded it to FollowSprite3d, it showed where the RayCast3D node encountered a collision, you can add/remove this node at any time and it will not affect the work in any way, it is a pleasant experience.
After that, I made the interaction, it's just 2 nodes, a raycast and a receiver, 1 "connection" signal and a link to the object, that's all, it gave so much room for logic, while it remained at the level of the simplest node components.
How did I not know this yet? Thanks, this will help me a lot in future projects. Very well made video!
There's an unofficial extension for Godot called Godex which adds support for ECS as a subsystem. You'd have to compile the engine from the source though. All of this signifies that while Godot may imitate ECS, it cannot fully embody it. If you find yourself in this situation, consider switching to an engine that is built on ECS principles from the ground up. Doing so could save you from a lot of frustration.
I did something similar to this in my game where I have an enum that tells effects when they should happen in battle. These timings get applied when the effects are initialized. The function that gets passed into the constructor will execute when the listed time comes, so ONTURN will execute on turn and ONATTACK will execute when the entity attacks. I also paired this with ONWHOM which basically says which party it’s going to act on. It’s a neat little thing and I have yet to finish all the 11 different timings but I think it’s something that’s worth while, especially for differentiating between poison, burn, and bleed.
Algorithm just blessed me with this banger. Such good advice on structuring scenes and code, and so well presented. Just what I needed
Are you comfortable sharing the code so I can learn through it line by line? Thanks!
Thanks for the suggestion!
The code is now available here 👉github.com/WhoStoleMyCoffee/ComponentsDemo
Regardless of all the techy definitions crap, it's such an interesting approach!!
This is probably the best example of OOP vs ECS, amazing video
What about interfaces/traits? One object can inherit from many interfaces. So you can have like, partial class Box : Node2D, IPushable, IInteractable, and partial class Lever : Node2D, IInteractable
where IInteractable and IPushable are interfaces
GDScript doesn't have inherits only extends
@@ChristopherStormStrydom-Chris That is unfortunate, my knowledge comes from C# so I was expecting it to be persent there as well
@@K4rmy i mean you can still use it in godot as long as you use c# while programming
Awesome video! I love the little pixel art cards as you talk, it reminds me a bit of a guy from the TF2 community, Bing Soy. Subscribed
can you link the demo for this video? I'm interested in how you implemented the movement
The code is now available here 👉github.com/WhoStoleMyCoffee/ComponentsDemo
I hope this helps!
@@tienne_k thanks ❤
TLDR: "Composition over Inheritance"
1:06 what exactly makes the parameters/methods useless? I worked on a puzzle game where I used the technique you described; every puzzle item derived from the same type and I simply configured its settings differently to enable or disable different traits. One of the benefits of this approach is its ability to allow me to transform state really easily; when a wood block is disintegrated by a fire ball, I simply switch canPush to off. How would your system handle this? Would it not entail adding/removing components? Surely this would be more difficult to manage.
Using both is the correct option, like you said. The moment I learnt about ECS, I upgraded my pawns to use 2 simultaneous state machines. you can see the results you know where
great video mate, and clever design, keep it up!
I have been struggling to reasoning over exactly how to do something like this. Ie having a unit, which is either ranged, melee or a mix of them. This is a great option for adding those clasifications and adjusting their targeting based on it. Thanks!
great video GREAT music, informative, mic kinda sucked, really good humour, great visuals BRAVO !
I hope you will make more godot video. i like those :)
I never much thought about a use for the enter tree function before. Thanks!
I clicked on this video only because of the thumbnail. I started using this seemingly useless node while making my last game jam game by just adding a script to it and having it exist in the main scene tree. like for a sound manager or a score manager which I later found out that can be done by auto loads. then I started to add scripts to them in the way that you described first with out the metadata. I am no programmer and my code is worse than spaghetti but it is great to see that I was on the right track. GREAT video! very well explained Please keep doing what you are doing .
when this clicked for me it really made my dev so much easier, especially since you can reuse those components, that you for sharing the meta trick, I was always using get node, but using that is muuch better❤
I've been using components like this for over a year and I NEVER knew you could use meta data to keep track of them like this. GENIUS!
One question, if I had multiple nodes of the same component class under a single node (ie. multiple damage modifiers applied to a weapon), I assume I would have to handle the meta differently? (Maybe using an array/dict for the value, instead of the node itself?)
Yeah, I suppose.
I mean ideally, you wouldn't have multiple of one component node under the same parent...
very useful video and perfectly presented, thank you very much!
Ah thank you, I was wondering how to do that kind of connection.
This was a big reason why I haven't switched to Godot yet.
Love it, been getting into component based programming recently.
I would love to see a full tutorial series for that game you showed using components and how to balance composition vs inheritance Thanks!
It is worth noting that ECS isn't just the use of modular components. It also focuses on separating the data (the components) from the logic (systems), which your system does not do.
Also, other people have mentioned this, but your annoyance is with deep inheritance, not OOP. Godot _is_ object oriented, which makes it all the more annoying that GDScript is missing some very important object-oriented features, like generics and interfaces
WOW I've just come up to the same way of implementation for my game 24 H ago. And I've received the video in youtube recommendation which describes the same topic, which was posted 21 H ago.
TH-cam recommendation algorithms are scary....
Thank you =)
I'm very new to Godot, and still a novice when it comes to programming. This was genuinely so helpful
The ECS vs OOP gun example is a bit off IMO because the characteristics you mention are part of the bullet and not the gun which fires it.
I get what you mean, but this can easily change. E.g. if you use hitscan where there are no literal bullet objects flying around
Every single thing this dude says is very far off, it’s like he learned to program with RPG Maker lol
@@andre.drezus yeah, I'm learning to take this video with a grain of salt, but the core idea has been eye-opening nonetheless.
what is the difference between using node paths and setting the metadata? isn't it basically the same thing to do %Interactible with a unique node name and get_meta(&"InteractibleComponent") ?
Love the meta data idea to register components, that feels so clean.
You are not using godot to its full potential.
I mean... you dont need to call me out or anything lol.
what does the & symbol mean in the context of owner.set_meta(&"InteractableComponent', self)
The & symbol is used to denote that the string "InteractableComponent" is a StringName instead of a regular String.
It's a shorthand for: StringName("InteractableComponent")
What are StringNames?
StringNames are like Strings but way faster and less flexible, which makes them good for stuff like IDs.
Unlike Strings, two StringNames with the same value are -- to the engine -- the same object.
For example, when you compare 2 Strings, you'd normally have to go character by character and check if they're the same.
Well, since 2 StringNames with the same value are the same object, the engine can just check if the memory location are the same. This makes comparing them really fast (especially for long strings)!
The downside is that it's slower to mutate (e.g. join 2 StringNames or add characters) because Godot has to create a new String first.
@@tienne_k thank you
has_meta returns nothing for me. a have a meta data on an object by default with the name "Type" and value(string) "Block". when checking node.has_meta("Type") it returns false. why?
used get_meta("Type") != null in the end. still dont get why has_meta didnt return true
Very interesting and clever approach!
I didn't get the description "GDScript is object oriented, but we have such a powerful tool (nodes)[...]". Components and Inheritance are not opposite approaches, on the very contrary, they are complementary approaches. We use inheritance all the time in Godot to extend component's behaviors, for instance.
I use this for different enemy behavior systems.
It's especially useful when your components are not just node classes but scenes, i.e. collections of nodes.
I don't quite see the need in the step with the meta data though.
I'd build it in a way where the entity never needs to be aware of its components.
it's fine for the component to use the owner reference to take care of everything that pertains to the component.
Clearly spoken and well explained! Loved the pixel art diagrams, gives me ideas for my own videos too! Overall really well edited video that's concise and to the point! Looking forward to more from you!
for an ECS, you probably want a dictionary of named strings, where each character in the string represents a component. then you can spawn those in by parsing the string, and adding the component trait data to various global arrays, that are used in systems that update specific traits in those components. Each spawned in component, would get a unique ID, and that is the index location the traits are stored in the arrays. The global arrays group similar traits for faster processing, which is efficient for large simulations because it reduces branching code.
This is an excellent video! Thank you!
Hmm, so from what i understood, roblox studio is also ECS and OOP?
Hey, set_meta(&"myCmpt, self)
What does this & do in params above ? never seen '&' being used like this
I'm a bit confused like why should we use the node to store script????
Why don't we just implement some customs Resource and used it as component for the main node???
Is it's to avoid having too the env var to keep the Resource???
But that still doesn't make sense caz we can just have the ArrayOf as an component for the Entity.
I think I don't understand the fundamental different between two approach. Can you explain me a bit further??
Good point! You could also do that.
The main difference between the two approaches is that Node-based components can *directly* interact with the scene tree, while Resource-based ones can't.
For example, in the Resource based approach, you'd have to always keep a reference to the parent node (the Node that has the component) or the scene tree if you want to interact with them.
Compare that to Nodes where you just have methods like `get_tree()`, `get_node()`, `create_tween()`, `_process()`, etc.. right at your fingertips when you need them.
The other advantage of using Nodes is that you can easily add, configure them in the editor.
For example, you could have a component which extends `Node2D` or `Label`. Then, you could position them as you wish in the editor! E.g. changing the position of the `Node2D`, or setting the text on the `Label`
But yeah, you could totally just have something like `@export var components: Array[Component]` if that's more convenient for you
I hope this helps!
Inheritance for general features that majority of objects have, ecs for specific cases
Im new so sorry if this is a super simple question. If you did make your game like this using nodes that have blocks of code in them and using them to mod other nodes, would you have to make sure that all the nodes you do that with are autoloaded?
No, you don't.
That's the nice part: there's no autoloading! You just add the component nodes as direct children of whatever node you want to affect (aka "mod").
It's similar to how some nodes work in Godot out of the box!
For example, to add collision to an Area2D, you just give it a CollisionShape2D node. Or how PathFollow2D nodes work as children of Path2D nodes.
I hope this helps :)
@@tienne_k Yeah this helps. It makes sense. I think I was getting confused because I was using something similar to handle audio by making a node and basically putting all the sound in there in a key and then calling, or whatever, that node and the specific sound from the key that I needed, but because I am doing it like that it needs to be autoloaded but I assume that because you are actually attaching the node you create as a child to each thing you use then you dont need it to be autoloaded.
Very neat stuff, gonna give it a go in a bit and see what I can do with it, thanks for the video!
One thing that people get consistently wrong is that OOP is not about inheritance. Inheritance is just a tool to save duplicating code (and a crappy crutch to achieve limited form of polymorphism). The structure of OOP is really just the one of encapsulated organs talking to each other by emitting signals (and it's obvious that a different organ can react differently to the same signal, so the idea of polymophism becomes self-explanatory and general). Just don't use inheritance if it prevents you to achieve that goal. Modular Components is also a perfectly valid way to achieve that. Hope it helps :)
eye opening video, thank you so much
dang, I always forget about metadata in Godot - this is a great use-case for it!
Great video. Hilariously, as a low-level programmer with only moderate knowledge/experience in programming, I figured this out intuitively when I learned Godot and it makes so much sense to me.
It's the best of both ECS and OOP and it should be embraced more, absolutely. There's a lot of little tricks I see rarely talked about, in general, that makes certain aspects of ECS and OOP creation easier to manage and create.
Ohhhh, registering in the parent's metadata. That's clever. I just started using metadata in Marker2Ds to provide NPC tasks with an animation_name which the NPC consumes and plays at the task. I think metadata doesn't get nearly enough attention. Nice use of it here!
Honestly this is an amazing system. I can imagine a good few systems that could use this in my game.
this is actually informative! thanks!
Ah so this video tells me to use Godot like Unity. As a previously (not formerly) Unity user, I immediately did this on Godot. Works like a charm.
where are this guys 4,000 subscribers
Oh boy cant wait to completely rework my weapons for the third time!
Hey, just found your channel and really found this advice quite useful. I have used these techniques once or twice, but never really knew when to use it, since my purposes were rather niche. However, the way you explained really is eye opening on how this method is distinct in its purpose from inheritances and such.
Also quick question: Are your songs free to use in personal or commercial projects? Music is an area I am limited in, and I absolutely love the vibes of the songs on your channel!
Thank you so much for the feedback!!
Yes, my songs are free to use in both personal and commercial projects. Just be sure to credit me :)
so like... why not just check when the player collides with something and it is in group pushable, push it? is the idea here... to simply add extendability? for example objects can push other ones etc...
Think about it.
Objects are just fancy structs.
Use objects as data, not rules.
Really helped me clean up my code, thanks boss
Really enjoyed the video! How would you make custom interaction code per object? Switch and Tree are both interactable - how can you make it so Switch opens door and Tree gives you Apple for instance? I relied on interfaces in unity/c# fir this before
This is where Systems come in.
This video deserves more views. YT algo do your thing.
godot really makes me feel like I was spoiled by interfaces in C# and Java. I'd implement default functions in an interface and use it for pseudo multi inheritance.
I've been using a system for my PVZ inspired game where there is a giant "Machine" (Like plants in PVZ) script that has an array called "Properties". Depending on the properties listed in the array, the script has certain behaviors. But as you mentioned in the video, this means that all machines have a lot of wasted code and I didn't really think about this. On the other hand, Machines can any number of properties. So I'm wondering, is listing them all as nodes attached to the game object more or less convenient then just having a shared machine script with individual "if properties.has(*specific property*)" conditions??
Cool, I used this sometimes unknowingly it's an actual game dev pattern
ok you just solved my question on how do i easily import stuff in my thingies to make them modular. never thought placing them as child can be that.
Thanks. I was going nuts making a sword in my game about guns. Sword needed the methods used by weapons, but also damage methods used by bullets. "Sword is a bullet that can be fired" was how I got it working for a while. I changed it so that there's a "damage component" which contains all the methods for damage. However, now every single bullet needs a "damage component" since this isnt part of the base logic. Is there any way to improve this?
Lazy gamedev: Just fire a big invisible non-moving bullet from your sword.
0:55 i don't understand this argument, the whole point of OOP is to not have to rewrite the same code for every object, you just inherit from the base object. The objects don't "own" the code, they don't get bigger in size because of code that they don't use. There is nothing wrong with having unused code, Being able to do the thing but not actually doing the thing.
Also one argument from me in favor in OOP: override - with components you can't really have an object that works 99% like the others, but has small deviation. You would have to code specific condition for this one object in the component code or create identical component with slightly different behavior in that 1%. But with OOP you just override that one function from base object that differs from the other objects.
I guess you could make new component and inherit from the base one, then override, but if you need this only once, per specific object, it might be tedious
Please is there a tutorial to learn how to make this kind of grid based movement? I swear this thing is so weird to make in Godot, I never understood it.
Seems like it should be simple: On input move the character object a fixed distance, then as long as each player object is placed inside a grid square initially it should never deviate so long as everything else that moves it -like pushback from getting hit- also only moves it that same amount in whatever direction it's supposed to.
That is amazing and I’ll totally be implementing that! But I do have a question, how could this solve the fire + life-steal bullet problem? If a fire bullet has one animation for the bullet, and the life-steal has another animation, then how do you make a combination of animations? If components are completely independent of each other, they can’t have their own “fire + life-steal” animation, right?
I'm probably wrong, but wouldn't you use an animation tree to set up custom animations for each situation?
Unless you mean just spawning multiple different particles in the same place, which you should be able to do through code.
You had the pronunciation of Godot right the first time! (God-oh)
Oh thank God (-oh)!
Hmm, this type of problem in understanding game engines is why I learned to code with no engine.
I'm happy to see that modern game engines are allowing those interactions.
It's too late for me to join in, but at least others can have an easier time going into game dev.
Woooaahh... I realized that in GameMaker Studio, ECS can be easily applied there.
To the Softwaredevelopers:
i am a Java Developer since 2009, developed with Angular and C# too.
So OOP has been a part of half of my life.
Is this Component-Style just for people who came over to gamedevelopment without knowing other Languages and OOP is "too complex to understand"?
Or do you think, the ComponentSystem is a good way also for people who Objectify everything since 15 years?
I believe that every design has its own advantages and disadvantages. What we need to do is choose the one that suits us better, rather than choosing it just because of a specific advantage
Very nice! Thanks for sharing