-- 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 :)
"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.
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.
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.
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.
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 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.
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.
Yeah, I feel like there are a lot of people in the game development space with very little actual knowledge of architecture. People read simplified explanations, use them for a bit and then make their own simplified and often wrong explanations. Inheritance vs composition is a design consideration within OOP; it's not two different things. The whole thing is starting to reek of infomercials, with inheritance being demonstrated as gracefully as trying to hammer a nail while making 7 holes the wall. ECS is simply a specific approach to data driven design which is also completely compatible with OOP. And yes, nothing in this video was ECS. As far as I know Godot doesn't even use ECS for its node system; only in its underlying implementation of the physics engine etc.
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.
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!
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
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!
I'm absolutely in love with this video. I've been trying to make some Godot tutorials lately, but they're dry as a bone compared to this. Nice music, good visuals, very high level explanation. Really great stuff!
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.
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!
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.
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!
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.
This is the exact video I needed to pop up in my recommended, I knew I wanted to take advantage of the ECS stuff in godot but I wasn't exactly sure how. Short and to the point, well edited, I like the "gun mods" example. Good stuff, thanks.
just as a heads-up, this is not really ECS. This is "composition" (see discussions about inheritance vs composition). And ECS has a way more specific meaning and is not what Godot does.
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?)
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!
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.
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??
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
Yes, it would be very cool to have interfaces in Godot... What do you mean "that's not what this video is about"? But seriously, I find it much more intuitive and effective to use interfaces than stuffing the implementation into nodes.
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.
Could you upload a tutorial showing how that works? I'm very new to Godot, though I used Roblox Studio before and this sounds like how ModuleScripts work.
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.
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?
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!
Does Tienne_k not understand that the crate could inherit from GridObject, Pushable, AND Interactable? Fire bullets could easily be Bullet, and Flaming child classes. Am I missing something? I think the biggest problem with inheritance is not a limitation with the model, but just that sometimes developers have trouble understanding how simple it is. I'm not arguing against the methods we're talking about here. Just against OOP being a problem for these examples.
So, interface inheritance… But actually, this is pretty cool. I don’t use Godot, but the idea of components always felt limiting before this. So, thanks for the lesson.
No, because with interfaces you would need to rewrite the methods for each class. This way you don't have to, but it's tricky, as all your classes will share exactly the same behavior (in many cases not likely). It's something in between a composition and a multiple inheritance... kinda.
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
does anyone know where i can learn the godot coding language? I've been using it for years now but still not understand the basic knowledge of godot language lol
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.
I really hope to see more of your videos. This is one of the best explanations I have ever seen. Also love that it's explaning the architecture which not many tutorials explain architectures.
So This Teq you Mention... Its about Having a "Node" Doing One Job Really Well... Then Finding a way To Call that Action - Like in your Video, Using meta Data , Child/Parent Relationship - True/False Statements? (Don't know To be Honest) Once it gets Call - Automatically Knows what to do... this is the part where i get lost when People are Talking about it... And once you are Done Using it - you Free it... But What About Rules? Like Fire Cannot Combine With Water what do you do Then?... Just out of Curiosity...
i think you dangerously misunderstood OOP in this video, spreading this out would be a shame. What you described is not really a limitation to OOP at all , and you are not "solving "it by doing something outside of OOP . In this whole video, there isnt a single time where you talk about something that isnt OOP. The alternatives you mention, the spectrum, engines: all of them are plain old OOP . ECS is not an alternative to OOP, it just uses a DESIGN PATTERN within OOP, it is just a way of using OOP to solve problem, and people have been using it since forever. Like , the Composite Structural Pattern is included in the GOF for god's sake : en.wikipedia.org/wiki/Composite_pattern . This is basically the holy text of OOP, and its there since it was published, to say it is whole diffrerent new thing is sacrilegious , its like saying Jesus is the alternative to Christianism . ECS is not more flexible than OOP, in reality it owes its own existence only to OOP's flexibility , every praise you gave to it is not a downside to OOP, its a merit. As a matter of fact the Composite pattern is just one of the ways you can solve the "problem" you posed in the video, all of them are well-stablished ways to use OOP, to the point that this is not even considered a problem, what you called the OOP way of doing things is such a naive implementation it is considered an anti-pattern, and all the issues you mentioned arent considered a flaw with OOP but with the person implementing it .
The amount of methods and parameters in a object or not stored in memory, when you call a method on an object You're simply calling a reference to the method and then running an instance of that method of the method, suffice to say your object stores the method memory of all objects that are the same type they just store once so adding new objects they will inherit the same reference addresses to these methods and then when you call a method it's just running an instance of that method with whatever objects variables there isn't actually an overhead to putting in more methods into a script It just simply makes it to where your script can get unreadable
Too overcomplicated... Below, i used basic OOP Interfaces to exactly accomplish what was asked in the first place. No Godot needed. class Crate : IPushable, IInteractable { ... } class Stone : IPushable { ... } on_click = if object is IInteractable interactable_object { interactable_object.Interact(); } on_push = if object is IPushable pushable_object { pushable_object.Push(); }
This is a core problem and common knowledge. Also, the title “you’re not using Godot to its potential” while opening onto some pixel art grid of sprites made me chuckle. Turn down the clickbait please!
Keep it extensible for what? I'm not just going to make it extensible for anything. Design your game before you start coding it bro. Don't solve imaginary problems with your code
If you want to code your game rigid and non-extensible then go ahead, "bro". Many of us developers however like to be able to add cool new ideas without having to rewrite tons of code.
I'm sorry but you're clearly an inexperienced developer if you think that adding more abstraction to make things "extensible" means quicker development. I've been at this for a long enough time.to have gone through that phase (very early on , as with anyone else who went through that phase also went through it very early on)
@@kyoai hes right half the time you never extend anything and any modular code you can insert into future projects tends to never really quite fit anyway and you write something new again anyway.
@kyoai and also, I'd be willing to bet anyone who wants to add "cool new ideas" doesn't have a whole lot of finished games, if im wrong absolutely go ahead and post your portfolio, but im likely right. Seriously design your game BEFORE coding it. It'll make coding SO much easier
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.
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
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.
-- 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
"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.
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.
The old as world "composition over inheritance"
Could have a dedicated node to keep the functionality nodes in and skip the metadata.
I've heard about components before but this has been easily the best intro yet. Good job
I never much thought about a use for the enter tree function before. Thanks!
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.
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.
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 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.
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.
OOP doesn't imply inheritance. This isn't ECS either. I imagine the video took work but, you're contributing to confuse a lot of people
Yeah, I feel like there are a lot of people in the game development space with very little actual knowledge of architecture. People read simplified explanations, use them for a bit and then make their own simplified and often wrong explanations. Inheritance vs composition is a design consideration within OOP; it's not two different things. The whole thing is starting to reek of infomercials, with inheritance being demonstrated as gracefully as trying to hammer a nail while making 7 holes the wall.
ECS is simply a specific approach to data driven design which is also completely compatible with OOP. And yes, nothing in this video was ECS. As far as I know Godot doesn't even use ECS for its node system; only in its underlying implementation of the physics engine etc.
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.
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!
Hmm, so from what i understood, roblox studio is also ECS and OOP?
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
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!
I'm very new to Godot, and still a novice when it comes to programming. This was genuinely so helpful
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!
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.
I'm absolutely in love with this video. I've been trying to make some Godot tutorials lately, but they're dry as a bone compared to this. Nice music, good visuals, very high level explanation.
Really great stuff!
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.
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!
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.
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.
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!
How did I not know this yet? Thanks, this will help me a lot in future projects. Very well made video!
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
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.
great video GREAT music, informative, mic kinda sucked, really good humour, great visuals BRAVO !
Woooaahh... I realized that in GameMaker Studio, ECS can be easily applied there.
You had the pronunciation of Godot right the first time! (God-oh)
Oh thank God (-oh)!
Bevy, outdated? Wat???
My bad, I misworded that lol 😅
I meant that Bevy being "the 2nd most popular game engine on Github" might be outdated.
Thanks for pointing that out!!
@@tienne_kin a good way or bad way(is it the1st?, cuz idk how to check)
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.
This is the exact video I needed to pop up in my recommended, I knew I wanted to take advantage of the ECS stuff in godot but I wasn't exactly sure how. Short and to the point, well edited, I like the "gun mods" example. Good stuff, thanks.
just as a heads-up, this is not really ECS. This is "composition" (see discussions about inheritance vs composition). And ECS has a way more specific meaning and is not what Godot does.
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...
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!
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 ❤
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.
Cool, I used this sometimes unknowingly it's an actual game dev pattern
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??
Really helped me clean up my code, thanks boss
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
Yes, it would be very cool to have interfaces in Godot...
What do you mean "that's not what this video is about"?
But seriously, I find it much more intuitive and effective to use interfaces than stuffing the implementation into nodes.
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.
Could you upload a tutorial showing how that works? I'm very new to Godot, though I used Roblox Studio before and this sounds like how ModuleScripts work.
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.
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
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!
This is an excellent video! Thank you!
great video mate, and clever design, keep it up!
Does Tienne_k not understand that the crate could inherit from GridObject, Pushable, AND Interactable? Fire bullets could easily be Bullet, and Flaming child classes. Am I missing something? I think the biggest problem with inheritance is not a limitation with the model, but just that sometimes developers have trouble understanding how simple it is. I'm not arguing against the methods we're talking about here. Just against OOP being a problem for these examples.
Sounds like multiple inheritance?
Very interesting and clever approach!
So, interface inheritance…
But actually, this is pretty cool. I don’t use Godot, but the idea of components always felt limiting before this. So, thanks for the lesson.
No, because with interfaces you would need to rewrite the methods for each class. This way you don't have to, but it's tricky, as all your classes will share exactly the same behavior (in many cases not likely). It's something in between a composition and a multiple inheritance... kinda.
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
This helps a LOT
does anyone know where i can learn the godot coding language? I've been using it for years now but still not understand the basic knowledge of godot language lol
You are not using godot to its full potential.
I mean... you dont need to call me out or anything lol.
this is actually informative! thanks!
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
where are this guys 4,000 subscribers
what about entities and systems
I really hope to see more of your videos. This is one of the best explanations I have ever seen. Also love that it's explaning the architecture which not many tutorials explain architectures.
cool, thanks for sharing :)
Very nice! Thanks for sharing
Think about it.
Objects are just fancy structs.
Use objects as data, not rules.
OOOOOOOOOOOOOOH this is Mind Blowing 🤯
>full potential
>uses GDScript
5:45 nice meme, haha
This is akin to classes in Bootstrap or React.
So This Teq you Mention...
Its about Having a "Node" Doing One Job Really Well...
Then Finding a way To Call that Action - Like in your Video, Using meta Data , Child/Parent Relationship - True/False Statements? (Don't know To be Honest)
Once it gets Call - Automatically Knows what to do... this is the part where i get lost when People are Talking about it...
And once you are Done Using it - you Free it...
But What About Rules?
Like Fire Cannot Combine With Water
what do you do Then?... Just out of Curiosity...
i think you dangerously misunderstood OOP in this video, spreading this out would be a shame. What you described is not really a limitation to OOP at all , and you are not "solving "it by doing something outside of OOP . In this whole video, there isnt a single time where you talk about something that isnt OOP. The alternatives you mention, the spectrum, engines: all of them are plain old OOP .
ECS is not an alternative to OOP, it just uses a DESIGN PATTERN within OOP, it is just a way of using OOP to solve problem, and people have been using it since forever.
Like , the Composite Structural Pattern is included in the GOF for god's sake : en.wikipedia.org/wiki/Composite_pattern . This is basically the holy text of OOP, and its there since it was published, to say it is whole diffrerent new thing is sacrilegious , its like saying Jesus is the alternative to Christianism .
ECS is not more flexible than OOP, in reality it owes its own existence only to OOP's flexibility , every praise you gave to it is not a downside to OOP, its a merit. As a matter of fact the Composite pattern is just one of the ways you can solve the "problem" you posed in the video, all of them are well-stablished ways to use OOP, to the point that this is not even considered a problem, what you called the OOP way of doing things is such a naive implementation it is considered an anti-pattern, and all the issues you mentioned arent considered a flaw with OOP but with the person implementing it .
An "alternative" to OOP would be something like functional programming , the language you use to code shaders is not oop, see the difference?
First time I see use for metadata
The amount of methods and parameters in a object or not stored in memory, when you call a method on an object You're simply calling a reference to the method and then running an instance of that method of the method, suffice to say your object stores the method memory of all objects that are the same type they just store once so adding new objects they will inherit the same reference addresses to these methods and then when you call a method it's just running an instance of that method with whatever objects variables there isn't actually an overhead to putting in more methods into a script It just simply makes it to where your script can get unreadable
Thanks for sharing the code
Too overcomplicated... Below, i used basic OOP Interfaces to exactly accomplish what was asked in the first place. No Godot needed.
class Crate : IPushable, IInteractable { ... }
class Stone : IPushable { ... }
on_click = if object is IInteractable interactable_object {
interactable_object.Interact();
}
on_push = if object is IPushable pushable_object {
pushable_object.Push();
}
I know that. I'm too dumb to use it effectively.
i tried to make my player as component, then I encountered problem with player movements and clamping 😂
very good video
Modularity vs Granularity talk: th-cam.com/video/MlQ3640EIOE/w-d-xo.htmlsi=COtRn6VK7D5NTsl1
Finely-graduated, granular software: th-cam.com/video/yFZcfIfJUdg/w-d-xo.htmlsi=dhto7ZvaYkcTyWKL
Because this modularity thing has things to consider, and this video is missing a great bit of emphasis on the potential(esp. John Lakos' stuff)
What a cool video
I thought everyone used godot like that
Pushing 🚫⛔
Pussing ☑️☑️☑️
"Baba is Godot" ..? :)
It's pronounced Godot
solution if you wanna stick with OOP: use interfaces (i know gdscript doesn't have interfaces shut up)
I know that but is don’t know how to use godot
This is a core problem and common knowledge. Also, the title “you’re not using Godot to its potential” while opening onto some pixel art grid of sprites made me chuckle. Turn down the clickbait please!
You're right, I'm not using Godot
Love me some clickbait articles for a game engine...
Great video!
(but please pronounce it the way that drops the T, like "g'doh" or "go-doh")
The creator of Godot (Juan) pronounces it using the T.
When your average Godot user attempts to pass as knowledgeable on OOP and design principles 😂
I’m not using godot at all actually
Keep it extensible for what? I'm not just going to make it extensible for anything. Design your game before you start coding it bro. Don't solve imaginary problems with your code
If you want to code your game rigid and non-extensible then go ahead, "bro". Many of us developers however like to be able to add cool new ideas without having to rewrite tons of code.
I'm sorry but you're clearly an inexperienced developer if you think that adding more abstraction to make things "extensible" means quicker development. I've been at this for a long enough time.to have gone through that phase (very early on , as with anyone else who went through that phase also went through it very early on)
@@kyoai hes right half the time you never extend anything and any modular code you can insert into future projects tends to never really quite fit anyway and you write something new again anyway.
@kyoai and also, I'd be willing to bet anyone who wants to add "cool new ideas" doesn't have a whole lot of finished games, if im wrong absolutely go ahead and post your portfolio, but im likely right. Seriously design your game BEFORE coding it. It'll make coding SO much easier
I don't use Godot at all
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.
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
Good explanation. I always recommend people reading about inheritance vs composition.
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.