Also if your game has complex combat or a ton of different special abilities and actions, consider using an action queuing system instead of a state machine! It's way easier to manage
Same question here. Would I apply individual actions from a queue (depending on the current state) instead of having conditions for all actions? But how would that be an alternative to a state machine?
A big thing with these is they are all worthless if you don't design levels with them in mind. Getting Over It controls horribly, but is learnable and designed the world around it offsetting the issues. Celeste is a great example of how to design a world with good mechanics in mind. The jumps are often big because of the combination of Dashing and Coyote time which makes a wonderful experience for jumping over stuff while holding down to fast fall can help let you make things more floaty for mid-air control at base while giving an ability to snap down faster when needed. So don't just put these mechanics into your game when it is done, design your game with these mechanics in mind.
This is absolutely amazing. I added delayed jump and coyote time within about 15 minutes and it was so much easier to implement than I had thought, the dead jump presses were really annoying before. Now it's a difference of day and night and it put a big fat smile on my face. I heard of coyote time before but haven't considered how easy it would be to implement. Thank you so much for this video. I'm going to try out your other suggestions but these two were a real quick change that improved the feel of my game loop a ton. Thank you!
Another great thing to add is some form of momentum to your running! I’m not talking classic sonic style momentum, I mean like 2D Mario, how if you hold down the run button and keep going forward you’ll change into a few different running states. Some games may not need it but I enjoy having momentum
@@Onaterdemthey do sound really similar, really the only difference aside from the speed values, traction, etc. is that SMB's is changed with the run button.
@@Onaterdem well yeah but Mario and Sonic momentum are different in ways. You hold the run button to build up speed and Mario can’t go fast enough to run loops
@@PLAYER42_ready Hmm well holding down the run button is like holding down the forward button with extra steps, so it's still the same in that regard. The max speed is just an easily changeable variable.
A lot of people give a lot of advice (and I'll always be thankful to ANYONE trying to share), but I can absolutely tell from the way you talk, explain, showcase, etc, that you know what you're talking about. You have that unknown "thing" that people say is what it takes to succeed in various fields, and you have it here. Hope to learn more from you moving forward, keep it up!
I know the thing that you mean gem fruit, but don't be fooled! There is no secret sauce. All it takes is introspection, constructive self criticism, and the drive to better oneself. From there, you can become a master at anything. It all takes hard work!
Dude this is insane, thank you so much for this. I'm using Game Maker Studio v1.4.9999, which isn't available anymore, but the concepts were VERY helpful. Especially that toolkit! Thanks!
There’s also a pragmatic argument for features like coyote time and jump buffers. The idea of any game is to put a player in the shoes of the character they’re playing as. In real life, you would never mistime a jump because you can physically feel the ground beneath your feet and know exactly when to jump again. When you’re running to jump off a ledge in real life, you can pace yourself and make sure your feet are in the right position to give yourself the optimal distance. In games, obviously, none of that is available to the player, so concessions need to be made to bridge that gap. I’d encourage everyone to use these tips, but also experiment with new ways to achieve the same (or possibly even better) results. You never know what you’ll discover by just playing around and trying things out.
Reaction time of a human is 300 ms. Especially feeling what is under your foot takes all the 2 m of nerve signal through your body and may even be slower than seeing? Anyway, I accept this explanation for jump buffers, and demand that they are also used while running. So running gets a "take a swing" animation, which will instantly become a jump the moment you pass over a ledge? Why is a ledge more important than jumping over oncoming opponents?
@@ArneChristianRosenfeldt Enemies often have a smaller hurtbox than it looks like for just that reason. That way the game is a little more lenient when it comes to dodging them. The same can also apply to your attacks but in the opposite direction where your hitbox is larger than the attack looks like so it is easier to hit enemies than it looks. Coyote time and some ways that games may nudge you a bit in certain directions or making your hitbox a bit smaller at times can be used to help you with jump precision when running. Also the jump buffer thing I would say is more about registering the intent of the player rather than about reaction time concerns. Without it they can't time a jump close to the landing without running the risk of missing the window for it by as little as a single frame. Then it will take a fair bit of time before they notice and can press the button again. By using the jump buffer you make it a little easier to time it right.
Just gotten back into gamedev after a few years out and your videos have been invaluable in getting me back up to speed! Props for including some footage of Dustforce. Some of the best platforming controls of any game I've played.
This is an awesome video with great production and pacing, and and the code examples have to be a huge help to anyone programming their own platformer from scratch! This video is drastically underviewed-but I got recommended it without having heard of your channel before, so hopefully the algorithm is at least thinking about blessing your channel :)
For the custom jump function you mentioned, thank you so much for actually showing some examples. As you said, it would be lazy to just punt us to another video and leave it at that. I agree that the GDC talk on the mathematics behind jumps is a really good resource, but it also takes a pretty long time to get through it. You did amazing by actually taking the time to showcase a custom jump function!
Good video. While most of these tips are mentioned in other GDC talks, I think they are definitely worth repeating. Also, thanks for including sources in the description.
My current game isn't a platformer but this video was awesome anyway. Love the ideas about giving players a little bit of leeway to avoid frustration and keep things fun. I think some of these concepts can be applied to other types of games for sure
Great video, I'm going to use this as a reference. I'm working on platforming mechanics for my next game, this new information makes me excited to work on that. I see why you'd use a timer instead a raycast for a jump buffer. Timing is much more consistent, especially at high speeds where collision gets funky. Consistency is so important. Also something I'd like to add to the idea of manipulating the players velocity mid-jump, this is also very useful for double jumps, slow falls or any ability that pops you up or stabilizes your momentum.
This is a great video! If you're wondering about using rigid body physics for a platforming player controller it's totally doable, but don't expect to be able to get a really nice feeling system without knowing how the physics works and understanding the physics behind what you want to accomplish (moving platforms are a great example of something that's nearly impossible to get right with a rigid body unless you fully understand what it is you want to happen) I think the results can absolutely be worth the struggle though, you can get some incredible interactions with other physical objects that just wouldn't work without a properly simulated player. There's a reason why almost all platformers go the Kinematic path though, being able to fully control all the aspects of your player makes everything much simpler.
One example that I see of people having trouble with rigid body's is on slopes, it's because the idea that a running person (or robot or hedgehog or whatever) can be represented as a single rigid shape starts to break down in a case like this. It's intuitive to us that a person should have little difficulty running up a slope (like it literally takes more energy but platforming characters tend to ignore stamina) but in order to do that in a way we expect we have to things like rotating the player to match the slopes orientation, which is actually usually too much rotation visually but it works in a cartoony style. Even then the large increase in friction from pushing against the surface while it goes away from the direction of gravity is hard to account for in a pleasant way, especially if you want the speed up and down the slope to not be very different. The solution imo is to not actually slide the player along the ground, what you really should be simulating is the feet moving underneath the player at their intended running speed, while the feet are in contact with the ground they should be imparting force to the players rigid body (through a physics constraint of some kind, most physics simulations have these, hopefully they are capable enough to deal with a situation like this) and interacting with the ground by way of friction. This is obviously pretty tough to do, compared with switching to a kinematic system, but it's not like you really need to simulate the players legs as well or match their feet positions to where it looks like their feet are. so you can still have full control of the "feet" bodies and the constraints between them and the player. So yeah slopes are really hard for a rigid body player, because without them you can sometimes get away with making the player one solid rigid object that just slides around. Also there could be a more simple way to emulate the feel of running up and down a slope than with separate bodies for feet, For example I've played around with using friction to drive tanks in 3D by simply modifying the physics system to let me add a specific amount of velocity to the friction calculation specifically, so I could make the tread surfaces behave in a physically accurate way and it worked like a charm, even though the physics I was using was never built to accommodate that.
It occurs to me now that one very quick thing to try for a rigid body player on a slope is to modify their gravity vector to be closer to the direction of the slope, you could even potentially make the effect fall off for steeper slopes to get gradually less traversable slopes in a pretty smooth way (you wouldn't want that for games where you can run up slopes onto walls though hehe)
I use rigidbodies and they work great. I used the tip with reducing velocity when releasing jump button. I love it! In my case i only reduce the velocity by 20% but it makes huge difference.
Dude, this is amazing material you have there, please, continue releasing videos like that. It stands out from the rest of things here on youtube. Saw your video twice and also, I am grateful that you have written version of it 👏Have a nice and a lot of success o/
That's a pretty good example of what game designers have to come up with in their work, i.e. what game design is all about. People think game design is about large scale ideas, when in fact the things described in this video are the type of stuff game designers need to put tons of time and effort, sweat and tears into figuring out on every game they make.
Umm, the first tip really depends on how you are doing things. I've been making a sidescrolling 2D/2.5D metroidvania controller in Unity (using 3D assets) and I am using a Rigidbody, I simply use a Physics material with no friction which prevents him from getting stuck on walls or ledges/corners (he slides off everything), while keeping the benefit of being pushed/shoved by other rigidbodies (and I increase gravity a lot to make falling more satisfying/less floaty). I also use a time threshold for my input polling (ie: when I need to, my Input manager can check if a button was pressed/released within a specific time threshold. This is a godsend for combos and when the player presses buttons too soon or too late).
Lovely video! Really easy to watch with great ideas that I'm planning to implement now! I just opened godot for the first time last week and starting making a 2D platformer so this was an ideal watch for me!
I agree with others - massively under appreciated video. I wanna say man, your methodology here of placing personal ideation and creativity at the top, and not leading others to simply copy what you did, is a million times more valuable in my opinion. No wonder it is under appreciated, most people want the work done for them. Well, I thought it was really good and I hope that means something. Off to start my journey, thank you!
Ive come here after watching your state pattern video. One important thing is that if you can enter the fall state after initiating the jump state, coyote will not work this way. The timer gets reset all the time, meaning that the player always has a timeframe where they can jump mid-air. So the easy solution is to not enter the fall state after jumping (which for most games isnt necessary I suppose?)
Good point! And if you need to enter fall state after jump state, you may want to start passing data between states, such as what the last state was, that way you can make sure you only start the timer if you come from a ground state. Can also do things like track when the player was last on the ground, etc.
I like that you refer to so much other videos who talk about in in death instead of just trying to put everything into one video which would just be a compilation helping no one
4:00 This one is more obvious that it can get used for speedrunners (It literally is more jump options), however there is a cool tidbit I want to mention! In Red Ball 1 (Idk about the rest of the series), you can actually release jump, so you start falling sooner, then repress it! This actually has an impact, making input sequences like this possible: Jump, nothing, jump, nothing, nothing, jump
One thing I'm adding to my game is smash-style fast-falling. So the player can press the down button to fall faster. I think this is more relevant to action games that include air combat and an air moveset that's different from the ground.
Unrelated question but what was the third game shown in the intro? It looks really good (sorry if it’s a very well known game and I’m about to get clowned on for not knowing it)
Jump Buffering is the most important in my opinion, I've found myself sometimes playing games without it (Namely obscure online indie games), And it's often very easily notiçable, Especially if you have long segments which require the player to jump quickly after touching the ground. A while ago I was playing a game with a few jumps that were far harder than they should've been, because if you hit jump too early, you don't jump because there's no buffering, but if you hit jump too late, you'll slide off the platform, and if you try to stop on the platform, you lose momentum necessary for the jump.
Great video. Recently played through Ducktales Remastered, and holy shit, I'm now realizing why I hated the platforming so much in that game. Especially that it hasn't implemented any form of "Push off ledges", so your character is stopped jumping upwards near edges all the time. Also, I think the character hitbox is larger than one tile gap, or very close to it, which makes this even worse.
Been trying to figure out how the make my platformer's controls feel as good as Super Mario World (In my opinion, no platformer comes closer to SMW when it comes to controls), so this video is very useful to me. Thanks for the code examples.
Yeah, Super Mario World really nailed it in a way few games have been able to emulate. Kind of crazy how ~30 years later it still controls better than most. Thanks for watching!
I have a small one that personally bothers me in games, but it basically only matters on a keyboard. (seriously, pet peeve stuff here) When pressing Left & Right (A/D) at the same time, they should null each other out and my character shouldn't move. This goes for ALL games. 2D, 3D, Indie, AAA. I tend to do this by taking the pressed input values, or use the bools as 0-1, then take one from the other and use this value in my move code. In Godot 3.5 for example, I do: inputDirection = Input.is_action_pressed("MoveRight") as int - Input.is_action_pressed("MoveLeft") as int So, Holding D: inputDirection = 1 - 0 = 1 Holding A: inputDirection = 0 - 1 = -1 Holding Both: inputDirection = 1 - 1 = 0 Holding Neither: inputDirection = 0 - 0 = 0
Starting to learn godot at the moment, and my goal is to create a movement system that mimics megaman x, likely around x4-6. Really want to make something fun like those games, and movement systems seems a good start as any!
but ... setting the velocity IS using a rigidbody 🤔 or is he just tranlating a vector. and if he's moving colliders as well, isn't he paying the cost of physic sync?
Excellent video. Curious about that BaseState machines you got going on there! (Godot total beginner over here) EDIT: never mind, just saw you got a video on EXACTLY that. Subbing :)
i mean jumps are cool and all, but what about the ground movement? i thought i could implement a super mario 3 or world run with P speed, but it's surprisingly difficult to figure out.
Coyote time sucks if you design jumps to require using it. It really annoys me when games make it so that the only way you can make a jump is to literally fall off the ledge before pressing the jump button. It should be there to catch millisecond mistakes, not a feature of level design
1. yeah i use gamemaker, idk what a rigid body is 2. why not just check if player is pressing the jump button when he touches the floor that way the player can hold the jump for repeated jumps rather than need to learn the precise timing or you to code away their precise timing 3. thats what id do to although i think coyote timing is overhyped tbh 4. interesing ill try increasing gravity on fall ty for the idea! 5. yeah good shizz
Don't use rigidbodies huh. Never heard that one before, but i am finding myself fighting with the rb a lot in one of my projects. I just assumed getting collisions to work with high velocities would be too buggy if i coded that myself tho.
Game devs seem to add random forces to a rigid body and wonder why the simulation wreck havocs on their level design. Has anyone tried to just run animations, like running or extending the legs of the figure? With the correct friction and in 2d this might work. And put a constraint on rotation ( but Sonic on slopes?) . Oh we may need some up vector logic.
Been trying to recreate sonic in pygame for my nephew. Got the momentum working nicely but the balancing the jumping and collisions with undulating ground tiles is a real issue.
These are some great recommendations. I'm trying to implement the "ledge push" in my project right now on Unreal. I am totally with you on the raycast part, but you glossed over the 'slide' function pretty quickly. What is the method that you use to move your character over if a ledge is detected? I know you're not using Unreal, but I'm just trying to figure out the general idea so i can translate it.
In this example, I just change the position of the object by the appropriate amount the same frame it's detected. A little crude, but should be ok if we're just doing a small amount of pushing
There are exceptions to everything, including using rigidbodies. They can, of course, be used for a game, but it's easy to end up fighting the physics with them if you're going for a more traditional style platformer. That's all I'm getting at here.
@@TheShaggyDev And fighting the physics does indeed happen for a few specific jumps and other areas of the game. I was just wondering if you had any knowledge of the game's behavior in general due to how it handled things. And thank you for this wonderful video!
Kind of a combination of coyote time and the raycast snapping, but sometimes it’s frustrating to think you made it to a platform, only to “stub your toe” and start falling. Super Mario Bros., for example, even let’s you run across short gaps if you’re moving fast enough.
2:45 Another one that gets abused by Speedrunners XD 1. In SMB1 (yes this one is in a 1985 game lol), this can be used to go farther to the right side of the screen. However, this is not actually useful anywhere. 2. In SMM2 (Super Mario Maker 2), people actually use this to jump with good timing and get a couple-pixel boost!
Thanks! It's an old flash game named Geote, so not directly playable these days but I just discovered that Flashpoint has it archived and it seems to be more or less playable! flashpointproject.github.io/flashpoint-database/search/#29cd3cb3-13f7-442d-8ab4-fb60fac5200f
I will say I think it'd be better to do the delta time subtraction for the buffer feature in the physics process. While the variable is initially modified by an input, the importance of its update is tied to the physics engine. If you end up with graphics lagging behind or freezing, you will end up in a situation where in _physics_process the engine thinks the input is still buffered when really it shouldn't. An edge case for sure, but still worth the consideration. Hell you COULD intentionally leave it in _process if you think it's more beneficial for a player who'd get a freeze mid jump to jump again during the freeze if they press jump again. The same obviously goes for coyote time with the caveat that I would recommend against intentionally putting it in _process. Sure if the player gets a freeze mid coyote time that means they may die (though theoretically no as input should still arrive at the proper time but let's keep a worst case scenario in mind), but if you keep it in process and they end up being able to coyote time super late in the fall (which will be visible once the game unfreeze) they will feel cheap, which is worse. For the edge snapping it would warrant testing but I have an idea that may simplify it. Put two rays (one on each side) x away from the character center (x being the max snapping distance). Also put a fairly small box detector above the player's head. If a wall is in that box and the ray doesn't hit, move the player away and snap them back towards the wall. If both ray don't hit, then cast a new ray at the top of both "snap rays" towards the symmetry line of the player, whichever has the longest collision distance is the one you want to pick. Should be pretty efficient regardless of whether you use a tileset based map or not.
I wonder how some of these techniques would translate well to 3D jump n Run, like coyote time I bet the player won't wait for the perfect perfect moment based on the perspective
but going away from physics means you can't easily add things like ice, wind, weight, knockback, momentum. Getting stuck on walls should be trivial to fix in comparison. I am currently trying to tackle this problem for my game and I ll go with a physics approach but give the forces extra power to make the player feel responsive enough.
Changing the shape of the collision box may have other undesired impacts, as you don't want the character to be unfairly hit by something or to appear to be floating off a cliff if the player stops on the edge. Managing a simple timer on a character is very low overhead and not something I'd be worried about in regards to performance.
I'm trying to do the raycast snap for my game. The left corner snaps fine but when I hit the right corner, all 4 raycasts mark true meaning the player doesn't move around the edge. When this happens, what should I be looking for?
@@TheShaggyDev Sorry, i forget about it. Well, so I will just ask for some way to implement a slope movement in the state machine, I get confused about how to put it inside my player with a state machine, I dont found any tutorial who helps in this case.
@@G69G71 Ahh I see. You shouldn't need a state machine for that. Move and Slide can already keep you attached to a slope, then the speed can be adjusted appropriately, though I'm afraid I don't have a resource handy for how to do that. Can probably find more if you search around for slope movement in Godot.
what about fix the slope problem? like stoping the player when is on slope, this will be helpful in the game, do you know one way to fix that in state machine?
In Godot, the move_and_slide function has parameters for handling stopping on a slope. No need to modify the state machine: docs.godotengine.org/en/stable/classes/class_kinematicbody2d.html?highlight=kinematicbody2d#class-kinematicbody2d-method-move-and-slide
@@G69G71 Double check the up_direction parameter and the max slope angle. If that doesn't fix it, could check out some other resources on that specific issue and see if that helps. PigDev has done a video on slopes, for instance: ruclips.net/video/9l-tf97z2bg/видео.html
@@G69G71 With the disclaimer that I've not implemented the PidDev technique myself, it looks like you'd just put it in the MoveState since he's working with the move_and_slide_with_snap function And yes, I don't see any reason why this wouldn't work in 3.5
Do you have any tips for making a 2D platformer in Unity? Unity doesn't have a great simple physics component for 2D, like its 3D character controller. It's one of the big reason why I prefer Godot, actually, because it has a 2D kinematic body, as well as 2D counterparts for basically everything, and far better 2D support in general.
I'm afraid I can't help you too much there. I've not done a 2D platformer in Unity so while I've got some ideas, you'd be better served finding a Unity oriented channel to help. The general concepts from this video would still apply though. Coyote time, jump buffering, etc are all engine agnostic.
Ive seen some people say before that rigid bodies arent good. But I cant really find anyone explaining how to make a 2d character without them. Like, what do I do???
It depends on your engine. Most engines have some sort of simpler / faster physics implementation than a rigid body that you can use. And if your engine doesn't offer an alternative, rigid bodies can work too! It just may be more work to get it to feel right.
The code in this video is built upon my state machine series, which is where BaseState comes from. I've got a few videos on state machines if you'd like to learn about them and build the same machine I use here (can skip the Godot 3 videos if you're not on 3, though that's what was out when I made this video): ruclips.net/p/PLaiU9HSaKMWtmAIR345HGIz_ijQiyr3kH
Most likely it's because we can always jump when entering the fall state, and the jump state probably transitions into the fall state in your game, which has happened to me before as well. What I like to do for edge cases like that, is start passing a little bit of data into the state on change. For instance, if we pass in a reference to the previous state in our "State.enter()" function, we can only allow coyote jumping if we didn't come from a jump state.
Input buffer for jumping is a must. However, coyote time and displacing the char a bit when jumping against a ledge, although very adviceable, they are not present in some well known games such as Hollow knight (which i find a fine game, but not as good as all the hype says)
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
Also if your game has complex combat or a ton of different special abilities and actions, consider using an action queuing system instead of a state machine! It's way easier to manage
Excellent suggestion!
Hi sorry to bother but what exactly is an action queueing system?
Same question here. Would I apply individual actions from a queue (depending on the current state) instead of having conditions for all actions? But how would that be an alternative to a state machine?
@@michasengotta2295 its basically queuing inputs, of course you can use state machine but its simpler to queue inputs into an array
@@stan7132 I still don't understand how queuing input has anything to do with the way that state is stored or transitions are handled.
A big thing with these is they are all worthless if you don't design levels with them in mind.
Getting Over It controls horribly, but is learnable and designed the world around it offsetting the issues. Celeste is a great example of how to design a world with good mechanics in mind. The jumps are often big because of the combination of Dashing and Coyote time which makes a wonderful experience for jumping over stuff while holding down to fast fall can help let you make things more floaty for mid-air control at base while giving an ability to snap down faster when needed.
So don't just put these mechanics into your game when it is done, design your game with these mechanics in mind.
This is absolutely amazing. I added delayed jump and coyote time within about 15 minutes and it was so much easier to implement than I had thought, the dead jump presses were really annoying before. Now it's a difference of day and night and it put a big fat smile on my face. I heard of coyote time before but haven't considered how easy it would be to implement. Thank you so much for this video. I'm going to try out your other suggestions but these two were a real quick change that improved the feel of my game loop a ton. Thank you!
What if the jump button extends your legs and you let physics do the rest. At least the button will feel alive thanks to the animation.
Another great thing to add is some form of momentum to your running! I’m not talking classic sonic style momentum, I mean like 2D Mario, how if you hold down the run button and keep going forward you’ll change into a few different running states. Some games may not need it but I enjoy having momentum
Wait... Isn't what you're describing _exactly like_ Classic Sonic momentum?
@@Onaterdemthey do sound really similar, really the only difference aside from the speed values, traction, etc. is that SMB's is changed with the run button.
@@Onaterdem well yeah but Mario and Sonic momentum are different in ways. You hold the run button to build up speed and Mario can’t go fast enough to run loops
@@PLAYER42_ready Hmm well holding down the run button is like holding down the forward button with extra steps, so it's still the same in that regard. The max speed is just an easily changeable variable.
A lot of people give a lot of advice (and I'll always be thankful to ANYONE trying to share), but I can absolutely tell from the way you talk, explain, showcase, etc, that you know what you're talking about. You have that unknown "thing" that people say is what it takes to succeed in various fields, and you have it here. Hope to learn more from you moving forward, keep it up!
Thank you! That's really kind. I'm just trying to be helpful 😅
I know the thing that you mean gem fruit, but don't be fooled! There is no secret sauce. All it takes is introspection, constructive self criticism, and the drive to better oneself. From there, you can become a master at anything. It all takes hard work!
Dude this is insane, thank you so much for this. I'm using Game Maker Studio v1.4.9999, which isn't available anymore, but the concepts were VERY helpful. Especially that toolkit! Thanks!
The other day I learned the script just for the player movement in Celeste is over 5700 lines. Fuckin wild
There’s also a pragmatic argument for features like coyote time and jump buffers. The idea of any game is to put a player in the shoes of the character they’re playing as. In real life, you would never mistime a jump because you can physically feel the ground beneath your feet and know exactly when to jump again. When you’re running to jump off a ledge in real life, you can pace yourself and make sure your feet are in the right position to give yourself the optimal distance. In games, obviously, none of that is available to the player, so concessions need to be made to bridge that gap. I’d encourage everyone to use these tips, but also experiment with new ways to achieve the same (or possibly even better) results. You never know what you’ll discover by just playing around and trying things out.
Reaction time of a human is 300 ms. Especially feeling what is under your foot takes all the 2 m of nerve signal through your body and may even be slower than seeing? Anyway, I accept this explanation for jump buffers, and demand that they are also used while running. So running gets a "take a swing" animation, which will instantly become a jump the moment you pass over a ledge? Why is a ledge more important than jumping over oncoming opponents?
@@ArneChristianRosenfeldt Enemies often have a smaller hurtbox than it looks like for just that reason. That way the game is a little more lenient when it comes to dodging them. The same can also apply to your attacks but in the opposite direction where your hitbox is larger than the attack looks like so it is easier to hit enemies than it looks.
Coyote time and some ways that games may nudge you a bit in certain directions or making your hitbox a bit smaller at times can be used to help you with jump precision when running.
Also the jump buffer thing I would say is more about registering the intent of the player rather than about reaction time concerns. Without it they can't time a jump close to the landing without running the risk of missing the window for it by as little as a single frame. Then it will take a fair bit of time before they notice and can press the button again. By using the jump buffer you make it a little easier to time it right.
Just gotten back into gamedev after a few years out and your videos have been invaluable in getting me back up to speed! Props for including some footage of Dustforce. Some of the best platforming controls of any game I've played.
This is an awesome video with great production and pacing, and and the code examples have to be a huge help to anyone programming their own platformer from scratch! This video is drastically underviewed-but I got recommended it without having heard of your channel before, so hopefully the algorithm is at least thinking about blessing your channel :)
Thank you!! Never know what the algorithm is going to do, so we can hope!
This is a perfect video to send to idea guys, when they say "when you press this button it jumps", having no idea of everything that goes behind it
For the custom jump function you mentioned, thank you so much for actually showing some examples. As you said, it would be lazy to just punt us to another video and leave it at that. I agree that the GDC talk on the mathematics behind jumps is a really good resource, but it also takes a pretty long time to get through it. You did amazing by actually taking the time to showcase a custom jump function!
This info is gold, ty!
Wow... so much value packed into one video!! Thank you!
The good stuff, Shaggy the GOAT at it again
Hahaha, thanks! Always nice to have fans 😅
Good video. While most of these tips are mentioned in other GDC talks, I think they are definitely worth repeating. Also, thanks for including sources in the description.
My current game isn't a platformer but this video was awesome anyway. Love the ideas about giving players a little bit of leeway to avoid frustration and keep things fun. I think some of these concepts can be applied to other types of games for sure
It's a great summary, very concise and even with some programming tips. Solid :)
I never even thought of buffering the jump, that's great.
Great video, I'm going to use this as a reference. I'm working on platforming mechanics for my next game, this new information makes me excited to work on that.
I see why you'd use a timer instead a raycast for a jump buffer. Timing is much more consistent, especially at high speeds where collision gets funky. Consistency is so important.
Also something I'd like to add to the idea of manipulating the players velocity mid-jump, this is also very useful for double jumps, slow falls or any ability that pops you up or stabilizes your momentum.
This is a great video! If you're wondering about using rigid body physics for a platforming player controller it's totally doable, but don't expect to be able to get a really nice feeling system without knowing how the physics works and understanding the physics behind what you want to accomplish (moving platforms are a great example of something that's nearly impossible to get right with a rigid body unless you fully understand what it is you want to happen)
I think the results can absolutely be worth the struggle though, you can get some incredible interactions with other physical objects that just wouldn't work without a properly simulated player.
There's a reason why almost all platformers go the Kinematic path though, being able to fully control all the aspects of your player makes everything much simpler.
One example that I see of people having trouble with rigid body's is on slopes, it's because the idea that a running person (or robot or hedgehog or whatever) can be represented as a single rigid shape starts to break down in a case like this. It's intuitive to us that a person should have little difficulty running up a slope (like it literally takes more energy but platforming characters tend to ignore stamina) but in order to do that in a way we expect we have to things like rotating the player to match the slopes orientation, which is actually usually too much rotation visually but it works in a cartoony style. Even then the large increase in friction from pushing against the surface while it goes away from the direction of gravity is hard to account for in a pleasant way, especially if you want the speed up and down the slope to not be very different.
The solution imo is to not actually slide the player along the ground, what you really should be simulating is the feet moving underneath the player at their intended running speed, while the feet are in contact with the ground they should be imparting force to the players rigid body (through a physics constraint of some kind, most physics simulations have these, hopefully they are capable enough to deal with a situation like this) and interacting with the ground by way of friction. This is obviously pretty tough to do, compared with switching to a kinematic system, but it's not like you really need to simulate the players legs as well or match their feet positions to where it looks like their feet are. so you can still have full control of the "feet" bodies and the constraints between them and the player.
So yeah slopes are really hard for a rigid body player, because without them you can sometimes get away with making the player one solid rigid object that just slides around.
Also there could be a more simple way to emulate the feel of running up and down a slope than with separate bodies for feet, For example I've played around with using friction to drive tanks in 3D by simply modifying the physics system to let me add a specific amount of velocity to the friction calculation specifically, so I could make the tread surfaces behave in a physically accurate way and it worked like a charm, even though the physics I was using was never built to accommodate that.
It occurs to me now that one very quick thing to try for a rigid body player on a slope is to modify their gravity vector to be closer to the direction of the slope, you could even potentially make the effect fall off for steeper slopes to get gradually less traversable slopes in a pretty smooth way (you wouldn't want that for games where you can run up slopes onto walls though hehe)
I use rigidbodies and they work great.
I used the tip with reducing velocity when releasing jump button. I love it! In my case i only reduce the velocity by 20% but it makes huge difference.
Dude, this is amazing material you have there, please, continue releasing videos like that. It stands out from the rest of things here on youtube. Saw your video twice and also, I am grateful that you have written version of it 👏Have a nice and a lot of success o/
That's a pretty good example of what game designers have to come up with in their work, i.e. what game design is all about. People think game design is about large scale ideas, when in fact the things described in this video are the type of stuff game designers need to put tons of time and effort, sweat and tears into figuring out on every game they make.
Thanks for this! Some of these things seem pretty advanced for my limited coding knowledge, but it’s helpful anyways :)
Umm, the first tip really depends on how you are doing things. I've been making a sidescrolling 2D/2.5D metroidvania controller in Unity (using 3D assets) and I am using a Rigidbody, I simply use a Physics material with no friction which prevents him from getting stuck on walls or ledges/corners (he slides off everything), while keeping the benefit of being pushed/shoved by other rigidbodies (and I increase gravity a lot to make falling more satisfying/less floaty). I also use a time threshold for my input polling (ie: when I need to, my Input manager can check if a button was pressed/released within a specific time threshold. This is a godsend for combos and when the player presses buttons too soon or too late).
yeah honestly idk why some people don't even try to do anything with rigidbody
4:16 AAAAAAAAAAHHHHHH
I'VE BEEN TRYING TO FIGURE OUT THIS EXACT ISSUE FOR SO LONG
HOLY CRAP THANK YOU
Lovely video! Really easy to watch with great ideas that I'm planning to implement now! I just opened godot for the first time last week and starting making a 2D platformer so this was an ideal watch for me!
I agree with others - massively under appreciated video. I wanna say man, your methodology here of placing personal ideation and creativity at the top, and not leading others to simply copy what you did, is a million times more valuable in my opinion. No wonder it is under appreciated, most people want the work done for them. Well, I thought it was really good and I hope that means something. Off to start my journey, thank you!
Thanks mate! Liked and subscribed on your awesome channel!
Ive come here after watching your state pattern video. One important thing is that if you can enter the fall state after initiating the jump state, coyote will not work this way. The timer gets reset all the time, meaning that the player always has a timeframe where they can jump mid-air. So the easy solution is to not enter the fall state after jumping (which for most games isnt necessary I suppose?)
Good point! And if you need to enter fall state after jump state, you may want to start passing data between states, such as what the last state was, that way you can make sure you only start the timer if you come from a ground state. Can also do things like track when the player was last on the ground, etc.
Another good video, thanks for the upload!
Thanks! Glad you enjoyed it!
Thank tou for this video! I realy needed such content where some partially untold and unnoticed game mechanics are described!
You have blown my mind!
Keep up these videos. Very helpful.
I like that you refer to so much other videos who talk about in in death instead of just trying to put everything into one video which would just be a compilation helping no one
Very interesting! I will definitely be referencing this as I go. Have not heard of some of these terms before.
4:00 This one is more obvious that it can get used for speedrunners (It literally is more jump options), however there is a cool tidbit I want to mention!
In Red Ball 1 (Idk about the rest of the series), you can actually release jump, so you start falling sooner, then repress it! This actually has an impact, making input sequences like this possible:
Jump, nothing, jump, nothing, nothing, jump
One thing I'm adding to my game is smash-style fast-falling. So the player can press the down button to fall faster. I think this is more relevant to action games that include air combat and an air moveset that's different from the ground.
1:05
Geometry Dash: "Bro... Just hold jump, just hold it, okay?) TRUST ME, IT'S DOESN'T MAKE GAME EASIER "
Nice video, love both visual representation and coding parts. Not too handheld which leaves it to understanding it yourself
Making a kaizo game! Will be implementing Fall gravity and reaction to releasing Jump right after seeing this. Much love
Unrelated question but what was the third game shown in the intro? It looks really good (sorry if it’s a very well known game and I’m about to get clowned on for not knowing it)
Dustforce! A little bit older now, but a very slick platformer
Jump Buffering is the most important in my opinion, I've found myself sometimes playing games without it (Namely obscure online indie games), And it's often very easily notiçable, Especially if you have long segments which require the player to jump quickly after touching the ground. A while ago I was playing a game with a few jumps that were far harder than they should've been, because if you hit jump too early, you don't jump because there's no buffering, but if you hit jump too late, you'll slide off the platform, and if you try to stop on the platform, you lose momentum necessary for the jump.
how this video has 300 views? you are so underrated
Thanks! Doing a bit better now, at least :)
Almost everything on this list is something I'd have never considered
Great video. Recently played through Ducktales Remastered, and holy shit, I'm now realizing why I hated the platforming so much in that game. Especially that it hasn't implemented any form of "Push off ledges", so your character is stopped jumping upwards near edges all the time. Also, I think the character hitbox is larger than one tile gap, or very close to it, which makes this even worse.
And a specific note to Nintendo: LET PLAYERS REBIND YOUR CONTROLS!!!
great video, new sub
Been trying to figure out how the make my platformer's controls feel as good as Super Mario World (In my opinion, no platformer comes closer to SMW when it comes to controls), so this video is very useful to me. Thanks for the code examples.
Yeah, Super Mario World really nailed it in a way few games have been able to emulate. Kind of crazy how ~30 years later it still controls better than most. Thanks for watching!
I have a small one that personally bothers me in games, but it basically only matters on a keyboard. (seriously, pet peeve stuff here)
When pressing Left & Right (A/D) at the same time, they should null each other out and my character shouldn't move.
This goes for ALL games. 2D, 3D, Indie, AAA.
I tend to do this by taking the pressed input values, or use the bools as 0-1, then take one from the other and use this value in my move code.
In Godot 3.5 for example, I do:
inputDirection = Input.is_action_pressed("MoveRight") as int - Input.is_action_pressed("MoveLeft") as int
So,
Holding D: inputDirection = 1 - 0 = 1
Holding A: inputDirection = 0 - 1 = -1
Holding Both: inputDirection = 1 - 1 = 0
Holding Neither: inputDirection = 0 - 0 = 0
Starting to learn godot at the moment, and my goal is to create a movement system that mimics megaman x, likely around x4-6. Really want to make something fun like those games, and movement systems seems a good start as any!
Good video!
but ... setting the velocity IS using a rigidbody 🤔
or is he just tranlating a vector.
and if he's moving colliders as well, isn't he paying the cost of physic sync?
very good tips
Excellent video. Curious about that BaseState machines you got going on there!
(Godot total beginner over here)
EDIT: never mind, just saw you got a video on EXACTLY that. Subbing :)
i mean jumps are cool and all, but what about the ground movement? i thought i could implement a super mario 3 or world run with P speed, but it's surprisingly difficult to figure out.
4:25 If you want, you can do something like:
If down pressed, gravity higher
So you can fall faster when you want!
Coyote time sucks if you design jumps to require using it.
It really annoys me when games make it so that the only way you can make a jump is to literally fall off the ledge before pressing the jump button. It should be there to catch millisecond mistakes, not a feature of level design
1. yeah i use gamemaker, idk what a rigid body is
2. why not just check if player is pressing the jump button when he touches the floor that way the player can hold the jump for repeated jumps rather than need to learn the precise timing or you to code away their precise timing
3. thats what id do to although i think coyote timing is overhyped tbh
4. interesing ill try increasing gravity on fall ty for the idea!
5. yeah good shizz
Don't use rigidbodies huh. Never heard that one before, but i am finding myself fighting with the rb a lot in one of my projects. I just assumed getting collisions to work with high velocities would be too buggy if i coded that myself tho.
Game devs seem to add random forces to a rigid body and wonder why the simulation wreck havocs on their level design. Has anyone tried to just run animations, like running or extending the legs of the figure? With the correct friction and in 2d this might work. And put a constraint on rotation ( but Sonic on slopes?) . Oh we may need some up vector logic.
Been trying to recreate sonic in pygame for my nephew. Got the momentum working nicely but the balancing the jumping and collisions with undulating ground tiles is a real issue.
These are some great recommendations. I'm trying to implement the "ledge push" in my project right now on Unreal. I am totally with you on the raycast part, but you glossed over the 'slide' function pretty quickly. What is the method that you use to move your character over if a ledge is detected?
I know you're not using Unreal, but I'm just trying to figure out the general idea so i can translate it.
In this example, I just change the position of the object by the appropriate amount the same frame it's detected. A little crude, but should be ok if we're just doing a small amount of pushing
Given the entire game violates rule 1, I am curious how you feel about rainworld and its physics platforming for all entities
There are exceptions to everything, including using rigidbodies. They can, of course, be used for a game, but it's easy to end up fighting the physics with them if you're going for a more traditional style platformer. That's all I'm getting at here.
@@TheShaggyDev And fighting the physics does indeed happen for a few specific jumps and other areas of the game. I was just wondering if you had any knowledge of the game's behavior in general due to how it handled things. And thank you for this wonderful video!
@@casualbird7671 Glad you liked it! Off the top of my head, no, but I've not looked at that game in a loooong time.
Kind of a combination of coyote time and the raycast snapping, but sometimes it’s frustrating to think you made it to a platform, only to “stub your toe” and start falling. Super Mario Bros., for example, even let’s you run across short gaps if you’re moving fast enough.
Thanks
Thank you! Glad you enjoyed the video!
1:55 Red Ball 4 uses Coyote time, and the TAS just looks at this and thinks "So AKA there's more ground to cover huge jumps" XD
"Don't use rigid body"
... Try me
2 weeks later
-> This was a mistake. My game jumping just doesn't feel right :(
But what about us people who actually go outside and jump ( into and over water )? Why would an unrealistic jump feel right?
2:45 Another one that gets abused by Speedrunners XD
1. In SMB1 (yes this one is in a 1985 game lol), this can be used to go farther to the right side of the screen. However, this is not actually useful anywhere.
2. In SMM2 (Super Mario Maker 2), people actually use this to jump with good timing and get a couple-pixel boost!
I am really curious about that old game of yours @4:36. It looks fun to play, do you still have a version somewhere I can try it out?
Thanks! It's an old flash game named Geote, so not directly playable these days but I just discovered that Flashpoint has it archived and it seems to be more or less playable!
flashpointproject.github.io/flashpoint-database/search/#29cd3cb3-13f7-442d-8ab4-fb60fac5200f
You can still use game engine physics and tweak the rigid body physics to get a great jump
I will say I think it'd be better to do the delta time subtraction for the buffer feature in the physics process. While the variable is initially modified by an input, the importance of its update is tied to the physics engine. If you end up with graphics lagging behind or freezing, you will end up in a situation where in _physics_process the engine thinks the input is still buffered when really it shouldn't. An edge case for sure, but still worth the consideration. Hell you COULD intentionally leave it in _process if you think it's more beneficial for a player who'd get a freeze mid jump to jump again during the freeze if they press jump again.
The same obviously goes for coyote time with the caveat that I would recommend against intentionally putting it in _process. Sure if the player gets a freeze mid coyote time that means they may die (though theoretically no as input should still arrive at the proper time but let's keep a worst case scenario in mind), but if you keep it in process and they end up being able to coyote time super late in the fall (which will be visible once the game unfreeze) they will feel cheap, which is worse.
For the edge snapping it would warrant testing but I have an idea that may simplify it. Put two rays (one on each side) x away from the character center (x being the max snapping distance). Also put a fairly small box detector above the player's head. If a wall is in that box and the ray doesn't hit, move the player away and snap them back towards the wall. If both ray don't hit, then cast a new ray at the top of both "snap rays" towards the symmetry line of the player, whichever has the longest collision distance is the one you want to pick. Should be pretty efficient regardless of whether you use a tileset based map or not.
Step 1: Download Celeste’s code
Step 2: Pat yourself on the back
I wonder how some of these techniques would translate well to 3D jump n Run, like coyote time
I bet the player won't wait for the perfect perfect moment based on the perspective
what is the third game in beggining
Dustforce!
but going away from physics means you can't easily add things like ice, wind, weight, knockback, momentum. Getting stuck on walls should be trivial to fix in comparison. I am currently trying to tackle this problem for my game and I ll go with a physics approach but give the forces extra power to make the player feel responsive enough.
Great vid ! Whats the name of the game you show in the begining with the hero using a broom ?:0
Dustforce! It's a very flow-oriented platformer
@@TheShaggyDev Thank you ! The animation and art there is so inspiring , amazing .
For coyote time would it be better to instead have a collision box extend farther than the sprite thus less things are being computed?
Changing the shape of the collision box may have other undesired impacts, as you don't want the character to be unfairly hit by something or to appear to be floating off a cliff if the player stops on the edge. Managing a simple timer on a character is very low overhead and not something I'd be worried about in regards to performance.
Games already use the bounding boxes for the ledge and it looks ridiculous when the player stands over the ledge with one pixel touching the platform.
I'm trying to do the raycast snap for my game. The left corner snaps fine but when I hit the right corner, all 4 raycasts mark true meaning the player doesn't move around the edge. When this happens, what should I be looking for?
Gravity video isn't available anymore :(
Oh dang, that's a shame. Thanks for letting me know. I'll update the description ☹
you missed to put the system of varying jump
Not sure I follow? The last section is about customizing how the jump works over time, including a variable jump height.
@@TheShaggyDev
Sorry, i forget about it.
Well, so I will just ask for some way to implement a slope movement in the state machine, I get confused about how to put it inside my player with a state machine, I dont found any tutorial who helps in this case.
@@G69G71 What kind of movement are you wanting to implement?
@@TheShaggyDev moving in slopes without bounce in the end, a slope who the player can up and down according of the angle of the shape.
@@G69G71 Ahh I see. You shouldn't need a state machine for that. Move and Slide can already keep you attached to a slope, then the speed can be adjusted appropriately, though I'm afraid I don't have a resource handy for how to do that. Can probably find more if you search around for slope movement in Godot.
would this apply to 3D platforming too??
what about fix the slope problem?
like stoping the player when is on slope, this will be helpful in the game, do you know one way to fix that in state machine?
In Godot, the move_and_slide function has parameters for handling stopping on a slope. No need to modify the state machine:
docs.godotengine.org/en/stable/classes/class_kinematicbody2d.html?highlight=kinematicbody2d#class-kinematicbody2d-method-move-and-slide
@@TheShaggyDev i tryied it but my player still sliding
@@G69G71 Double check the up_direction parameter and the max slope angle. If that doesn't fix it, could check out some other resources on that specific issue and see if that helps. PigDev has done a video on slopes, for instance: ruclips.net/video/9l-tf97z2bg/видео.html
@@TheShaggyDev i tried the pigdev one and worked but where i put the script from the video? And this works in the 3.5 version?
@@G69G71 With the disclaimer that I've not implemented the PidDev technique myself, it looks like you'd just put it in the MoveState since he's working with the move_and_slide_with_snap function
And yes, I don't see any reason why this wouldn't work in 3.5
Do you have any tips for making a 2D platformer in Unity? Unity doesn't have a great simple physics component for 2D, like its 3D character controller. It's one of the big reason why I prefer Godot, actually, because it has a 2D kinematic body, as well as 2D counterparts for basically everything, and far better 2D support in general.
I'm afraid I can't help you too much there. I've not done a 2D platformer in Unity so while I've got some ideas, you'd be better served finding a Unity oriented channel to help. The general concepts from this video would still apply though. Coyote time, jump buffering, etc are all engine agnostic.
@@TheShaggyDev Cool, thanks
I believe you can add a rigidbody and make it kinematic in unity
What programming language do you code in? And which IDE do you use?
What's shown here is mostly, maybe entirely, the built-in Godot code editor and its scripting language GDScript
What was the 3rd game you showed never seen it
Dustforce! Very slick game.
Ive seen some people say before that rigid bodies arent good. But I cant really find anyone explaining how to make a 2d character without them. Like, what do I do???
It depends on your engine. Most engines have some sort of simpler / faster physics implementation than a rigid body that you can use. And if your engine doesn't offer an alternative, rigid bodies can work too! It just may be more work to get it to feel right.
celeste and its heavy reliance on left finger trigger on switch is grotesque
I hate that game devs for web games think we want to use the arrow keys for movement.
So basically make all mechanics to please players but not too much
Celeste is one of if not the best platformer in my opinion!
Hey im a new to godot, what is BaseState? And how can i use it
The code in this video is built upon my state machine series, which is where BaseState comes from. I've got a few videos on state machines if you'd like to learn about them and build the same machine I use here (can skip the Godot 3 videos if you're not on 3, though that's what was out when I made this video): ruclips.net/p/PLaiU9HSaKMWtmAIR345HGIz_ijQiyr3kH
imo coyote jump isn't really necessary. It's almost equivalent to making platforms bigger than they look.
when i do the coyote jump system the player had infinity jumps, how i can fix that?
Most likely it's because we can always jump when entering the fall state, and the jump state probably transitions into the fall state in your game, which has happened to me before as well.
What I like to do for edge cases like that, is start passing a little bit of data into the state on change. For instance, if we pass in a reference to the previous state in our "State.enter()" function, we can only allow coyote jumping if we didn't come from a jump state.
@@TheShaggyDev ok, thx but I already fixed that
correcting player mistakes?
no, they're gonna learn from that.
Input buffer for jumping is a must. However, coyote time and displacing the char a bit when jumping against a ledge, although very adviceable, they are not present in some well known games such as Hollow knight (which i find a fine game, but not as good as all the hype says)
what language are you using in this demo? looks like JavaScript?
Nah, this is all GDScript, the scripting language of the Godot game engine.
idk. It seems like godot itself have a big problem in physics and it's been going on since the early versions
whats that broom game?
Dustforce
What's the game on the right of the thumbnail
Dustforce