I honestly expected the video to start with "A game dev secret about ledge grabbing." with a little bit of fun 8-bit music in the background lol. Honestly really nice tutorial though.
Excellent tutorial! One thought, some general state checking may still be necessary, but my instinct tells me that if the ledge collider were shorter - like half the width of the player and only covering the front, instead of full width and covering front and back - then those split second state-changes when the player turns right as they're grabbing a ledge wouldn't occur in 99% of cases.
I think this technique would also work for 3D platformers too. Pretty cool, thanks for sharing this Swinkly, I wouldn't have thought that a 0 height slightly wider collision box above the player could be used👍
It's cool that you've managed to make it work, but it seems a bit hacky and a perfect place for proper State Machine implementation. This way you don't have to make multiple additional colliders to solve generalized cases (e.g. you need to be grounded to jump), you code exactly how your character acts during this specific state (e.g. character can jump when in ledge_grab state or character's velocity is not changing their position during ledge_grab state).
I definitely agree that this approach could be refined further. That said, it was still way easier to implement than another method I'd previously tried using exclusively raycasts, and for my game project it seems to work pretty seamlessly! And since I'm still fairly new at this is, my main priority is that abilities feel responsive and fun, regardless the method I use to make them work.
Nice video! Not exactly related (could be, though, code architecture is wide) but i think it would be for your benefit to add a "transition time" option for your state changes, in a way which you could cancel transitions c:
Great tutorial! I did something very similar with me ledge grab when I was learning Godot. How did you find learning state machines and states? I've looked at a few tutorials but it seems complicated to be honest or perhaps I'm just over complicating it lol
I looked a few different methods and some of them did feel a little overly complicated for my purposes - the method I used here is literally just an enum with the different states that I use in place of a bunch of booleans, and it was surprisingly easy to figure out! The main difference is figuring out when changes between different states should occur - it gets your brain thinking in a different logical direction.
@@Swinkly_ that sounds like a pretty smart way of working it. Thanks for letting me know. Been really inspiring watching you figure out and learn stuff. Even though I don't comment on your dev logs often I really do enjoy them and the insight you offer plus your honesty about things. God bless :)
I would consider this more of a hack. I don't know the most elegant solution, but it shouldn't include an extra collider with a height of 0. You are already adding lots of code to bypass the problems that arise from this. To my knowledge a better solution would be raycast based. The the problem arises when you want to have an animation from hanging position to idle on top of ledge. You'd have to move the CharacterBody2D manually to a spot and have the animation match the motion. Much easier just to jump or let go from hanging
Hmm, I don't necessarily agree. You say it "shouldn't" use an extra collision shape - but why not? This solution was dozens of times easier to implement and troubleshoot than my previous approach, which used exclusively raycasts. I also don't see how it would be any more complicated to approach the situation you mentioned with this system. If you're just using raycasts, not only do you have to write code to detect the circumstances for the ledge grab, you have write code to stop the player's vertical movement instead of letting the collider do the work. And since the player can move many pixels per frame, you also have to write code which ensures they are correctly aligned with the edge. Then you have to manually write code to inherit the velocity of moving objects instead of having this automatically done for you in Godot's physics. All of the bugs I encountered in this video were also things that had to be solved when I approached the ledge grab using only raycasts, and it was a lot harder that way.
would it not be easier to base the ledge grab state off the ledge grab collision shape? My thinking is that if you had two shapes, one which would check for a wall to grab onto and another one pixel above it that would check for air above the wall you could apply the ledge grab state when the top collision shape isn't in contact with a wall given the other shape is. Would this be more difficult? I don't really know how it would compare with your method since I don't have any experience programming.
I think overall that approach would end up being fairly similar difficulty-wise, but ultimately it comes down to preference and what makes the most sense to you! This solution could definitely be refined further, but I still found it way easier to implement and troubleshoot than just other methods, like using exclusively raycasts.
Just a function I made to execute the jump action if the input is pressed - there's a few other checks it does to ensure the player should be able to jump, so it was easier to separate it into its own function.
Man... Why does every Godot platformer look so floaty? I think I need to try making a platformer without the Godot physics engine. Worst part is, Jolt isn't working in 2D. :/
Believe it or not, the floatiness of a platformer has absolutely nothing to do with Godot's built-in physics and everything to do with how the game's creator tunes their jump. You can make a jump as heavy and precise or as light and floaty as you want in Godot. It's not an engine issue, it's a coding issue.
That's generally not valid. It will negate state before doing the comparison. "not" might work instead of "!" since I suspect (but have not checked) that it's parsed differently.
I wouldn't follow this directly, as it does feel a bit hacky of a method, but I do think it serves as good reference to some for understanding different issues that could come up depending on the way things are done and different ways solutions can be thought out. Also with how it's done here, I would also check attempting to ledge-grab on a moving platform just as it reaches the ground / close enough where you can grab and hit the ground at the same time, and also what might happen if the ledge height is perfect enough where you would enter both the grab and land state to see what takes priority. Plus check the precise inputs issue you had with the moving platform as it moves down, as when it pushes you towards the wall to get towards it, the platform could lower before you update and thus you float in place or float away again.
Good shout on looking into those interactions! I'll do some more testing to see if I can find any bugs. And it does seem that several people find this method hacky, but my main priorities right now are "does it feel good to control?" and "is it fun?" regardless the hacky methods I may use to get there 😅
@@Swinkly_ Yeah that's why I mention I still think it's good reference for ways things can be done, not everything needs to be perfect if it works for what you're doing. And for what it's worth, the current gameplay looks Really smooth, so what you're doing is working.
I honestly expected the video to start with "A game dev secret about ledge grabbing." with a little bit of fun 8-bit music in the background lol. Honestly really nice tutorial though.
Haha, love the Inbound Shovel reference! Glad you enjoyed the tutorial!
"slowly float away from the wall forever"
You: oh a bug
Me: speed run strat
First tutorial? This is great brother, keep it up!
A tutorial that goes through every detail in the process and provide the project files , im tearing up right now ❤
Please keep going like this
Amazing tutorial! I started my game dev journey recently. This will deff come in handy later. Thank yoou for making it!
Liked and subscribed, and not because i needed the tutorial. Its just very well done, and that is what the Godot tutorial scene needs right now
this is such a great video with the pacing and step by step stuff is very informative! hope to see more!
Glad you enjoyed it! Will definitely be doing more tutorials soon!
Great job, I subscribed to your channel because of your shorts on "feel". Looking forward to more longer tutorials!
Excellent tutorial! One thought, some general state checking may still be necessary, but my instinct tells me that if the ledge collider were shorter - like half the width of the player and only covering the front, instead of full width and covering front and back - then those split second state-changes when the player turns right as they're grabbing a ledge wouldn't occur in 99% of cases.
I think this technique would also work for 3D platformers too. Pretty cool, thanks for sharing this Swinkly, I wouldn't have thought that a 0 height slightly wider collision box above the player could be used👍
first tutorial and its a complete banger, thanks for the help!
Ah, state machines. I'll try to keep this in mind for whenever I inevitably try to code a game with (advanced) platforming.
This is neat! i appreciate you going through your thought process!
Great TUTORIAL Thank you very much
It's cool that you've managed to make it work, but it seems a bit hacky and a perfect place for proper State Machine implementation. This way you don't have to make multiple additional colliders to solve generalized cases (e.g. you need to be grounded to jump), you code exactly how your character acts during this specific state (e.g. character can jump when in ledge_grab state or character's velocity is not changing their position during ledge_grab state).
I definitely agree that this approach could be refined further. That said, it was still way easier to implement than another method I'd previously tried using exclusively raycasts, and for my game project it seems to work pretty seamlessly! And since I'm still fairly new at this is, my main priority is that abilities feel responsive and fun, regardless the method I use to make them work.
This is pretty cool!
Could you also make a video on the basics of a character controloer and the other aspects like slide?
Nice video! Not exactly related (could be, though, code architecture is wide) but i think it would be for your benefit to add a "transition time" option for your state changes, in a way which you could cancel transitions c:
super mega W tutorial bro
Great tutorial! I did something very similar with me ledge grab when I was learning Godot. How did you find learning state machines and states? I've looked at a few tutorials but it seems complicated to be honest or perhaps I'm just over complicating it lol
I looked a few different methods and some of them did feel a little overly complicated for my purposes - the method I used here is literally just an enum with the different states that I use in place of a bunch of booleans, and it was surprisingly easy to figure out! The main difference is figuring out when changes between different states should occur - it gets your brain thinking in a different logical direction.
@@Swinkly_ that sounds like a pretty smart way of working it. Thanks for letting me know. Been really inspiring watching you figure out and learn stuff. Even though I don't comment on your dev logs often I really do enjoy them and the insight you offer plus your honesty about things. God bless :)
I would consider this more of a hack. I don't know the most elegant solution, but it shouldn't include an extra collider with a height of 0. You are already adding lots of code to bypass the problems that arise from this. To my knowledge a better solution would be raycast based. The the problem arises when you want to have an animation from hanging position to idle on top of ledge. You'd have to move the CharacterBody2D manually to a spot and have the animation match the motion. Much easier just to jump or let go from hanging
Hmm, I don't necessarily agree. You say it "shouldn't" use an extra collision shape - but why not? This solution was dozens of times easier to implement and troubleshoot than my previous approach, which used exclusively raycasts. I also don't see how it would be any more complicated to approach the situation you mentioned with this system.
If you're just using raycasts, not only do you have to write code to detect the circumstances for the ledge grab, you have write code to stop the player's vertical movement instead of letting the collider do the work. And since the player can move many pixels per frame, you also have to write code which ensures they are correctly aligned with the edge. Then you have to manually write code to inherit the velocity of moving objects instead of having this automatically done for you in Godot's physics. All of the bugs I encountered in this video were also things that had to be solved when I approached the ledge grab using only raycasts, and it was a lot harder that way.
would it not be easier to base the ledge grab state off the ledge grab collision shape? My thinking is that if you had two shapes, one which would check for a wall to grab onto and another one pixel above it that would check for air above the wall you could apply the ledge grab state when the top collision shape isn't in contact with a wall given the other shape is. Would this be more difficult? I don't really know how it would compare with your method since I don't have any experience programming.
I think overall that approach would end up being fairly similar difficulty-wise, but ultimately it comes down to preference and what makes the most sense to you! This solution could definitely be refined further, but I still found it way easier to implement and troubleshoot than just other methods, like using exclusively raycasts.
Nice
Any news about your new art yet ?
The assets are in progress and looking really nice! Might still be a little while before I'm ready to reveal the new look but it's coming!
Alright awesome, great things take time
What is handle jump input?
Just a function I made to execute the jump action if the input is pressed - there's a few other checks it does to ensure the player should be able to jump, so it was easier to separate it into its own function.
@ Thanks
how do I add a slide???????
amazing
Man... Why does every Godot platformer look so floaty? I think I need to try making a platformer without the Godot physics engine. Worst part is, Jolt isn't working in 2D. :/
Believe it or not, the floatiness of a platformer has absolutely nothing to do with Godot's built-in physics and everything to do with how the game's creator tunes their jump. You can make a jump as heavy and precise or as light and floaty as you want in Godot. It's not an engine issue, it's a coding issue.
Why do you use state != instead of !state =?
Just personal preference! To me that feels easier to read.
@@Swinkly_ great tutorial btw super helpful
That's generally not valid. It will negate state before doing the comparison. "not" might work instead of "!" since I suspect (but have not checked) that it's parsed differently.
cool
I having problem in ledgegrabe , i am using node base state matchine ,i dont know how can i share problem, can you help me ,you have discord?
I wouldn't follow this directly, as it does feel a bit hacky of a method, but I do think it serves as good reference to some for understanding different issues that could come up depending on the way things are done and different ways solutions can be thought out.
Also with how it's done here, I would also check attempting to ledge-grab on a moving platform just as it reaches the ground / close enough where you can grab and hit the ground at the same time, and also what might happen if the ledge height is perfect enough where you would enter both the grab and land state to see what takes priority. Plus check the precise inputs issue you had with the moving platform as it moves down, as when it pushes you towards the wall to get towards it, the platform could lower before you update and thus you float in place or float away again.
Good shout on looking into those interactions! I'll do some more testing to see if I can find any bugs. And it does seem that several people find this method hacky, but my main priorities right now are "does it feel good to control?" and "is it fun?" regardless the hacky methods I may use to get there 😅
@@Swinkly_ Yeah that's why I mention I still think it's good reference for ways things can be done, not everything needs to be perfect if it works for what you're doing. And for what it's worth, the current gameplay looks Really smooth, so what you're doing is working.