Update: In the video, I demonstrate that Velocity should be multiplied by delta previous to calling move_and_slide to ensure a consistent speed across varying frame rates. However, it is not required as move_and_slide automatically multiplies Velocity by delta itself. Move_and_collide does expect the provided vector to be multiplied by delta.
Lerp is short for linear interpolation. What you've done here is effectively recreate the exact same behavior that you enabled with the checkbox in the inspector. Adjusting the follow speed is also possible by changing the value directly under that check box. If you truly want a different feel for the interpolation you will have to use a different easing function. Lerp uses linear easing, but you could try cubic, quadratic, etc. Alternatively, you could use a custom curve and adjust it until you are pleased with how it feels. When scripting player movement, my approach is to use linear easing, but code in acceleration and deceleration speeds so that I can precisely tune the curve on either side. If you don't account for this the player goes from a dead stop to a full sprint instantly which is usually not desirable.
Great points! In this video, I was mainly looking to highlight different implementations for camera smoothing, that it could easily be done both through the built-in functionality or through code.
I must say I'm several months into my Godot education and I can create any type of character in my sleep now, but this is actually a really useful and well explained reminder of the fundamentals.
Hi YanislavGalyov, thanks for highlighting this. It is not required as move_and_slide multiplies velocity by delta itself, as you mentioned. This is a bit confusing from the documentation as move_and_collide does expect the provided vector to be multiplied by delta. Delta is not mentioned in regards to move_and_slide. Move_and_slide does use Velocity, which is stated as being pixels per second, though when/how this is enforced is not expanded upon in the documentation. I went ahead and looked at move_and_slide's implementation on GitHub, and move_and_slide does get delta through a singleton reference of the engine checking if it is currently in a physics frame, though has a comment noting that it's a bit of a hack. Regardless, move_and_slide does not require the Velocity to be multiplied by delta, though move_and_collide does.
Absolutely! As you're still primarily moving in the x and y axes, these concepts should still be applicable. It it makes sense for your game mechanics, you could add a fifth action for jumping (if there are obstacles to move over, for instance). I would still handle that in the HandleInput method. For a 3D top down game, you could also rename "up" to "forward", and "down" to "backward" if you would like. The camera following could become a bit more complicated depending on where you would like the camera to be / how you would like it to behave, though conceptually it should be similar. Let me know if that answered your question or if you have any others!
Great video, thank you! I'd like my 2D character to... (1) rotate/face using the mouse (2) W/S moves the player forward/backwards, based on the facing direction (3) A/D strafes the player left/right, perpendicular (90 degrees) to the facing direction I've solved 1 & 2, but cant figure out how to do #3, any help would be appreciated my code... look_at(get_global_mouse_position()) # mouse controls facing (rotation) direction velocity = transform.x * Input.get_axis("down", "up") * speed # W/S moves the player forward/back based on the facing direction
Hey @Mr.TummyOfClanTummy! This should work for you: extends CharacterBody2D var speed = 400 func _physics_process(delta): look_at(get_global_mouse_position()) var move_forward = Input.get_axis("down", "up") var move_sideways = Input.get_axis("left", "right") velocity = ((transform.x * move_forward) + (transform.y * move_sideways)) * speed move_and_slide() The parentheses are important due to PEMDAS, haha. If you remove the outer parentheses, only move_sideways would be multiplied by speed, so that can cause some unexpected behavior. Let me know if this is not the behavior you were looking for. Hope this helps!
Update: In the video, I demonstrate that Velocity should be multiplied by delta previous to calling move_and_slide to ensure a consistent speed across varying frame rates. However, it is not required as move_and_slide automatically multiplies Velocity by delta itself. Move_and_collide does expect the provided vector to be multiplied by delta.
Really good tutorial. This is great for beginners to get their head around Godot. Definitely subscribing and checking out more of your videos.
Thank you very much, cradledani!
Lerp is short for linear interpolation. What you've done here is effectively recreate the exact same behavior that you enabled with the checkbox in the inspector. Adjusting the follow speed is also possible by changing the value directly under that check box. If you truly want a different feel for the interpolation you will have to use a different easing function. Lerp uses linear easing, but you could try cubic, quadratic, etc. Alternatively, you could use a custom curve and adjust it until you are pleased with how it feels. When scripting player movement, my approach is to use linear easing, but code in acceleration and deceleration speeds so that I can precisely tune the curve on either side. If you don't account for this the player goes from a dead stop to a full sprint instantly which is usually not desirable.
Great points! In this video, I was mainly looking to highlight different implementations for camera smoothing, that it could easily be done both through the built-in functionality or through code.
I really like your presentation. Thanks for the tuts.
Thank you for watching and for the feedback!
I must say I'm several months into my Godot education and I can create any type of character in my sleep now, but this is actually a really useful and well explained reminder of the fundamentals.
Thanks, good tutorial
Thank you!
why do you multiply the Velocity with delta when MoveAndSlide method takes care of this?
Hi YanislavGalyov, thanks for highlighting this. It is not required as move_and_slide multiplies velocity by delta itself, as you mentioned. This is a bit confusing from the documentation as move_and_collide does expect the provided vector to be multiplied by delta. Delta is not mentioned in regards to move_and_slide. Move_and_slide does use Velocity, which is stated as being pixels per second, though when/how this is enforced is not expanded upon in the documentation. I went ahead and looked at move_and_slide's implementation on GitHub, and move_and_slide does get delta through a singleton reference of the engine checking if it is currently in a physics frame, though has a comment noting that it's a bit of a hack. Regardless, move_and_slide does not require the Velocity to be multiplied by delta, though move_and_collide does.
Can I apply these fundamentals to 3d top down movement. Since in theory it would be kinda similar right? (move up down right left)
Absolutely! As you're still primarily moving in the x and y axes, these concepts should still be applicable. It it makes sense for your game mechanics, you could add a fifth action for jumping (if there are obstacles to move over, for instance). I would still handle that in the HandleInput method. For a 3D top down game, you could also rename "up" to "forward", and "down" to "backward" if you would like. The camera following could become a bit more complicated depending on where you would like the camera to be / how you would like it to behave, though conceptually it should be similar. Let me know if that answered your question or if you have any others!
@@TundraFeedandSupplyCo Thank for answering! No question for now, I need to somehow applies these concepts first.
Great video, thank you! I'd like my 2D character to...
(1) rotate/face using the mouse
(2) W/S moves the player forward/backwards, based on the facing direction
(3) A/D strafes the player left/right, perpendicular (90 degrees) to the facing direction
I've solved 1 & 2, but cant figure out how to do #3, any help would be appreciated
my code...
look_at(get_global_mouse_position()) # mouse controls facing (rotation) direction
velocity = transform.x * Input.get_axis("down", "up") * speed # W/S moves the player forward/back based on the facing direction
Hey @Mr.TummyOfClanTummy! This should work for you:
extends CharacterBody2D
var speed = 400
func _physics_process(delta):
look_at(get_global_mouse_position())
var move_forward = Input.get_axis("down", "up")
var move_sideways = Input.get_axis("left", "right")
velocity = ((transform.x * move_forward) + (transform.y * move_sideways)) * speed
move_and_slide()
The parentheses are important due to PEMDAS, haha. If you remove the outer parentheses, only move_sideways would be multiplied by speed, so that can cause some unexpected behavior.
Let me know if this is not the behavior you were looking for. Hope this helps!
@@TundraFeedandSupplyCo Huge thank you!!!