Tonight I was talking with a mentee who is just getting started in the world of game design, and ended up digging up some old demos I had made to illustrate some basic game feel concepts. I thought they were still pretty useful, so I’m reviving the article they were part of. Although this is specific to GameMaker on the implementation side, the demos are much more broadly applicable. Enjoy!


I want to tackle some game-feel issues with jumping that I often see in beginner GameMaker platformers. If you are a student learning about game development, or a hobbyist learning GameMaker to prepare for your first game jam, or just interested in trying demos to better grasp ideas like ledge assistance and input buffering, this article is for you!  


One year when I was trying out a bunch of student games, I noticed I was giving the same feedback to student games over and over, so I dug into the tutorials they used. Many GameMaker students referenced Shaun Spalding’s excellent platformer tutorials for their first game. I like these tutorials because they are simple and straightforward in a way that won’t overwhelm a beginner, even one with no coding experience. 

The original tutorial for Gamemaker Studio

And an updated one for Gamemaker Studio 2

The trade-off for this simple approach, however, are a couple of game-feel issues that pop up as a result of the jump code. I’m going to focus on two small ways that beginners can modify these tutorial scripts to make their jumping feel better:  Ledge Assistance and Jump Input Buffering 

These are common platformer implementation techniques, so the good news is that a lot of excellent stuff has already been written in depth about these concepts. But if you’re a beginner just building your very first platformer, this sort of stuff probably isn’t on the forefront of your mind. It’s already a big task to create all the pieces of a platformer from scratch, down to just getting your character moving at a basic level, so something like “jump input buffering” isn’t going to be a thing a beginner considers researching.

My hope is to connect these concepts to the base tutorial to help ease students into thinking about this sort of stuff with their games. Let us begin!

1. Ledge Assistance

Also known as ledge forgiveness, grace period jumping, coyote time*, or a number of other terms, this is a fix for the following issue you may run into when setting up your jump code: You try and jump off a ledge at the last possible moment in order to clear a really big gap, but your jump input doesn’t register and you fall off the ledge instead.

The fix for this is allowing a buffer of time where the player can be not-on-the-ground but will still register a jump input – a grace period for jumping off of a ledge.

For an in-depth and  illustrated look at this concept, I highly recommend Kyle Pulver’s article on this topic.

Since this concept is so closely tied to input and feel, it can be difficult to fully understand by visualizations alone. So I made a simple demo to help people understand how the grace period changes the feel of jumping.

Try the Ledge Assistance Demo (keyboard required)

This is a very simple platformer setup based on the code in Spalding’s tutorials, but one where you can adjust the number of frames in the ledge assistance grace period.

The default is the grace frames set to 0, which is what it feels like in the default tutorial version. As you may be able to feel as you try to make the long jump from one ledge to the other, you can get into a situation where you try and jump at the last possible minute, but fall lifelessly to your death instead.


A gif showing what a missed jump looks like when there is no assistance

This feels terrible because there’s a disconnect between your input and what you expected to happen as a result. Kyle’s article goes more in depth into why this happens and provides an alternative implementation to avoid the issue, which is what I used to make the grace period.

By adjusting the grace frames (by clicking the up and down arrows), you are controlling the number of frames the player can simultaneously be “in the air” and press the jump button and still have that jump register. This is the “grace timer” that Kyle mentions in his article. Play around with this number and feel the difference it makes in the jump. Check the “show feedback” button to get a visual cue to illustrate when the grace period is active.


A gift showing the visual cue for when the grace period is active

What is the right number of frames to use for a grace period?

Well, this depends entirely on your game and what player feeling you’re going for. If you are making a very tight, precise action platformer, then you’ll probably want to make the frame window as small as possible while still compensating for human reaction time (if you want to get all mathy, consider your target frames per second, and the fact that average human reaction time is somewhere in the realm of ~215ms, or you can just do it by feel. I recommend starting with 6 frames and adjusting from there). If you can’t guarantee a consistent framerate, you may need another solution (time? distance?)

However, let’s say you’re making a game about the laziest bat who “jumps” by flapping her wings a single time, in which case it may make sense to have a super floaty jump and really long grace period, so the bat could amble off the edge and start visibly falling before “jumping.” I dunno, I just made that up off the top of my head.

My point is that there’s no universal right answer here, you’re going to have to tune it with the feel you’re going for in your game, in which you have to consider many things: level of challenge, experience of audience, reaction time factors for your audience, input device, the fantasy of your movement, etc.

2. Jump Input Buffering

Another issue I see in a lot of student platformers is no input buffering on jumping, which is something that can feel bad if you’re making a game that requires a lot of repeated, precise jumping. Once again, Kyle Pulver has written about this and illustrated it at length, and I recommend reading his article

The solution to this issue is in a way the opposite of the ledge assistance issue: you still want a grace period in which a jump input will register as true, but in this case you want it *after* you hit the jump button instead of before.

Try the Jump Input Buffering Demo (keyboard required)

Similar to the other demo, when the jump input buffer frames is set to 0, this is what you get with the base tutorial version. If you happen to hit the jump button just slightly *before* the character collides with the ground, it will not register, and so the character will sit there on the ground and you will feel grumpy about it. This happens more often when you are trying to do a series of jumps one after the other, jumping as soon as the character hits the ground.


Shows how an early input can mess up a precise jump when there is no buffering

Increasing the buffer frames is basically saying “if the player hits the ground within this number of frames after I press the jump button, just execute the jump as soon as they touch the ground”


Shows the colored background cue to indicate when the jump window will accept an input

Again, there’s no universal answer for how big of a buffer to use. Play around with different frame amounts and try to feel the difference it makes in the jumping. You’re trying to find a balance between compensating for player reaction time and still having the movement look and feel grounded and believable.

And think about what player feeling you are fulfilling with your game. Would it ever make sense to have a really really high input buffer? What would that game look like?? What would the fantasy be for that input to make sense and feel good? Maybe you should try and make that game!

The Point

When it comes to the wide world of game feel, these are but two small tweaks, and one can really dig in and get really deep into shaping player input to feel amazing. There are many others to explore: tuning variable jump height, nudge assistance, the idea of programming jumping in terms of max time to peak as a number to tune around, and so on.

But when you are just getting started with your first platformer and are feeling like you have a handling on the basics, I think these are good places to introduce yourself to tuning player input. It’s easy to get overwhelmed, especially if you aren’t an experienced coder, when you take on too much right off the bat.

And you can see when looking at the script itself below, even these two tweaks get quite a bit more complicated than the original tutorial script for player movement.

But I think it’s a good place to start, and a great way to add a little extra polish to your first platformer, be it for a class project or a game jam or just for fun.

Script Samples

If you are following Spalding’s GameMaker tutorial, you should be able to copy and paste these scripts into the player object’s Create event and Step events, respectively. Set grace_jump_time and jump_buffer to whatever number felt good to you when playing with the two demos. I tried to comment thoroughly. Or you can just look at the whole GameMaker project attached below. Good luck!

Modified Player Create Event

Modified Player Step Event

All the Links in One Place


* Regarding “Coyote Time,” I used to not like this phrase because it’s so reliant on a cultural understanding of Looney Tunes, so I asked a bunch of international devs if they found the phrase confusing. Half of them said it was, and would prefer a description that described what the concept actually does. The other half liked Coyote Time because, even though they didn’t understand the reference, it was a term that was easy to search and get what they were looking for. Basically, call it whatever you want it doesn’t matter.