Awesome, glad I could help!

I can confirm. This would be undoubtedly awesome. Very necessary.

We do. We crave it!

I'll add that idea to the list! :)

Use inheritance only when composition is logically impossible. In all other cases prefer composition. And don't inherit deeper than two levels.

So for the enemies, I'd definitely create an Enemy class to handle all the common functions (like ai, movement, etc.) You could then export properties for things like a Health Component, Stats Component, etc. (all different classes), and these could handle the more composition-oriented logic. Hope this helps!

Planning on extending this video with a custom resource attack system:)

Every instance of a class will have the same properties, so to give a class a "unique" property, you either need to inherit the base class (and add new properties), or add metadata

No there’s a multitude of uses for classes, not having to rewrite code is the biggest. If I have ten enemies they can all have the same health. Why create ten scenes with the same script lines written. When code can be reduced it should be. Example, you have a script where you want enemies to spawn every time an enemy dies - you can use a class with a condition statement stating if enemy_dies(): PathSpawn Then no matter the enemy type that died when you kill one it respawns. Then you didn’t have to write the spawn script on ten enemy types. If you plan on having no variety or spaghetti code sure you can ignore classes. If you want to speed up production, have cleaner, more efficient code then use classes.

@@H3_remix I have no idea what do you mean by reduced code? How do classes reduce code if it's just another script you instance? Its literally just a script saved as .tscn....same thing as writing a script and attaching it where you need it

@@Ceisri you’re missing the fundamental point of classes. If you have ten enemies and they all have 100 health, why would you need to write ten scripts for their health, movement or spawn position. You’re writing much less code because instead od creating ten variables in ten scripts you have one script with one variable. Health. You could then extrapolate it further and add their movement. You can then have their specific mechanics only in their script, but because they’ve inherited the enemy class they don’t need the health variable in each one. Thus you’ve reduced your lines by a minimum of ten in this example. Because your enemy class already has a health variable, or spawn variable set you can write it once and then set each enemy to be a part of the class. I’m not sure where we have lost each other here. The difference being classes are declarative while nodes and scenes are imperative. Declarative meaning it doesn’t need to define its control flow. Imperative meaning it’s described step by step in detail. Are scripts/scenes similar to classes, yes, but they are not the same. As dor the node with a script attached you’ve created an imperative code. Rather than being declarative as in classes. There is extensive documentation on the godot site about classes and how they function if you have further confusion.

​@@H3_remixI think what he's asking is why would you use classes instead of just instancing the scene/code you've already written.

@@H3_remix Multiple instances of the enemy.tscn scene will share the same code file. Then if we export the health variable it can be made unique for each enemy directly in the editor. No need for classes or additional lines of code. @Queble this is a great tutorial, but I personally would really enjoy some more real-world examples of how classes are better than just instancing scenes!