Paradoxically, it’s often the same problem behind these 2 feelings: a lack of reactivity to the player’s inputs and a lack of precision.

My goal here is to help novice game designers (and maybe more experienced ones) to avoid this kind of control feelings if they don’t want it. But keep in mind having reactive and precise controls is not an obligation and won’t work for all the gameplays.

So, after this little clarification, let’s talk about the common reasons which could, in my mind, contribute to this feeling:

Priority to animations

What the first Prince of Persia, Another world and Dark souls have in common? Yes: the priority to player animations before the player’s inputs. If these 3 great games build their gameplay with this constraint, maybe it’s not what you want for a “reactive” game.

For more details, when animations have “priority”, it will be impossible for the player to do some actions while another animation is still running:

Hopefully, it’s very simple to avoid: give full priority to player’s input, even if it cut your character animations.

This issue may appears as obvious for experienced designers, but always good to remind it!

Low ground friction

What I call friction is a strength applied on the character speed, when the player releases the stick, on its opposite direction, until he’s stopped.

Yes, having a small ground friction is very cool, especially with a beautiful breaking animation! But when your player takes 0.5 seconds to stop at full speed, it’s most of the time too long!

Except for ice platforms or for a skateboarder character, be careful with too low friction on the ground and don’t hesitate to increase it.

No reactivity when changing direction

If you use a classic system to move your player on the ground, with run acceleration, maximum speed and friction to stop itself, maybe you noticed a result you didn’t expect when you suddenly change direction: the player is not reactive and needs some time to go the other way.

Let’s explain with a 2D platformer. The speed computation each time laps is:

speed = speed + acceleration (with a maximum speed limitation of course!)

If the player gives a “right input”, the acceleration is positive and speed increases in positive à the character moves right.

Now, if the player gives suddenly a “left input”, the acceleration is now negative and speed progressively decreases from positive to negative à the time the speed takes to move from positive to negative, the player slows down progressively to finally go left. With a little scheme :

 So, now, what’s the solution? Actually it’s pretty simple: you just have to use a “reactivity percentage”.

What I call a “reactivity percentage” is an extra percent of acceleration when the player gives an input in a direction opposite to the actual speed:

If input direction opposite to actual speed direction
        speed = speed + acceleration + acceleration * reactivityPercent
Else
        speed = speed + acceleration

And with a scheme :

This solution can be used in 3D environment too, with a little modification as a direction can be “more or less” opposite to one other. The idea is to apply a ratio to this acceleration percentage, relating to the “amount of opposition”:

oppositionPercent = opposition ratio between input and actual direction (0 is the same direction and 1 the complete opposite)
speed = speed + acceleration + acceleration * reactivityPercent *oppositionPercent

Non-analog speed on analog stick

Some games use 2 values of speed, often a “walk” and a “run” one.

If this solution was evident on 8 and 16 bits consoles with a directional cross to control movements (by default, the player walks and, holding a button, the player runs), it seems not logical with analog stick on modern pads : as your thumb move on the stick is progressive, you expect a progressive speed too.

Having only these 2 values with an analog stick don’t always result with a “rigid” feeling but, if the values are too far from each other, the player will feel this “step” at stick midcourse.

Analog speed is quite simple to implement as most of commercial game engines have a -1 to 1 value for each axis. So, you can determinate your current maximum speed setting a “maximum” maximum speed (the maximum speed when your stick is all to the right/left):

currentMaximumSpeed = MaximumSpeed * AnalogStickRatio

And it’s always a good idea to think about modulate the acceleration the same way.

Low gravity

Having a little bit too low gravity value can definitively give you this feeling of limp controls, like if your character was a feather or was on the Moon.

It can be a choice but, sometimes, designers lower the gravity to make the platform challenges easier (or keep the Earth default one, 9.81m/s, not adapted to their objects dimensions). It’s a possibility but keep in mind you risk to lose the “weight feeling”, which is paradoxically important to succeed in platforming challenges.

Air control (acceleration in the air) not tweaked

Air control (ability to move player on the horizontal plan in the air) is something not realistic at all. But realistic behaviors are not always fun in video-games and, for a platformer with jump challenges, you’ll probably need some air control.

If acceleration parameter on the ground must be carefully tweaked, it’s all the more true for air acceleration (because the player is falling and don’t have all the time in the world to react):

And, obviously, low air acceleration will multiply the “weight” feeling of a high gravity value and a fast one the “floating” feeling of a low gravity.

So, gravity and air acceleration should probably be considered and tweaked together.

However, be careful to not always “compensate” high gravity with a high air control and vice versa, sometimes it could be better to keep consistency between the 2 values. And don’t forget “extreme” values can lead to great games with strong identities:

Non-analog jump

A non-analog jump solution, namely only one jump height without any possibility of modulation, is frequent, even in modern and AAA games. First, let’s be clear on what is the difference between what I call an analog jump mechanic and a non-analog one:

In some games, like AC or GTA series, it's not a problem to have non-analog jumps, because they’re not focused on jump challenges and the game want to keep a “realistic” mood. However, in “jump-centric” games (like Super Meat Boy, Mario or Sonic series), being able to “cut” your jump in the air is essential to succeed in some challenges (like jumping under a spiked ceiling). In addition, it contributes to have a feeling of reactive controls.

Implementing an analog mechanic could be a little bit tricky. My solution as a designer is directly inspired by the one used in Sonic (thanks to the “Jump velocity” part of Sonic Physics guide): assuming you use an impulsion speed to jump (letting the character falling back step by step with the action of gravity), the idea is to define a “cut jump speed limit” and, if the vertical speed is superior to this limit when the player releases the input, set the vertical speed equal to the limit. If the speed is inferior to this value, it means the character is close enough to fall back and it’s not necessary to decrease “directly” the jump speed.

Of course, you’ll need some tries to find the good value for the “cut jump speed limit”. As the value is linked to your gravity, for me a value of “gravity / 10” worked well:

cutJumpSpeedLimit = gravity / 10

If isJumping and jumpInputReleased and verticalSpeed > cutjumpSpeed
        verticalSpeed = cutJumpSpeed

No tolerance for jump calls

Naturally, you want your character to be able to jump only when he is grounded. But if you strictly use this condition, you will probably encounter some lack of reactivity feelings. Indeed, if the player calls for a jump a few frames just before the character touches the ground (and it’s often true, because the human brain tends to anticipate too much the action), the call won’t be considerate. The same way, if the player wants to jump when the character reaches the end of a platform, he may reacts just a few frames too late while the character just start to fall. Clearer with a little scheme:

The perception of the player can make him think he was able to jump, even if technically it’s not true.

To avoid this perception, the solution is to add a “tolerance”, which means:

No abilities when jumping

The sensation of "high reactivity" appears when having an immediate result of your inputs on the screen. Yes, it seems obvious but, playing Skylanders Swap Force, I was surprised to be unable to attack when I was jumping: no animation or sound feedback, just no response to the attack button when in the air.

In a platformer, jump is your main ability and way of moving and you will use it very often. So, forbid any other ability while jumping must really be carefully considered. Especially if this ability is needed in action phases (like the attack ability in a melee fight based game) !

If you really want to forbid the action in the air for any good reason, it's always a good idea to feedback this impossibility with some sound, FX or animation.

Round platform edges (slippery edges)

I some games, all the platform have round edges. There a lot of reasons to do that but a common one is to avoid the character “capsule” collider to get stuck on right-angled edges:

A lot of accessible game engines, like Unity 3D, use this kind of “capsule” collider to handle collisions with their physics engine. So, it’s very tempting to use this easy and quick solution to avoid the “stuck” issue instead of dealing with right-angled edges.

Actually, it’s not necessarily a bad solution: if your game is not based on jump challenges and don’t need high precision moves, it’s probably ok. However, if you want to make a Mario-like with critical jumps, you should probably avoid round edges: it could be very frustrating for the player to reach a platform on the edge, feeling he touched the platform ground, and finally slip into the void because of an almost invisible round edge!

If you are interested in coding, I wrote a previous article in my “hobbyist coder” series about a way to code a custom 2D platformer controller in Unity 3D, especially to avoid this kind of problems.

Visual and sound feedbacks

Yes, feedbacks are important. And yes, sometimes even during the prototype process.

I realized the importance of feedback in platformer working on a personal project: even with all the other “rules” above applied, I still found the game a little bit limp. I tried to tweak the variables, modify the move system, etc… Nothing changed. Finally I was tired to search and decided to start coding a sound manager to “relax” and the first sound I added to test it was the jump one. And how I was surprised to find my character much more reactive! I decided to continue on this way and implemented a run animation speed linked to the character speed: the games seemed to gain more reactivity again!

This little story was just to say that sometimes, even if you know animations, sounds or FX will come later in the development, the brain needs them to help it “materialize” some physics concepts like speed, move or gravity. And because platformer games are all about the understanding of specific physics, I think it’s important to implement placeholder feedbacks early before trying to tweak your move variables.

Conclusion

Of course, this list is non exhaustive and I’m really interested to hear about other observations about platformer controls.

This list is also subjective and it’s why I put a lot of “in my mind, “In my opinion” and “most of the time” expressions in this article: nothing is set in stone in game design. The game designer work is not really about “theory” and it’s why it’s very tricky to write about it. In my opinion (again!), the center of his work is above all to prototypes ideas, test them, prototype, test, etc. until he end up with something “fun”. So, if you want to design a kind of game which usually needs a lot of reactivity and precision, but going against these few tips, just don’t hesitate. But prototype your work!

Let’s finish with my game design golden rule: there are no golden rules!

And, finally, thanks to some really interesting articles which inspired me to write this one: