You're not using Godot to its potential
Вставка
- Опубліковано 7 чер 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
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.
"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"
Thanks man! This video is so well edited and easy to follow!
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!
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.
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
I've heard about components before but this has been easily the best intro yet. Good job
Could have a dedicated node to keep the functionality nodes in and skip the metadata.
Good explanation. I always recommend people reading about inheritance vs composition.
great video mate, and clever design, keep it up!
How did I not know this yet? Thanks, this will help me a lot in future projects. Very well made video!
Wow, simply explained with nice flow and content dense, straight to the point. THank you!
Love the meta data idea to register components, that feels so clean.
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 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!
Inheritance for general features that majority of objects have, ecs for specific cases
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.
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!
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.
Very interesting and clever approach!
this is actually informative! thanks!
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
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
TLDR: "Composition over Inheritance"
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❤
you legend! I am such a beginner at godot and programming this is going to make my future projects way better
very useful video and perfectly presented, thank you very much!
I'm very new to Godot, and still a novice when it comes to programming. This was genuinely so helpful
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 .
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!
Very nice! Thanks for sharing
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! 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.
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 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!
This is cool, I’ve seen this used in the openxr addon for godot, I will definitely try implementing this in my game.
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
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.
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!
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!
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.
Really helped me clean up my code, thanks boss
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 helps a LOT
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") ?
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.
dang, I always forget about metadata in Godot - this is a great use-case for it!
Thanks for sharing the code
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
Very nice video, thanks
This video deserves more views. YT algo do your thing.
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.
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.
Nice explanation
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
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??
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.
UA-cam recommendation algorithms are scary....
Thank you =)
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 :)
I hope you will make more godot video. i like those :)
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.
Honestly this is an amazing system. I can imagine a good few systems that could use this in my game.
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.
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.
Hmm, so from what i understood, roblox studio is also ECS and OOP?
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!
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.
great video GREAT music, informative, mic kinda sucked, really good humour, great visuals BRAVO !
nice video 👍
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.
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.
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.
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...
Regardless of all the techy definitions crap, it's such an interesting approach!!
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.
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.
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.
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.
Cool, I used this sometimes unknowingly it's an actual game dev pattern
OOOOOOOOOOOOOOH this is Mind Blowing 🤯
very good video
Woooaahh... I realized that in GameMaker Studio, ECS can be easily applied there.
Think about it.
Objects are just fancy structs.
Use objects as data, not rules.
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 ❤
Is functional programming have a place in game dev?
Good point you rise here!
Although as others said, this is not an OOP issue, but the @ss programming languages deficiency. This wouldn't happen if we had multiple inheritance like in C++. I've faced this issue a million times, and yes, you end up changing your design, or working around it.
What you show is really cool for some scenarios. BUT, your classes need to adapt to the common functionality and the executed code will be exactly the same for all of them (so you'll need a very good design if you want variations).
Regarding some cases you showed, there may be ways of achieving that with patterns such as decorator for example, but it's definitely a flaw of the programming languages that should have already been addressed. Your way in Godot is a very good option!
5:45 nice meme, haha
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.
Nice, im new ro godot, but im pretty sure now in godot 4, you can extend the script, so you can add multiple scripts to one object.
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)
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!
What a cool video
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
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
where are this guys 4,000 subscribers
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.