Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 21, 2014
arrowPress Releases
September 21, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Platformer controls: how to avoid limpness and rigidity feelings
by Yoann Pignole on 01/03/14 09:25:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutraís community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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):

  • Too low air acceleration won’t give player a chance to correct his trajectory in the air and he’ll have a feeling of “heaviness”.
  • Too fast air acceleration will be tricky to measure for the player

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:

  • A jump call is registered when the player gives the input AND the character is close enough to the ground. So, as the character touches the ground, he will jump again :

  • When the character falls from a platform, there’s a time delay during which he can jump when in the air if the player gives the input :

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:


Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Senior AI Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Lead Tools Engineer - Infinity Ward
Insomniac Games
Insomniac Games — Burbank , California, United States
[09.19.14]

Senior Engine Programmer
Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[09.19.14]

Front-End Developer






Comments


Javier Degirolmo
profile image
Another method for variable-height jumps which I use (and is simpler to implement since there are no new variables needed) is that if the character is 1) jumping 2) going up and 3) the button is not held down, make the character accelerate down twice as fast (essentially add the acceleration value again).

The above provides some surprisingly complex behavior, because it's possible for the player to press the button again while the character is still going up (especially if the character bounces). This would make the character return back to the normal falling speed, giving greater control to the player.

Yoann Pignole
profile image
Hi Javier and thanks for this information about how you deal with analog jump !

Indeed, your method allows the player to press the button again while the character isn't falling yet, but I'm wondering if the time delay (assuming you don't use a very low gravity) when he can do this is enough to provide an efficient and understandable mechanic ?

The idea is surprising and it's why I would definitely like to test this gameplay !

Alexandre Daze-Hill
profile image
I've got nothing short of a passion for platformer controls and I'm quite impressed by the thoroughness of your presentation! I'm now working on a series of entries explaining a game we're making, the first three beign about everything you've talking about and I have been surprised at the amout of common ideas we have.

One thing I'd add on is a complaint to Battleblock Theater: when the player is too near the ground, it seems he won't double jump for the reason you gave: tolerant jump calls,and it's all good, but it also happens with hurting platforms, so it won't let me double jump to avoid beign killed. Also, I like verifying if there is something bad ahead of me, if there is, I increase greatly the friction when there is no input, to avoid beign hurt too much time after the last input.

Yoann Pignole
profile image
Hi Alexandre and thanks for the compliment about the thoroughness (and to make me learn a new english word !)

I didn't play yet Battleblock Theater but I guess the issue you explained is not really the same I talked about : a double jump should be allowed at ANY time the character is in the air (with often a "number of uses" condition), even when he is very close to the ground.
For the "hurting platforms" case, one of the better choice would probably be to reduce the collision of the lethal object facing its visual representation : it's another way to add "tolerance" and allow a double jump a little bit after the character visually touched the obstacle...

Alexandre Daze-Hill
profile image
But as you said, maybe the player wanted to jump from the platform, if it is the case, you make him use the double jump when he doesn't expect it to be used, what if his intentions were to double jump after the landing, but he pressed too soon? What I did for our platformer "engine" is to first check with raycasts if the ground will be touched within 4 frames at current falling speed, if so, I check with the same rays, clamped to the landing point, if a hurting collision is touched. If neither touch anything or both touch something, there is no custom handling, if only the landing check returns true, the tolerance system is used.

A question comes to mind now, one that I never thought of before, how would one best handle a delayed jump system like this and an analogue jumping system? What I mean is if the player is used to the timing of the jumpsand lets say he means to sustain the jump for 4 frames, but he also presses 4 frames early, will the jump be sustained only one frame or the system would compensate for the number of frames pressed prior to the real jump? Or maybe it would be weird to do this because maybe it would look like the character suffers some lag regarding the sustainment of the jump?

Yoann Pignole
profile image
I never had issues mixing the analog jump system and the tolerance-for-close-to-ground-jumps : if the player press the jump button in the tolerance zone, the jump call is just "registered" and the jump will be performed as soon as the character touch the ground. Then, if the player still hold the button, the character will reach the max height, else the character will just have a jump impulsion and stop when the "cut jump speed limit" (which I talked about in the article) will be reached. Actually, this time between when the player pressed the button and when the character touch the ground and finally jump is so short that the player won't feel it : it's just about tweaking well the distance-above-ground-where-a-jump-call-is-registered !

Alexandre Daze-Hill
profile image
I guess you're right! Never bothered with that detail before and it never felt wrong, but I spontaneously wondered if it would be better to do work on this, you seemed to be an appropriate person to ask on the subject, anyway thanks for your time!


none
 
Comment: