Surprise! I made another video. :) Here is the Github repo for this project (under MIT license): github.com/uheartbeast/youtube-tutorials/tree/master/Action%20RPG Fixing jitter and stutter: docs.godotengine.org/uk/latest/tutorials/misc/jitter_stutter.html This video was made possible by my wonderful Kickstarter backers. If you are interested in taking a deeper dive into the Godot game engine you can buy my 1-bit Godot Course at this link: www.heartgamedev.com/1-bit-godot-course-youtube Thanks again for the support. - Ben P.S. Don't forget to wash your hands.
for anyone having trouble with the clamped() function, it's been deprecated and it's now limit_length() instead. there's a clamp() function in Vector2 but it requires 2 vectors, a minimum and a maximum, and I'm not sure how it works for this case but limit_length() does the job
As a mathematician, hearing people actually explaining the math behind a function melts my heart. I am so pleased with these videos and how things are explained!
I was literally wishing all day that you would make this series a daily series but then I thought that would be ridiculous! But look at this!! Thank you again for everything Ben!
TIP: Important difference between move_and_collide() and move_and_slide(): move_and_slide() ALREADY uses delta automatically, so you shouldn't multiply your velocity by delta when using it move_and_collide(), which is what HeartBeast uses in this video, does NOT automatically do this. You have to pass in velocity multiplied by delta, as HeartBeast demonstrates
@@Dxpress_ Well, this really confuses me too. My only attempt to explain this inconsistency is, that move_and_slide would be normally used for player movement. You are not interested in collisions; if the player character bumps into anything, just slide along. Therefore, this is multiplied by delta to ease writing code. Contrary, move_and_collide returns a CollisionBody2D. You will probably use this function to check for collisions, before you move. For example, if you want to know, if there is a collidable object in 30 units or less in front of you, you could use move_and_collide to check. If delta would automatically be applied to move_and_collide, you would not have a good chance to predict, what distance you would have checked for collisions for, since its 30 multiplied by 1/FPS. So, this would explain, why move_and_collide does not automatically multiply by delta. However, the only reason I can see that move_and_slide does so, is saving you from writing "* delta" for this function or worse, forgetting to do so - at the very questionable cost of understandability. I hope, my comment is somewhat comprehensible, it is pretty late...
Honestly im so thankful for this series. This video alone explained a math concept to me that i had been struggling with for months. Applied to a coding context and explained by your smooth voice and I understood vectors and normalizing them in minutes. Coding and game dev especially is helping me answer a lot of those "when will this be useful" questions that I had so often in math classes
Wow Ben, back to back? I thought for a minute these might be pre-recorded, but the date on your PC says otherwise... right? :D You're a machine! Thanks so much for all you do for this community.
Not only a great teacher, but understands and explains things at a deeper level than necessary if just "getting the job done" which produces high value content
For anyone watching and trying with Godot 4.0 beta, I had to use CharacterBody2D as KinematicBody2D was superseded by CharacterBody2D. As such, "velocity" is a member attribute of CharacterBody2D, so you can't create the variable, but you can still manipulate the attribute. There also must have been some change to the integer values of it as I had to add two zeros to each value provided in the video for ACCELERATION, MAX_SPEED, and FRICTION to get it to behave the same way as on the video. 1,000, 10,000, and 1,000 respectively. My character was moving incredibly slowly, like one pixel per second until I did this. Hope it helps someone.
The slow movement comes from the fact that move_and_collide (and all the other move functions) are internally multiplying with delta. At least I believe so Edit: only move_and_slide is multiplying internally
I'm showing my ignorance, but it's worth it to say thank you. That was the simplest and best description of normalize I've ever seen. It's always been a thing I knew how to use, but I've never known really what it's doing. Thank you.
when I started with godot. I found your channel and your tutorials and I finished it and I had a basic knowledge of godot. And now you are still a great youtuber to learn
This was way more useful than I thought it was going to be! I didn't need a script kiddy course, but the why's behind what I'm doing and you sir lay out exactly what and why we are doing things in a very clear and easy to understand manner. New sub here, thank you!
I AM LOVING YOUR TUTORIALS people like brackeys don't always explain what he is doing, you are the only one who was successfully able to explain to me what normalized means in a simple manner ps. I'm really liking godot not the same for 3d but its prob my main for 2d unreal for 3d.
Other tutorials out there provide a nice introduction to the basics of movement, but yours is applicable to an actual game. The difference acceleration and friction makes is huge, and using a normalized input vector improves the quality further. Thank you for this tutorial.
After all 600 indian Unity youtube tutorials i've tried to watch this was really a breeze to understand. Thank you so much, you're going to be my foundation to hopefully make some cool games
Man I just decided to try out Godot to learn game making and hopefully programming at the same time, with no prior understanding I am finding it a little tricky because Godot doesn't seem to have the same sized community and the like of unreal and unity. Just stumbled on your channel and have to say even as a 35 year old dumbass like myself your videos are great and I have subbed and will support you where I can. You have a great way of explaining things and I could easily see you becoming one of the top channels if not the top for Godot, keep it up and regards from New Zealand.
You should visit the Discord server of the Godot community, I usually get my answers there within minutes (if its a simple question) , they are really helpful.
This is so fun to watch, i like how you explain what everything does and not like others which pretend that you know what most things do, time to try and make my own game!
This is LitErallY the best dam tutorial, I see others but they aren't the best explainers and use fancy words, making it hard to understand. With u make it so beginner friendly. Which I love so, thank u!!!
You are a great teacher! Extrapolating possible solutions and then using differeent ones as appropriate to solve the same problems really shows u were a born teacher
OH MY GOD THIS SERIES IS SO GOOOOOD! thank you so much for making it. I've been trying so hard to look for a video to help me with this. You just gave me everything. Once again thank you!! and I would totally recommend this to anyone.
Even though I know most of the concepts from using other game engines, I love your explanations! They're very clear and visual. Some of the other Godot "beginner" tutorials slap some very specific lingo around like it's nothing without explaining what all of it does. I already look forward to watching your other videos, keep it up!
@@Luka-sf3vu I have a comment about that in the final video (I assume you mean the 3.0 platformer). I ended up making a different series to teach about themes which was the only other thing I was planning to add to the platformer series.
For the physics to be consistent you still need delta squared for your friction. I would move the velocity = velocity.clamped line below the if else statement so the friction can have the same smooth acceleration curve.
hahaha "That is... not a circle." No joke tho, great tutorials. Thanks! Will likely buy the kickstarted course, your teaching style is easy to work with and thorough.
I did things a tad differently, I wanted my max speed, velocity, and friction variables to still sort of be measured in pixels per frame, so I made a separate value called game_speed which was just delta multiplied by sixty. When using that new variable instead of delta directly, my variables aren't just some large arbitrary number, they're the amount of pixels they'd move if the game were locked at 60 fps (but of course with the benefit of not actually being locked at that frame rate). Ultimately I just did this to prove to myself I actually understood what you were saying to some degree rather than just copying what you were doing verbatim, not all that many benefits to doing it my way to be honest.
I'm really appreciating the video series so far. Thank you for the content! I'm also wincing every time we're multiplying in "MAX_SPEED" 🤣 EDIT: Oh good, it gets changed to use move_toward(), and multiplying it in makes a lot more sense now.
normalizing is a pretty high up math concept for highschoolers/dropouts atleast but hey knowing that normalizing a square gives you a circle from coding is a neat way to learn too :P but yeah i think your explanation was fine enough for someone who doesnt need to know the higher math edit: also for those following along, do tight circles with your character (or ramp the speed up works aswell if you have enough screen size) and you can see how 'rhomboid' the movement looks, vs normalizing turns it into a pseudo circle with cardinal inputs
As a beginner who was feeling overwhelmed by so many other "beginner" videos, this series is proving invaluable to me and I'm only 2 videos deep! So many vids explaining basics gloss over why a thing does a thing and just tell you to do or type a thing. I'm somebody that NEEDS to know why a thing works or functions the way that it does, and you not only do a good job of explaining concepts as they are introduced, you show how I can go more in depth on my own with the "search help" bits. You've demystified a bunch things that were becoming increasingly frustrating that others weren't explaining in a way that I could intuitively grasp. I still feel somewhat overwhelmed with just how much their is to learn and understand, but you've helped that feeling become manageable for me and I thank you so very much for all the work you've done!
Just a heads up for anyone who wants to use joystick, normalizing will make the joystick treat controlled movement as if you were pushing in the same direction at maximum force. If that isn't the behavior you want, you can fix this by only normalizing if the .length() of the vector is greater than 1.
godot 4 made several changes that slightly differs from this tutorial - velocity is now a built-in variable, so no need to declare it - move_and_slide() now factor in delta as part of its internal function, so you don't need to manually multiply velocity by delta - .clamp() function now requires two input which might make it wordy if entering values for Vector2. I used velocity.limit_length(MAX_SPEED) as a work around
velocity.limit_length works perfectly! i was having trouble where even though my velocity values were showing the same as his were, my character was moving painfully slowly
Does clamping to a value based on delta seem weird? Especially since the velocity is carried over from the previous tick. Wouldn't you want to keep velocity in absolute distance/time units. Then scale it at the last possible moment with delta? Imagine if you are at the max speed and suddenly delta is halved, then it would clamp the velocity to half the previous max speed. At the next time step it would then accelerate again.
Ooops, good catch. That was not intentional on my end. You are correct that we should be multiplying by delta after clamping not inside the () of the clamp function call. I'll be sure to fix that in the next video.
@@uheartbeast It's best to just leave the `delta` at the end inside `move_and_slide()`. With the current code - even once the `delta` is outside the `clamp()`, you'd still have framerate dependent deceleration. Also something interesting to think about: One may use `move_toward()` to accelerate and deaccelerate every frame, making it pretty easy to change friction based on the ground/tiles the character is standing on or moving over.
I appreciate the tutorial, but as someone from a programming bg I must say: You repeat yourself in your code... Your code at 7:25 can be simplified to: ``` extends KinematicBody2D const MAX_SPEED = 100 var velocity func _physics_process(delta): var input_vector = Vector2() input_vector.x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left") input_vector.y = Input.get_action_strength("ui_down") - Input.get_action_strength("ui_up") if input_vector.length() > 0: velocity = input_vector.normalized() * delta * MAX_SPEED else: velocity = Vector2() move_and_collide(velocity) ``` When you create a Vector2() object, the default constructor creates an equivalent value to Vector2.ZERO, no need to create a new Vector2 and return Vector2.ZERO: 1. Your conditional statement on line 13 is creating a new Vector2 Object to compare to Vector2.ZERO. You can use .length() method to see if the character is moving diagonally. No need to create a new instance of a Vector2. You're essentially creating a new instance every frame when you don't need to create anything. 2. You don't need to have your input_vector normalized for all cases, or need to calculate arithmetic for all cases except for when movement occurs; so it can be refactored as above. Will these really make or break performance? For a 2D game, probably not considering how powerful gaming has become, but I think it's best not to repeat yourself.
Thanks for the feedback! Those are good ways to reduce the code down. However, as a teacher, some of the extra steps/lines are intentional. I'll often split something into multiples lines that could be done in a single step because it is easier for new programmers to follow. Similar to algebra, showing every single step (even if it is a be tedious and unnecessary) is important as people are learning those steps. Vector2.ZERO vs Vector() is more of a personal preference. I prefer Vector2.ZERO because I think it is more readable but there is a small performance tradeoff there. That doesn't mean there isn't still room for improvement, I'm sure there is. My code is far from perfect. But I would ask that as you see the steps I take try to filter it through the lens of giving each task its own line to help beginners follow along.
@@uheartbeast Well if it's any consolation, you're still a better game developer. Your tutorial is of the highest quality I've seen so please keep it up!
wow. I have been coding for a while, but I never really got to learn how to make character controllers (I like to make inventory/stat systems). You explained the concept behind so well! Recently because of Unity’s drama, I feel unsafe with them. I wish they didn’t take this path :/ Unity had such a huge community and their engine is honestly really balanced… Unreal is too heavy on for my PC and Godot seems too “simple” though I am searching about it and it actually seems kind of nice… I love scriptable objects and I heard Godot has “Resources” which is the equivalent and it seems to be even more flexible :D so I will at least start to get to know Godot’s interface, GD scripts, and the nodes :P YK in case Unity trolls their devs again ;-;
Man, i probably couldn't be able to figure out some of these things, like movement with friction\acceleration on my own '~' Hope it gets more natural with time, thanks for the lessons!
Just a note about something that I've just noticed. I'm running Avast AntiVirus and the Safe Save feature of Godot (which according to the description decreases file corruption upon crash) seems to be something of an issue for the antivirus software. If you get an error about lacking permissions to safe save (happens when you launch your game), add Godot as an exception.
As I know, for physic process, delta is the same for each iteration and depends only on the settings. If you pc at some point doesn't able to handle this delta, it will keep the same value in code, but will consume more real time, so game will work slower, and that's how it suppose to work. If physic delta was changing depending on performance, then there would be bugs, like objects goes through each over because of big delta. But in the (render) _process, delta actually varies depending on performance, because there shouldn't be any physic logic on render, so if it lagging, the game will works the same way, but the player just will see the render of the current state less often. It's still a good practice to multiply by delta even in the physic process in case you change the settings so the game will still work the same way
Yup that is correct. I guess I wasn't clear enough about that in the video. I do say that delta in the physics process is constant (I was trying to say that it doesn't actually change and should always be 1/60th of a second but I wasn't clear and talked some about delta in general and why we use delta). Overall I think the way I switch between the concept of delta and the actual value of delta in the physics process came off as a bit confusing.
@@redfiend Не обязательно 60, это в настройках проекта задаётся. Физику всю лучше делать только в physic process, но помнить о том, что перегружать его не надо. Собственно process, тоже перегружать не надо. По хорошему вообще никаких проблем с этим возникать не должно, а если возникают, то что-то скорее всего делается не так. Если какие-то сложные периодисеские задачи запускаются в любом из process, то возможно стоит их выносит в поток отдельный, чтоб они ни физику, ни отрисовку не тормозили. Например обдумывание хода икуственным интеллектом
@@redfiend ну, я не знаю как это в годо конкретно делается, не приходилось пока узнавать, просто в различных графических приложениях часто с таким сталкиваешься, что начинает что-то тяжёлое в основном потоке делать и весь интерфейс зависает, потому что ни отрисовка следующая не начнётся, ни ввод не считается. Фишка integrated forces, несколько я понял, только для rigid body. Он вызывается до physic process, и ты как-бы заранее задаёшь вектора все для своих rigid body, чтобы когда уже полноценно физика начала применяться, они были заданы. В process точно физику не надо отрабатывать, там то, что связано с отображением, типа обновить состояние интерфейса и т.д.. Не парься насчёт того, что physic process забьётся, это прям реально дофига физики нужно одновременно использовать, и то в этом случая перевод всего в process никак не поможет. Либо какие-то оптимизации придумывать, либо уменьшать в настройках частоту физики, если это приемлемо
Max speed doesn't need to be multiplied by delta, since it's just a limit that is being checked for. Please correct me if I'm wrong on that though. Also, thank you so much for these videos - I'm enjoying them so far!
I had stutter on Windows 11 using in Godot 3.4.4 stable, and setting "Vsync Via Compositor" to true in the Project settings (under General -> Display -> Window) fixed it completely. :)
Guys: WATCH THE NEXT VIDEO - He corrects and changes a lot there! For example I was wondering why he multiplies max_speed with delta. Also he shifts to move_and_slide instead of move_and_collide.
I was following, and when I got to the "move_toward" thing, it didn't work, so I had to reinstall Godot in 3.2.2 so it works PS: Love your vids, hope you make more
Hi Ben Thank you for this. I have a couple of questions First one Over what amount of time are you planning to complete this series? Of course you are doing this free so please don't take it wrong, I'm, by no means, trying to make you feel pressed. Not that I could anyway, but I'm just curious. The second one Is the 1-Bit course updated to the latest Godot Version? Are you planning to update it along Godot Updates? Or are you going to make a new one? I'm asking all this because I have to save a bit to be able to afford it and I want to be sure before I get it.
Hey! I'm guessing this series will take me a couple months. I'm planning on doing about 3 videos a week (I'll know for sure once I get into the flow of recording and such). The 1-bit Godot Course was recorded in Godot 3.1 but students are taking it in 3.2 and it is working fine. I'll be making sure the course works on future 3.2 versions as well (with comments and additions in post since I can't re-record the entire series). Either way learning the basics of how godot works and how many of the different nodes work will carry over into all future iterations of Godot. I learned Godot with Godot 2.1 and I was easily able to pick up Godot 3.x. Hope this helps! Thanks for the question.
One mistake within your explanation(at least as of Godot 3.3 and onwards) is that a normalized vector isn't clamped to a length of 1(the vector's length is called a magnitude btw). It's always turned into a magnitude 1 vector, whether it's longer or shorter than 1.
Surprise! I made another video. :)
Here is the Github repo for this project (under MIT license): github.com/uheartbeast/youtube-tutorials/tree/master/Action%20RPG
Fixing jitter and stutter: docs.godotengine.org/uk/latest/tutorials/misc/jitter_stutter.html
This video was made possible by my wonderful Kickstarter backers. If you are interested in taking a deeper dive into the Godot game engine you can buy my 1-bit Godot Course at this link: www.heartgamedev.com/1-bit-godot-course-youtube
Thanks again for the support.
- Ben
P.S. Don't forget to wash your hands.
Thank yooou soo muuch, I'm learning a bunch with you
can you help? the input_vector = input_vector.normalized() is red for me D:
@KGB still didnt work
@KGB its fine but it somehow didnt work anyway :(
@KGB how do i change var name? sorry im a beginner at this stuff xP
for anyone having trouble with the clamped() function, it's been deprecated and it's now limit_length() instead.
there's a clamp() function in Vector2 but it requires 2 vectors, a minimum and a maximum, and I'm not sure how it works for this case but limit_length() does the job
BROO THANKS !
Saved me
Appreciate it. Was trying to figure out why float wasn't an appropriate argument.
MUCH OBLIGED!
You are a life saver, man
As a mathematician, hearing people actually explaining the math behind a function melts my heart. I am so pleased with these videos and how things are explained!
nice
nice
I bet you didn't appreciate when he referred to constants as a type of variable though.
@@kishirisu1268 They said they're a mathematician. In mathematical theory, constants and variables are opposites.
As a fellow mathematician I can relate 🥴👍
me: why is his movement so much faster than mine?
also me: ah right, im watching the vid in 2x speed
I didn't recognize that till I see this comment hahahaha. I watch it in 2x too.
wait.. FUCK how did I not notice this lol
My speed is so slow and I’m not watching on 2x speed
@@bighazza3470 I forgot to delete the "delta" in my move_and_collide and it made my game almost not move at all
@@kimojumamil6121 i noticed it right now
I was literally wishing all day that you would make this series a daily series but then I thought that would be ridiculous! But look at this!! Thank you again for everything Ben!
lol 😄😄
TIP: Important difference between move_and_collide() and move_and_slide():
move_and_slide() ALREADY uses delta automatically, so you shouldn't multiply your velocity by delta when using it
move_and_collide(), which is what HeartBeast uses in this video, does NOT automatically do this. You have to pass in velocity multiplied by delta, as HeartBeast demonstrates
why aren't you pinned
Is there any particular reason why this is the case?
Because if not, they should really be changed to be consistent.
@@Dxpress_ Well, this really confuses me too. My only attempt to explain this inconsistency is, that move_and_slide would be normally used for player movement. You are not interested in collisions; if the player character bumps into anything, just slide along. Therefore, this is multiplied by delta to ease writing code.
Contrary, move_and_collide returns a CollisionBody2D. You will probably use this function to check for collisions, before you move. For example, if you want to know, if there is a collidable object in 30 units or less in front of you, you could use move_and_collide to check. If delta would automatically be applied to move_and_collide, you would not have a good chance to predict, what distance you would have checked for collisions for, since its 30 multiplied by 1/FPS. So, this would explain, why move_and_collide does not automatically multiply by delta. However, the only reason I can see that move_and_slide does so, is saving you from writing "* delta" for this function or worse, forgetting to do so - at the very questionable cost of understandability. I hope, my comment is somewhat comprehensible, it is pretty late...
ah yes, now my speed value doesn't have to be 5000
so what should i use then move_and_slide() or move_and_collide()
Honestly im so thankful for this series. This video alone explained a math concept to me that i had been struggling with for months. Applied to a coding context and explained by your smooth voice and I understood vectors and normalizing them in minutes. Coding and game dev especially is helping me answer a lot of those "when will this be useful" questions that I had so often in math classes
Wow Ben, back to back? I thought for a minute these might be pre-recorded, but the date on your PC says otherwise... right? :D
You're a machine! Thanks so much for all you do for this community.
Not only a great teacher, but understands and explains things at a deeper level than necessary if just "getting the job done" which produces high value content
For anyone watching and trying with Godot 4.0 beta, I had to use CharacterBody2D as KinematicBody2D was superseded by CharacterBody2D. As such, "velocity" is a member attribute of CharacterBody2D, so you can't create the variable, but you can still manipulate the attribute. There also must have been some change to the integer values of it as I had to add two zeros to each value provided in the video for ACCELERATION, MAX_SPEED, and FRICTION to get it to behave the same way as on the video. 1,000, 10,000, and 1,000 respectively. My character was moving incredibly slowly, like one pixel per second until I did this. Hope it helps someone.
Same in the last 3.5
@@Luusco Are you sure its in the latest stable(3.5.1) because I am encountering this problem but I cannot find the CharacterBody2D
@@QCumber-cl7wi it's not character body, but te same problem with the numbers in de kinematic body
The slow movement comes from the fact that move_and_collide (and all the other move functions) are internally multiplying with delta. At least I believe so
Edit: only move_and_slide is multiplying internally
Thank you so muhc, this was really helpful
I'm showing my ignorance, but it's worth it to say thank you. That was the simplest and best description of normalize I've ever seen. It's always been a thing I knew how to use, but I've never known really what it's doing. Thank you.
This is the best game programming tutorial I have ever seen. Thanks for making it.
From this point on I turned off my adblocker and started watching the ads completely without skipping
Much Love Ben!
Thanks!
I’ve been hearing and reading the phrase “normalize the vector” for years now and had no idea what that meant until now. Great stuff!
when I started with godot. I found your channel and your tutorials and I finished it and I had a basic knowledge of godot. And now you are still a great youtuber to learn
This was way more useful than I thought it was going to be! I didn't need a script kiddy course, but the why's behind what I'm doing and you sir lay out exactly what and why we are doing things in a very clear and easy to understand manner. New sub here, thank you!
You are the best person i have seen in youtube in ages! Really amazing seeing such a nice community around here! Your help is very much appreciated!
I AM LOVING YOUR TUTORIALS
people like brackeys don't always explain what he is doing, you are the only one who was successfully able to explain to me what normalized means in a simple manner
ps. I'm really liking godot not the same for 3d but its prob my main for 2d
unreal for 3d.
You are the Bob Ross of game design. I love you man.
Other tutorials out there provide a nice introduction to the basics of movement, but yours is applicable to an actual game. The difference acceleration and friction makes is huge, and using a normalized input vector improves the quality further. Thank you for this tutorial.
the intro gives me so much joy for some reason
After all 600 indian Unity youtube tutorials i've tried to watch this was really a breeze to understand.
Thank you so much, you're going to be my foundation to hopefully make some cool games
Man I just decided to try out Godot to learn game making and hopefully programming at the same time, with no prior understanding I am finding it a little tricky because Godot doesn't seem to have the same sized community and the like of unreal and unity. Just stumbled on your channel and have to say even as a 35 year old dumbass like myself your videos are great and I have subbed and will support you where I can. You have a great way of explaining things and I could easily see you becoming one of the top channels if not the top for Godot, keep it up and regards from New Zealand.
You should visit the Discord server of the Godot community, I usually get my answers there within minutes (if its a simple question) , they are really helpful.
@@r4nddon thank you for that man I will do.
This is so fun to watch, i like how you explain what everything does and not like others which pretend that you know what most things do, time to try and make my own game!
Wherever and whenever you are is such a nice greeting. I feel immensely welcomed.
Really, REALLY excited about this series :) Thank you so much for providing this for the community!
This is LitErallY the best dam tutorial, I see others but they aren't the best explainers and use fancy words, making it hard to understand. With u make it so beginner friendly. Which I love so, thank u!!!
Tho I have a question, could u pls make a simple RTS tutorial?
RTS type game*
In Godot*
You are a great teacher! Extrapolating possible solutions and then using differeent ones as appropriate to solve the same problems really shows u were a born teacher
OH MY GOD
THIS SERIES IS SO GOOOOOD! thank you so much for making it. I've been trying so hard to look for a video to help me with this. You just gave me everything. Once again thank you!! and I would totally recommend this to anyone.
Finally!!! I see what DELTA does.... Best explanation on TH-cam! Thanks, Ben!
Even though I know most of the concepts from using other game engines, I love your explanations! They're very clear and visual. Some of the other Godot "beginner" tutorials slap some very specific lingo around like it's nothing without explaining what all of it does. I already look forward to watching your other videos, keep it up!
There it is. Immediately you explained the delta speed and changed some values. Sweet. Thanks.
thank you for making this tutorial series, I've just started experimenting with making a game like this in Godot
I thank you so much, not only for the tutorialseries, but for pointing on godot. The work with this engine is so comfy! THX!
I've watched a lot of tutorials and i can tell that this series helped me the most thank you very much
Thank you from a 70 year old retiree! Very informative tutorial!!
TNice tutorials is THE most helpful tutorial on TH-cam imo. I am starting production in Hardstyle, and I find soft soft really useful
pretty good description of .normalised thank you i had problems understanding it
Thank you for these tutorials! Me and my friend are creating a game for a national project in our country and you are helping us a lot! Thank you!
You're welcome! Thanks for the comment :)
@@uheartbeast Also I recommend that you first finish platfomer before you start putting more series on your channel. But that's up to you :)
@@Luka-sf3vu I have a comment about that in the final video (I assume you mean the 3.0 platformer). I ended up making a different series to teach about themes which was the only other thing I was planning to add to the platformer series.
oh my god. You are the BEST coding teacher ive ever had. Thank you for teaching me, mentor
For the physics to be consistent you still need delta squared for your friction. I would move the velocity = velocity.clamped line below the if else statement so the friction can have the same smooth acceleration curve.
use limit_length() instead of clamped() in 4+
thank youuuu
Thank you so much for this tutorial. I’ve learned so much already. I can’t wait to put this knowledge into my first original game.
Literally the best tutorial for godot, I really like it :) Also, it's very lucky for me that you are developing ARPG game cause me too
Thanks as always Ben.
hahaha "That is... not a circle." No joke tho, great tutorials. Thanks! Will likely buy the kickstarted course, your teaching style is easy to work with and thorough.
I did things a tad differently, I wanted my max speed, velocity, and friction variables to still sort of be measured in pixels per frame, so I made a separate value called game_speed which was just delta multiplied by sixty. When using that new variable instead of delta directly, my variables aren't just some large arbitrary number, they're the amount of pixels they'd move if the game were locked at 60 fps (but of course with the benefit of not actually being locked at that frame rate).
Ultimately I just did this to prove to myself I actually understood what you were saying to some degree rather than just copying what you were doing verbatim, not all that many benefits to doing it my way to be honest.
I found I was having errors about the variable Velocity. Eventually I just changed it to "vel" and it worked
I have tryied to make my dream game for so many times But this time everything works with no problems. Thanks a lot
Nice! Thank you!
Thank you for your tutorials! Really helpful for studying Godot from scratch!
If your sprites are moving a tiny amount (like floating) when you walk around then check that they are placed using pixel snap in their scenes.
Execellent tutorials.i have done nicely in python but I didn’t understand any events in Godot.keep up the good work!
Just finished this part of the tutorial! Thanks onwards we go!
I'm really appreciating the video series so far. Thank you for the content! I'm also wincing every time we're multiplying in "MAX_SPEED" 🤣 EDIT: Oh good, it gets changed to use move_toward(), and multiplying it in makes a lot more sense now.
Excellent video series so far. The explanations are tremendous. Thanks
Pls continue this amazing work (i'm new, i need)
It's a great tutorial, and the algebra explanations are even better than the ones I got from my teachers
Thanks man, you are gold. Best tuts on TH-cam.
This is amazing--thank you so much for putting this on TH-cam!! ♥
Thanks for the video!
This is the best game programming tutorial !
I feel like this code could have been simplified even more but I appreciate this series it's a big help
thanks for the video.
waiting for the new one
Hopefully Monday *crosses fingers*
thank you very much for this wonderful tutorial
normalizing is a pretty high up math concept for highschoolers/dropouts atleast but hey knowing that normalizing a square gives you a circle from coding is a neat way to learn too :P
but yeah i think your explanation was fine enough for someone who doesnt need to know the higher math
edit:
also for those following along, do tight circles with your character (or ramp the speed up works aswell if you have enough screen size) and you can see how 'rhomboid' the movement looks, vs normalizing turns it into a pseudo circle with cardinal inputs
Your video is really helpful thanks a lot
Thanks A Lot , you explain things beautifully
Alltho i dont understand math very well, with this video i now at least know what makes the movement smooth.. nice tutorials man
Dude it work really well thank you
As a beginner who was feeling overwhelmed by so many other "beginner" videos, this series is proving invaluable to me and I'm only 2 videos deep! So many vids explaining basics gloss over why a thing does a thing and just tell you to do or type a thing. I'm somebody that NEEDS to know why a thing works or functions the way that it does, and you not only do a good job of explaining concepts as they are introduced, you show how I can go more in depth on my own with the "search help" bits. You've demystified a bunch things that were becoming increasingly frustrating that others weren't explaining in a way that I could intuitively grasp. I still feel somewhat overwhelmed with just how much their is to learn and understand, but you've helped that feeling become manageable for me and I thank you so very much for all the work you've done!
It's still a slog, took me a few days to understand the first vid fully, but I think I'll have this one figured within another day
Just a heads up for anyone who wants to use joystick, normalizing will make the joystick treat controlled movement as if you were pushing in the same direction at maximum force. If that isn't the behavior you want, you can fix this by only normalizing if the .length() of the vector is greater than 1.
you teach like my comp sci teacher so I dig that
sounds good, gonna use this to learn godot now thanks ;)
i love you. i love you. i love you. this tut is frigging epic man! Thank you so much!
godot 4 made several changes that slightly differs from this tutorial
- velocity is now a built-in variable, so no need to declare it
- move_and_slide() now factor in delta as part of its internal function, so you don't need to manually multiply velocity by delta
- .clamp() function now requires two input which might make it wordy if entering values for Vector2. I used velocity.limit_length(MAX_SPEED) as a work around
velocity.limit_length works perfectly! i was having trouble where even though my velocity values were showing the same as his were, my character was moving painfully slowly
Thanks! Why do we not use velocity.limit_length(MAX_SPEED * delta)? What happened to the delta?
When a game making tutorial explains normalizing a vector better than University
Does clamping to a value based on delta seem weird? Especially since the velocity is carried over from the previous tick. Wouldn't you want to keep velocity in absolute distance/time units. Then scale it at the last possible moment with delta? Imagine if you are at the max speed and suddenly delta is halved, then it would clamp the velocity to half the previous max speed. At the next time step it would then accelerate again.
Ooops, good catch. That was not intentional on my end. You are correct that we should be multiplying by delta after clamping not inside the () of the clamp function call. I'll be sure to fix that in the next video.
@@uheartbeast It's best to just leave the `delta` at the end inside `move_and_slide()`. With the current code - even once the `delta` is outside the `clamp()`, you'd still have framerate dependent deceleration. Also something interesting to think about: One may use `move_toward()` to accelerate and deaccelerate every frame, making it pretty easy to change friction based on the ground/tiles the character is standing on or moving over.
I appreciate the tutorial, but as someone from a programming bg I must say:
You repeat yourself in your code...
Your code at 7:25 can be simplified to:
```
extends KinematicBody2D
const MAX_SPEED = 100
var velocity
func _physics_process(delta):
var input_vector = Vector2()
input_vector.x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left")
input_vector.y = Input.get_action_strength("ui_down") - Input.get_action_strength("ui_up")
if input_vector.length() > 0:
velocity = input_vector.normalized() * delta * MAX_SPEED
else:
velocity = Vector2()
move_and_collide(velocity)
```
When you create a Vector2() object, the default constructor creates an equivalent value to Vector2.ZERO, no need to create a new Vector2 and return Vector2.ZERO:
1. Your conditional statement on line 13 is creating a new Vector2 Object to compare to Vector2.ZERO. You can use .length() method to see if the character is moving diagonally. No need to create a new instance of a Vector2. You're essentially creating a new instance every frame when you don't need to create anything.
2. You don't need to have your input_vector normalized for all cases, or need to calculate arithmetic for all cases except for when movement occurs; so it can be refactored as above.
Will these really make or break performance? For a 2D game, probably not considering how powerful gaming has become, but I think it's best not to repeat yourself.
Thanks for the feedback! Those are good ways to reduce the code down.
However, as a teacher, some of the extra steps/lines are intentional. I'll often split something into multiples lines that could be done in a single step because it is easier for new programmers to follow. Similar to algebra, showing every single step (even if it is a be tedious and unnecessary) is important as people are learning those steps.
Vector2.ZERO vs Vector() is more of a personal preference. I prefer Vector2.ZERO because I think it is more readable but there is a small performance tradeoff there.
That doesn't mean there isn't still room for improvement, I'm sure there is. My code is far from perfect. But I would ask that as you see the steps I take try to filter it through the lens of giving each task its own line to help beginners follow along.
@@uheartbeast Well if it's any consolation, you're still a better game developer. Your tutorial is of the highest quality I've seen so please keep it up!
@@wij8044 Thanks! Glad you are enjoying the videos. I always appreciate when students can take my stuff and improve on it further :)
wow thank you so much!!! i love this u earned a sub, and every video i like it
made so much sense!
wow. I have been coding for a while, but I never really got to learn how to make character controllers (I like to make inventory/stat systems). You explained the concept behind so well! Recently because of Unity’s drama, I feel unsafe with them. I wish they didn’t take this path :/ Unity had such a huge community and their engine is honestly really balanced… Unreal is too heavy on for my PC and Godot seems too “simple” though I am searching about it and it actually seems kind of nice… I love scriptable objects and I heard Godot has “Resources” which is the equivalent and it seems to be even more flexible :D so I will at least start to get to know Godot’s interface, GD scripts, and the nodes :P YK in case Unity trolls their devs again ;-;
Man, i probably couldn't be able to figure out some of these things, like movement with friction\acceleration on my own '~'
Hope it gets more natural with time, thanks for the lessons!
Great is less than you deserve, thanks for the amazing explanation.
customizable tutorial love you bro
Just a note about something that I've just noticed. I'm running Avast AntiVirus and the Safe Save feature of Godot (which according to the description decreases file corruption upon crash) seems to be something of an issue for the antivirus software. If you get an error about lacking permissions to safe save (happens when you launch your game), add Godot as an exception.
As I know, for physic process, delta is the same for each iteration and depends only on the settings. If you pc at some point doesn't able to handle this delta, it will keep the same value in code, but will consume more real time, so game will work slower, and that's how it suppose to work. If physic delta was changing depending on performance, then there would be bugs, like objects goes through each over because of big delta.
But in the (render) _process, delta actually varies depending on performance, because there shouldn't be any physic logic on render, so if it lagging, the game will works the same way, but the player just will see the render of the current state less often.
It's still a good practice to multiply by delta even in the physic process in case you change the settings so the game will still work the same way
Yup that is correct. I guess I wasn't clear enough about that in the video. I do say that delta in the physics process is constant (I was trying to say that it doesn't actually change and should always be 1/60th of a second but I wasn't clear and talked some about delta in general and why we use delta). Overall I think the way I switch between the concept of delta and the actual value of delta in the physics process came off as a bit confusing.
@@redfiend Не обязательно 60, это в настройках проекта задаётся. Физику всю лучше делать только в physic process, но помнить о том, что перегружать его не надо. Собственно process, тоже перегружать не надо. По хорошему вообще никаких проблем с этим возникать не должно, а если возникают, то что-то скорее всего делается не так. Если какие-то сложные периодисеские задачи запускаются в любом из process, то возможно стоит их выносит в поток отдельный, чтоб они ни физику, ни отрисовку не тормозили. Например обдумывание хода икуственным интеллектом
@@redfiend ну, я не знаю как это в годо конкретно делается, не приходилось пока узнавать, просто в различных графических приложениях часто с таким сталкиваешься, что начинает что-то тяжёлое в основном потоке делать и весь интерфейс зависает, потому что ни отрисовка следующая не начнётся, ни ввод не считается.
Фишка integrated forces, несколько я понял, только для rigid body. Он вызывается до physic process, и ты как-бы заранее задаёшь вектора все для своих rigid body, чтобы когда уже полноценно физика начала применяться, они были заданы. В process точно физику не надо отрабатывать, там то, что связано с отображением, типа обновить состояние интерфейса и т.д.. Не парься насчёт того, что physic process забьётся, это прям реально дофига физики нужно одновременно использовать, и то в этом случая перевод всего в process никак не поможет. Либо какие-то оптимизации придумывать, либо уменьшать в настройках частоту физики, если это приемлемо
Max speed doesn't need to be multiplied by delta, since it's just a limit that is being checked for. Please correct me if I'm wrong on that though.
Also, thank you so much for these videos - I'm enjoying them so far!
for those who have an error with the velocity function, replace the string with: velocity = velocity.limit_length(MAX_SPEED * delta)
I had stutter on Windows 11 using in Godot 3.4.4 stable, and setting "Vsync Via Compositor" to true in the Project settings (under General -> Display -> Window) fixed it completely. :)
onto the next one! ;D
Awensome tutorial, I love You so much
Terima kasih, Ben! (Thank you, Ben!) :)
Guys: WATCH THE NEXT VIDEO - He corrects and changes a lot there! For example I was wondering why he multiplies max_speed with delta. Also he shifts to move_and_slide instead of move_and_collide.
I was following, and when I got to the "move_toward" thing, it didn't work, so I had to reinstall Godot in 3.2.2 so it works
PS: Love your vids, hope you make more
Thank you for saying this, I had the same issue with "move_toward()" not being recognized as a function, but I fixed it after reinstalling also
Hi Ben
Thank you for this.
I have a couple of questions
First one
Over what amount of time are you planning to complete this series?
Of course you are doing this free so please don't take it wrong, I'm, by no means, trying to make you feel pressed. Not that I could anyway, but I'm just curious.
The second one
Is the 1-Bit course updated to the latest Godot Version? Are you planning to update it along Godot Updates? Or are you going to make a new one?
I'm asking all this because I have to save a bit to be able to afford it and I want to be sure before I get it.
Hey!
I'm guessing this series will take me a couple months. I'm planning on doing about 3 videos a week (I'll know for sure once I get into the flow of recording and such).
The 1-bit Godot Course was recorded in Godot 3.1 but students are taking it in 3.2 and it is working fine. I'll be making sure the course works on future 3.2 versions as well (with comments and additions in post since I can't re-record the entire series).
Either way learning the basics of how godot works and how many of the different nodes work will carry over into all future iterations of Godot. I learned Godot with Godot 2.1 and I was easily able to pick up Godot 3.x.
Hope this helps! Thanks for the question.
Thank you!
One mistake within your explanation(at least as of Godot 3.3 and onwards) is that a normalized vector isn't clamped to a length of 1(the vector's length is called a magnitude btw). It's always turned into a magnitude 1 vector, whether it's longer or shorter than 1.