You're not using Godot to its potential
Vložit
- čas přidán 5. 08. 2024
- In this video, I talk about making component-like structures in Godot, which I feel is often overlooked.
Yes, GDScript is object oriented, but we have such a powerful tool (nodes) at our hands, we might as well use it to its fullest!
Using nodes as components is so much more flexible than rigid OOP inheritance trees.
Of course, if you over-do it, you'll just be shooting yourself in the foot; ideally you'd want a healthy mixture of both. That's why Godot is so great!
Join our discord: / discord
Many people have been asking for a demo project. Here it is!
👉github.com/WhoStoleMyCoffee/C...
Btw, the plugin you see me use is a fork of Godot-Vim. Still a work in progress tho.
👉 github.com/bernardo-bruning/g...
Music 🎵 ――――――――――――――――
- Los Encinos by Quincas Moreira
- Bossa Sonsa, also by Quincas Moreira
Timestamps ⏰ ――――――――――――――――
0:00 Demo
0:20 The problem with OOP
1:30 FPS analogy
2:08 ECSs
3:10 Godot as an ECS??
4:40 Handling components
5:44 Conclusion
#godot #godotengine
-- 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"
I'm so happy to know that I've been using this method all along and it's one of the best!
Great video 🙌
I never much thought about a use for the enter tree function before. Thanks!
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
Could have a dedicated node to keep the functionality nodes in and skip the metadata.
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.
Good explanation. I always recommend people reading about inheritance vs composition.
I've heard about components before but this has been easily the best intro yet. Good job
How did I not know this yet? Thanks, this will help me a lot in future projects. Very well made video!
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.
Wow, simply explained with nice flow and content dense, straight to the point. THank you!
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!
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!
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.
Love the meta data idea to register components, that feels so clean.
great video mate, and clever design, keep it up!
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 an excellent video! Thank you!
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??
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") ?
Hey, set_meta(&"myCmpt, self)
What does this & do in params above ? never seen '&' being used like this
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❤
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.
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
this is actually informative! 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 .
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
very useful video and perfectly presented, thank you very much!
Very interesting and clever approach!
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.
This is cool, I’ve seen this used in the openxr addon for godot, I will definitely try implementing this in my game.
I'm very new to Godot, and still a novice when it comes to programming. This was genuinely so helpful
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
Really helped me clean up my code, thanks boss
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...
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.
Very nice! Thanks for sharing
Hmm, so from what i understood, roblox studio is also ECS and OOP?
Thanks man! This video is so well edited and easy to follow!
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!
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.
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!
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 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.
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!
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.
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 :)
TLDR: "Composition over Inheritance"
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)
Is functional programming have a place in game dev?
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.
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!
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
This helps a LOT
Very nice video, thanks
Algorithm just blessed me with this banger. Such good advice on structuring scenes and code, and so well presented. Just what I needed
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!
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!
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
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.
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.
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 ❤
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.
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
I hope you will make more godot video. i like those :)
Honestly this is an amazing system. I can imagine a good few systems that could use this in my game.
Inheritance for general features that majority of objects have, ecs for specific cases
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.
why just font use has_method() ?
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.
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
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.
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.
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
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!
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.
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
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.
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.
CZcams recommendation algorithms are scary....
Thank you =)
Thanks for sharing the code
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?
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.
OOOOOOOOOOOOOOH this is Mind Blowing 🤯
Oh boy cant wait to completely rework my weapons for the third time!
Nice explanation
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.
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.
Regardless of all the techy definitions crap, it's such an interesting approach!!
great video GREAT music, informative, mic kinda sucked, really good humour, great visuals BRAVO !
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
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 :)
This video deserves more views. YT algo do your thing.
Cool, I used this sometimes unknowingly it's an actual game dev pattern
Modularity vs Granularity talk: czcams.com/video/MlQ3640EIOE/video.htmlsi=COtRn6VK7D5NTsl1
Finely-graduated, granular software: czcams.com/video/yFZcfIfJUdg/video.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 about entities and systems