ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- A quick video to show you how Godot's class_name can be used to create a custom class that makes it easier to add and change functionality in a game.
I'm technically using Godot 4/GDScript 2.0, but that should be irrelevant for this topic.
Sprout Lands by Cup Nooble:
cupnooble.itch.io/sprout-land...
Music used:
• The 25th Hour - Schlat...
It's been a minute, so please leave feedback on how I covered things and the video.
Chapters:
0:00 Intro
0:25 Project Overview
0:50 Adding Knockback the Simple Way
1:20 The Problem With Simplicity
2:03 Introducing Classes
3:41 Using the Class Again
4:06 Functions in Classes
4:21 Time for Another Year Long Break - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMSL SEA W2D2 | Summer | โหดจัด ซัดไม่เลี้ยง](http://i.ytimg.com/vi/TJa9d7tpSP4/mqdefault.jpg)
This is one of the greatest Godot 4 tutorials ive ever seen. Please keep it up because we need more devs like you
I really like your tutorials. It seems like most game dev tutorials on youtube just focus on getting X feature working as soon as possible but yours really take the time to teach the best practices which is very appreciated.
this is incredible, thanks so much! I was wondering how to avoid writing all movement functions, skills functions, etc all in the player script. Now I can create movement classes, skill classes and call them on the player scene (well in theory, now I need to figure it out haha)
Really enjoying these videos. Useful, concise and with clear examples. Keep up the great work!
Clear and well laid out. Thank you.
Excellent real-life example. I was conditioned to think of classes as linked to objects for inheritance, but it can be so helpful using them like this.
New to your channel, thank you for all the Godot content and keep it up! You have remotivated me to keep with my project. Thanks again!
This is exactly what I needed. I've been thinking about a way to create skills for my game in a modular manner, for something like a moba or roguelike with multiple weapons.
This will be perfect, thank you for the video!
Very useful tutorial.
I just subscribed to your channel because your content is great. I hope to see more of those great Godot tutorials from you.
This is the absolute best tutorial I've ever seen on classes. I never understood them before, and didn't get the point of them. this shows why they're useful and I love it. Thank you so much
This kind of approuch its what we usually call "Composition", and its an amazing alternative to "compose" funcionality all over our programs :D nice video bro!
That was a really good simple video. I finally got classes now! Thank you very much!
Your videos are the first tutorials I've seen that make me feel like I'm understanding both the tool AND the context it is used in. Instant Like/Subscribe.
This seems like a great modular approach! You can call whatever you need but ignore whatever you do not need. Will incorporate it, thanks!
Oh my, this is so valuable! Thanks
Great work. No fluff, straight to the point!
This is amazing for instantly explaining something ive been trying to understand thank you
Really great demonstration of the "accept interfaces return concrete types" design principle; always love when game dev channels help promote good general practices haha :3
This is so well made and easy to understand, thank you pal!
extremely helpful, your channel is a blessing
Man, this is SOOO useful, to do something similar i passed dictionaries as arguments, and from there i used the values, but this is so much better, i heard that godot classes were useful, but i thought that it were only used for inheritance.
keep it up man, this is awesome🌟
side note: I listen to your words in 0.75x
I really like your tutorials. ❤
Found this video alongside your others as very helpful thank you! Would love to get a use case for Resources as well! 🙏🏾
actually i think this is a great way of introducing the concept of Object Oriented Programming in general, beyond their use in godot!
amazing video ^-^!, i'm currently making a game for a jam and this would been very useful to know early on, now the code for my games would be less terrible...
legit GOAT tutorials
You are so underrated. Keep up the good work
Awesome explanation! Keep it up 👍
This is amazing, thank you sir.
Now I just need to learn GDscript XD
I was searching for a video just like this earlier. Nothing showed up. But, at 4am, TH-cam decided to recommend it out of nowhere. Thanks, TH-cam algorithm!
The search results on TH-cam got so bad that we have to rely on the algorithm sometimes..
@@whannabi and that's saying a lot considering the quality of the algorithm
Thank you for your videos!
thanks a lot....very well explained....helps a ton....
1:50 i hope there is overloading like in Java or C# for gdscript in the future. However the class approach I feel like it so much more maintainable and extendable. great video.
There aren't strict virtual methods and it doesn't warn you if you haven't implemented something, but you can overload methods in a child class and access the parent's version with super.methodName!
thanks for this video i never heard someone explain godot clases so simple and funcional, tnx
😢 1:10
😢🤪
sexë
46
?@@Show-wi7cw
OMG, this is so cool, tyvm :)
Godot my beloved
I enjoy this video
This is probable one of the most integral videos along with components, do you think you could do and in depth tutorial on how to make your own components from scratch just simple getting damage from source and modification of stands on a player?
Great video. Thank you. :)
Just switched to 4.0 and stumbled to this video. This coding technique really helps especially for totally coding noobs like me. I was just searching how to make an optional parameter and this is the answer. Suggestion/request, can you do state machines?
I'll keep that idea in mind, but I have a few other videos I want to tackle first
For an optional parameter, give it a default value.
func my_func(manditory_parameter : String, optional_parameter : String = ""):
print(mandatory_parameter)
if not optional_parameter == "":
print(optional_parameter)
func _ready():
my_func("Hello") # prints "Hello"
my_func("Hello World!", "I love you!") # prints "Hello World!"
"I love you!"
Awesome video!
thanks so much!
Great video
And sorry for bothering but pls keep with the decomp séries was helping me a lot
I might, but I feel like I've run out of the things I saw the most questions about. What other things could be covered that aren't super specific or already done better by other people like Rovert and fznmeatpopsicle?
@@Bitlytic I understood
I saw your tutorial on rovert and also on fzdmeatpopsicle and your videos are really good and they helped me a lot with rovert and fznmeat too
I think my biggest problem that I think can be a good video I'm learning c code now and I'm not very good at programming and I don't know where to start practicing to improve in programming in decomp
Can you give me a tip about a practice/exercise in the decomp that I can do to improve or make a video that may have people with the same doubt
And i have a doubt about custom objects would be cool if u do a video about a custom object if u want of course
And sorry if im bothering you with this question and text
Sorry about that i hope im not bothering
Amazing content! Keep up the awesome work. It’s great to be exposed to new ways of organizing our code! Thank you very much.
Thanks.
Wow this tutorial is amazing im so happy i clicked and watched it! It clicked and opened so many possibilites ty! Myb a dumb question but does this work with godot 3.5?
Yea, class_name should still be a thing in Godot 3.x, I remember using it before 4 released
Thats very usefull ! Tnx, Liked and subed.
after watching this about 30times in the past few months I finally understand lol
This is the best thing to discover. I am a Python user for 3 years and using classes is a best.
What I didn’t know is Godot HAVE CLASSES ALL ALONG, PLUS AUTOCOMPLETE.
Thank god this universe have Godot
"Why are you reading this? (DEBUG)" was hilarious
it's basically one of the pillars of OOP design in a nutshell
As a Typescript web developer, I am surprised this is news for so many game devs.
Good video!
THX!
thank ^^
Thanks
In godot-rust, would this hypothetical be just a regular struct named Attack?
Of course, since godot-rust doesn't support scripts directly, there'll be more like a node named HittableObject or something, but that's besides the point.
amazing tuto thank you!
by any chance is there a place I can see the rest of the scripts. I'm new to Godot (and all coding) and im struggling to make everything work :P
I was wondering, if the damage is handled by the hurtbox hypothetically how would the HP bar be managed? Also would it double the damage with the hurtbox also having a damage function?
this is a brilliant tutorial, but do you have any long detailed version of , I am a starter and some thing really get past from me..
Would there be any advantages to extending Resource in the custom class?
Small reminder to aspiring game devs, don't worry too much about optimizing your code. Focus on getting it to run first, no matter how scuffed your code is.
Cause when you try to optimize a code and something just doesn't seem to work no matter what you do, it can get very discouraging.
It's like learning how to make a motorcycle engine, but you don't even know how to change the oil and replace the oil filter.
So with this method, is there any reason to use autoload to have global variables or global functions? I've been annoyed that when you reference a function in autoload, there's no auto-complete so I always have to go to the script and copy/paste functions.
There are reasons to use Autoload, but for global variables/functions I would say class_name may be the better option. Autoload is handy because it's essentially just adding a node to the SceneTree, so if it needed to do things with hierarchy it would be handy. class_name is very similar but allows easy reference from other scripts, so I end up using class_name a lot more often.
The main use case for Autoload that I've seen is for audio, where you can use that to keep audio consistently playing between scene loads, since Autoloaded objects are persistent between scene changes
You have no idea how much I was bashing my head in trying to figure this stuff out. It isn’t that complicated overall, but the official documentation really doesn’t explain these concepts well.
Nice tutorial, but I do have a question - why not have a class for objects that you can reuse to create things like trees and crates, and another class for enemies (or whatever you want to call it) to create things like cows?
Obviously I don't know your game set up, but it looks like you have separate scripts for trees and crates, even though they look like they do the exact same thing. Having a single object class for them and another class for enemies would eliminiate this issue as well as simplify the number of scripts you have overall.
the way you use those clases as a argument, does it call strategy patter or injection? or there another name for that pattern?
Instead of "class_name is OP" your Title should say "class_name is OOP".
Dumb jokes aside this video is very helpful. Keep it up.
Im a lil confusios, why do we make a var attack = Attack.new() ?
Not sure what that does exactly.
God what I would pay for half of these creators to just SHOW ALL THE CODE.
So you’re basically instancing an attack object with all the attributes you want to pass through your damage function and access the attributes by attack.attribute in an overloaded function?
If you don't need to store methods/functions in your attack class you could probably get away with just passing in a dictionary called something like "attack_data". You're keeping your project folder cleaner by not adding a new file and dictionaries are slightly more performant than custom objects. The downside is; I don't think that you get auto-complete with this approach. I think it mostly comes down to personal preference unless you are going to have hundreds or thousands of attack classes being instantiated at once. Even then; you might be able to use object pooling to squeeze a bit more performance out of your project.
I see some downsides with this approach:
- you dont have any sort of "strict typing" here which i think has some suboptimal performance measures and increases debugging difficulty
- the attack class would reduce complexity of the code whereas the dictionary increases it - with the dictionary you either need to always count on yourself to know every possible key that could be referenced by any receiver of the attack, and always fill it out for every thing that does attacks, or you would need to break the benefits of encapsulation by having both the attacker needing to be aware of what its attacking and how that receives an attack and the receiver being aware of how the attacker could be sending the attacks.
- passing around a common dictionary means every creator of this dictionary would have to instantiate the dictionary either on the fly or its script scope - meaning a constant repetition of code, and one instantiation per attacker, whereas using the class the definition only happens in a single file and you are just instantiating it with the attackers property instead of a dictionary
@@mwatkins0590 You can use strict typing with built-in types, especially if you are using Godot 4.
You also don't necessarily have to count on yourself knowing or filling out every possible key if you are using duck typing and anything that is relevant you are going to have to fill out anyway when using a class unless you have a lot of default values which can be solved by just defining a master "attack_data" dictionary in a singleton that you just copy any time you want to use it.
I will agree, this isn't a very orthodox approach, debugging is a legitimate concern (although; less of an issue when you have powerful debugging tools like Godot has), and it does increase the complexity by some definitions but using a class increases the complexity by other definitions and to be honest, once you get used to working in this type of environment; it's not that difficult and can actually be more performant if done correctly. I mean, under the hood, all a class is; is a dictionary of attributes stored in memory right next to a bunch of methods. We are basically just arguing the pros/cons of Object Oriented Programming vs Functional and/or Procedural Programming. Again; I think it mostly just comes down to personal preference.
@@Deeredman4 I think compiler and runtime optimizations work differently on a dictionary with variants as keys/values than on a strictly typed class.
I am new to GDScript, but from my experience it seems it is not capable of using strict typing with dictionaries like another language would.
For instance, I can do
var myDict: Dictionary = {...}
but I cannot do
var myDict: Dictionary[string, int] = {...}
so the typing of the values can be changed at runtime therefore must be inferred during runtime instead of compile time
@@mwatkins0590 Aaah, yeah, very true, you can't use strict typing on each element of the dictionary individually. This is a legitimate downside. That being said; I think they MIGHT have fixed that in Godot 4? I know they did for lists, I'm not sure about dictionaries and even if they did; you probably can't mix and match different types in the same dictionary. I don't really use static typing unless I need to so it doesn't really affect me but I could see why someone would have an issue with this approach. Good catch!
@@Deeredman4 I have only used godot 4 so if its possible id like to know. it definitly works for arrays though like Array[String] but unfortunately not things like Array[Array[String]]
Hmm, is there a garbage collector in goot tho? If I attack something a lot of times will all of those attack classes still be stored in memory?
Where can I get the images of the white bear (sprites sheet)?
One side is like 'classes are powerful' and the other is like 'composition is powerful!'
I just wanna make a game where you grill for god's sake
You can use both... but yeah maybe stick to good old code if you're new and/or want things super simple
Beware, my unsoliticed advice:
Classes and composition are compatible, I think you meant inheritance instead of classes. So, this example has no issues with composition, doesn't replace what composition does so you can use it as you like. You can compose your bigger classes of other smaller classes for example; that's what composition is. As an example, this is composition:
Player
- Weapon
- Health
While this is inheritance:
Player
Why not send the Node as a parameter in the attack function, and then use node.attack, node.knockback, etc. inside each object's hurt function?
subbed :)
Is that something typed gdscript will warn you about?
im a bit of Dum dum.... But arn't Classes and Const pretty Similar? 1-
i know the point of Classes is to De-couple Scripts from Requiring you to leave Breadcrums... and the Autofill is Great!, but i am Just curios if there any Differences between them xD...
Example: 1-
i kind of forgot how to write it as I'm still learning...
1- conts POSSIBLE = 0
2- var Name = POSSIBLE
I would like to add my two cents to this. Instead of naming the procedure damage, it will be better to name it get_damage. That way the check will look like "can this object get_damage".
Yeah, that would make the code more readable for sure.
As I understand it godot script is based on python. In python we woulnt worry about the class because you can always try: attack.knockback catch. Is there something similar in godot?
So unfortunately gdscript doesn't have try/catch, although we could do attack.has_method or similar. The class does have benefits though like intellisense and documenting our code for the future
The Attack class should probably also extend Reference since it otherwise will not be freed automatically, creating a memory leak.
Also, you could make a new class for the trees, crates and enemies so you can check if the object you hit is of that class and you won't have to check if it has a damage function (with just 1 function this is fine but if you have to check for like 10 functions then the code gets hard to read).
Do you have any sort of article/info link on the memory leak issue? I haven't extended reference before and would love more info since I haven't noticed a leak before.
And for the other solution, I was considering making a video that approached a solution like that as well
@@Bitlytic th-cam.com/video/U6zHnNffnGE/w-d-xo.html
This video explains memory leaks pretty well, but basically you're creating a new object every time you attack, and that object doesn't get freed from memory until you call Object.free() on it. Reference makes it so that the object is automatically freed once you no longer reference it anywhere anymore (basically once you're done with it). This means you don't have to worry about freeing it yourself which is quite helpful.
@@elmarhoppieland Just a quick update on this: I did some testing and it seems like in the case shown in the video, the Attack objects do free themselves since they leave scope. I made a change so that each attack was stored in an array just so they wouldn't leave scope, and that does seem to increase the memory pool. I didn't see any increase in memory over a long time caused by the attacks unless they were stored
if you've to check 10 functions, then the caller is an orchestrator and probably dealing with state mutations that it should not.
Testing the existence of methods is more or less testing for the presence of an interface.
Also, you may run into the square/rectangle issue as one class can only inherit from at most one other class.
As an example, you can hit a tree, a box and a cow. Those are unrelated objects, but they would implement the "hittable" interface.
You could also burn the tree and the box. That would be the "burnable" interface.
Some things would also be "burnable" without being "hittable"...
If you tried with inheritance, you would already bump in an issue of what inherit what!
And because Godot doesn't have interfaces, the closest is duck typing through testing the availability of methods.
Godot classes extend Reference by default.
Why would you attack a cow? The cow is nice
Cow can moul the man
Fuck the cow
Is there a reason not to make everything a class? I’ve been doing so, then casting my $Node references to its class just for autocomplete
Mind boggling how a struct in godot is a revolutionary concept.
Agreed
You'd think classes are something fundamental enough to not make it sound like a hidden feature.
I'm sorry, it's so funny to me to use the Sprout Lands pack to make a violent game lol. Meanwhile I am over here basically making an easter egg hunt simulator with it
Wwould be nice if you share a github project, great tutorial btw.
projectoverview
could you please upload your code. thank you.
I may look at stripping some of the art out of it and uploading it, since it uses premium assets and I'd rather not distribute those for the artist's sake
@@Bitlytic Please consider! I would love to see the full project.
gdscript needs to be able to define objects as types
Can you release code please
A Resource wouldn't be better?
I LOVE THIS ASMR TH-camR!!! SO MUCH INFORMATION
Great video. But please zoom in the code.
Will do in the next video and see how people like it
I dont know if its my ADHD but I can't follow this at all. well after 2 hours I figured out my issue. turns out it was me
I also go kinda fast, so I really don't blame you
I do appreciate the delivery its very good in my opinion.
The name of the project : why are u Reading this☠️
Pretty nice, but isnt this what a resource is supposed to be used for?
Poor cow
Sorry, imma be honest. I havent learned anything from this tutorial even tho i tried to understadnt it. This is a classic example of: do x, add y to get z.