How to Fix Issues with your Game's Controls

Advice on improving a game's controls often takes the form of specific tips and tricks, such as letting you jump a few frames after falling off a ledge in a platformer, also known as "coyote time". This type of advice is often useful but there are a few things stopping it from being a one size fits all solution:

First off, there are plenty of legitimate reasons to intentionally make your game's inputs difficult. Maybe you enjoy the challenge of strict inputs, maybe you think there are other ways of dealing with the perceived problems of strict inputs (for example, you might prefer to reduce your game's input lag instead of adding coyote time), or maybe you have an entirely different reason for it. Game development is an art, after all.

Or maybe your game does something new. Genre-specific gameplay programming knowledge is important, but if your game has an entirely new mechanic there might not be an existing solution for its input issues.

So how do your make your game's controls feel good? Personally I find that a lot of input issues either come down to timing or spacing. When it comes to timing issues, input buffers can let players input a command "too early" and cancel windows can let them input a command "too late". For spacing, shrinking or growing the appropriate hitboxes goes a long way in most situations, or even making the player completely invincible for a brief period.

But this doesn't cover everything. Maybe your game's control issue is unique to the game's design, or maybe there's just a bug hiding in your gameplay code that's occasionally messing up the controls.

The way I handle this is to treat literally every single control issue as if it's a bug in my code. For example, if I'm playtesting my game and an action doesn't come out even though I thought I input it correctly, or if my character bumps their head into a wall that I don't think they should have quite bumped into, I won't continue working on my game until I've tracked down the cause of the issue and either fixed it or decided that it shouldn't be fixed.

It's much easier to do this if you have a way to step through your own playtesting sessions frame-by-frame while looking at your own inputs, to see exactly what happened. I do this by automatically saving the last 15 seconds of gameplay states and inputs whenever I play my game, so it's trivial for me to step through any recent frame in a debugger. If you can't do that yourself, I at least recommend recording video footage of your own playtesting sessions with your controller inputs visible onscreen so you can watch the video back frame by frame.

If you have other team members or playtesters, you probably want to record in-game replays of their playtesting sessions too, so you can debug any control issues that they encounter.

In short, I recommend treating every instance of your game's controls feeling wrong as a bug, making them as easy as possible to reproduce, and putting real effort into fixing them.

To show how complicated these things can get, here are a few control issues from actual games in a genre that I'm familiar with: arcade-style 2D fighting games. I'll give the type of feedback that I would expect to hear from a casual playtester who encountered the issue, along with the actual cause of the problem:

Example feedback: "Sometimes my fireballs don't work", in a game with quarter circle forward / 236 fireball motions.

The actual issue: Maybe player presses the button a couple of frames before finishing their quarter circle motion, or they overshoot their quarter circle motion and press the up-forward diagonal before pressing the button, or they skip the down-forward diagonal input, or input the motion too slowly, or a million other things. It's up to you how lenient you want to be with any of these inaccurate fireball inputs. Some older games don't even make the fireball come out if you press the button on the same frame that you finish the motion; instead, they make you hold forward for one frame (or more!) before you press the button. Do whatever feels right for your game!

Example feedback: "Sometimes my pushblock doesn't come out", in a game where you pushblock by pressing a button while blocking.

The actual issue: If you input a pushblock during hitstop from blocking a move, your pushblock input will be eaten if another hit touches you before your hitstop runs out.

Example feedback: "The game works fine in training mode, but sometimes my moves don't come out in local versus mode"

The actual issue: When one player releases a button, it clears any buffered presses of that button for both players. So if you mash buttons really fast while the other player is doing a combo, it'll keep clearing their buffered button presses and make their input windows tighter as a result.

You get the idea. These kinds of input issues are indistinguishable from bugs, so if you don't want your game to have these problems you have to debug them accordingly. It's difficult to stamp out absolutely every single unintended input issue with your game, but the more effort you put in, the less issues you'll have.

To finish, here are a couple of specific tips that I do recommend for every game:

If possible, I recommend working in an environment where you have control over what is happening in your gameplay code on a frame by frame basis. Plenty of incredible games run in janky engines or have input issues, but it's easier to make your game feel good if you have complete control over what's going on. I also recommend running your gameplay code with a fixed timestep if possible, to keep things completely consistent across machines. If you really need your game to be ultra-responsive at high frame rates, you can always just run your gameplay code at a very short fixed timestep and visually interpolate between gameplay states if necessary.

Similarly, I don't recommend using third party physics or 3D animation systems to drive your gameplay code if you have a choice, unless that's the sort of game feel you're going for. After all, if you're making a heavily physics-driven game you probably want a degree of unpredictability in your controls anyway.

Last but not least, if you like another game's controls, play it and figure out how they work! If it's an older game, you can even step through the game one frame at a time in an emulator to see exactly what's going on. Some games' controls are already well-documented, such as the classic Sonic the Hedgehog games and various Tetris games.

That's all the advice I've got. Go study what makes other games feel good, try to work in an environment that gives you control over your gameplay code, and don't ignore any input issues!