Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

February 18, 2020
February 18, 2020
Press Releases
February 18, 2020
Games Press

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

# Designing a 2D Jump

by Mohan Rajagopalan on 08/13/14 05:29:00 pm

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.

[Re-posted from my entry in the AtomJack blog]

In a 2D platforming game of any kind, how you design the jump defines a tremendous amount of how the game is going to feel. Since Wayward will indeed have 2D platforms, jumping is naturally the first thing we prototyped. We’re still quite early in development, and things are changing all the time, but I thought I’d take you through some of our early thinking, walk through a little basic design, and discuss a few interesting tidbits on jumping.

DEGREES OF FREEDOM

The simplest version of jumping requires knowing initial vertical velocity and acceleration due to gravity to determine character height as a function of time during the jump:

This is the standard projectile motion equation from Newtonian mechanics, and yields a familiar parabolic trajectory which is more or less how jumping works in the real world. You could use a different model (like going for a more square-ish curve than a parabola), but humans are surprisingly attuned to parabolic motion. Players tend to feel that something is off when they don’t get that parabolic arc.

So, assuming the usual model, one way of designing a jump is to mess around with various values for initial velocity and gravity until you find numbers that make the jump feel right. (Note: using Earth's real gravity constant probably won't work, but more on that later.) This can be a valid approach, but thinking from a design perspective, you're probably more interested in numbers besides initial velocity and gravity. You might care instead about jump duration, max jump height, horizontal jump distance (when running at full speed), time to max height, or maybe something else. All of those things can be derived from a choice of velocity and gravity, but what if you want to think of gravity and velocity as being derived from things you care about, instead of the other way around? How can you make the choices that you care about from a design perspective and let properties like gravity fall out from those choices? And where do you start? Which choices do you make, and how many can you make?

We can apply an approach which I call Degrees of Freedom design. The idea is that for any game mechanic (or system in general), there are a finite number of choices you can make before everything else is determined by those choices. This forces you to pick the small number of things you care about most, figure those out, and let everything else be what it has to be.

In our jump equation, we know the jump is mechanically determined by two things: gravity and initial velocity. Therefore, we have two degrees of freedom. That means that as a designer, I will be able to make two choices, and everything else is determined. For me, jump height and jump duration are usually the two things I care about most for jump design, so I'll pick those two and know that I don't get to make any more choices. I've prioritized the two things I think are most important, and let everything else be determined.

Once you've decided what you care about, if you want you can do some math and then code the mechanic so that those things are the literal parameters you adjust, instead of the things that might be most straightforward to code (in this example, gravity and initial velocity). But often that step isn't required - the more useful thing is the design knowledge of how many things you have control of. In this example, I might then proceed by trying various values for velocity and gravity, but armed with the goal of hitting particular heights and durations, and the knowledge that it's possible to do so for any pair of values I like.

#### VARIABLE JUMP HEIGHTS

Of course, that model of jumping is too simple. Games have a long tradition of allowing players to vary the heights of their jumps by holding down the jump button for shorter or longer durations. This doesn't make a whole lot of physical sense, and not every game does it, but it is fairly common.

The usual way of accomplishing this is to suppress gravity while the jump button is held down, up to some maximum duration. This results in a jump motion which isn't quite projectile motion - height gain is linear until gravity kicks in, then transitions into the usual parabola:

If this is height vs time, the red line is height until gravity kicks in, at which point the blue or purple parabola takes over.

It's important to realize that you can't get a jump that feels quite like proper projectile motion using this scheme. That initial linear part is always going to give a bit of a float-y, jetpack-y feel to the jump.

Going back to the degrees of freedom approach, we can now think of the jump as being determined by initial velocity, gravity, and the duration of the jump suppression. It’s clear that we've got three degrees of freedom now, the third one coming from the gravity suppression timer.

I don't care about that timer directly. Note that the timer doesn't correspond to the apex of the jump - the player will continue moving upwards once gravity kicks in, until gravity "overtakes" that initial velocity. The timer is more subtle, and not something the player (or designer) will feel specifically. But I've got another degree of freedom (I still care about max height and max jump duration, as before, for my first two degrees), so what else do I care about in this new system?

The answer probably should be related to variable jump heights. Thinking about how players process a variable jump, I'm pretty confident that they really only consider two cases: the highest jump (where they hold the button down until they hit the apex (although they didn't have to, to achieve that max jump)), and lowest jump (where they just tap on the jump button as lightly as possible). So maybe the third thing I care about is lowest jump height. I might also care about lowest jump duration, but I'm out of degrees - I have to pick one or the other, and I think jump height is more important.

#### AIR CONTROL

So far we've only really covered the up and down part of the jump, but there’s a lot more to decide about what happens in the air. Specifically, how much horizontal motion control should we give the player? There are the extremes of no air control (Ghouls ‘n Ghosts games), full air control (Mega Man games), and lots in between (Mario, Metroid). Having no air control is the most “realistic” scheme for sure, but generally makes for unforgiving gameplay. Granting full air control is the most game-y scheme, allowing for ultra-precise movement and tricky platform puzzles.

Going for something in between, where you’ve got aerial momentum but can affect it to some degree mid-air, can give a nice weightiness to the jump while still giving the player room to correct errors and feel in control. That’s where we started in prototyping, but over time we kept adjusting more and more towards full air control. This was surprising at first, because we aren’t aiming for a game where precise platforming and timing was a core component of the game. But on further reflection, it became clear that we wanted more air control because we wanted less focus on platforming puzzles. By making it as easy as possible for the player to move where they want to move, we free them to focus on other aspects of the game.

#### GRAVITY, JUMP HEIGHTS, AND A WORLD IN MINIATURE

Most games feature characters with amazingly high vertical leaps, and Wayward is no exception. Particularly in 2D games, the player can usually jump at least the character’s height, and often many times more than that. Intuitively, that translates to some combination of very strong and light characters, and very weak gravity.

Well, it turns out that weak gravity isn't what games do at all. In fact, many Mario games have gravity in excess of 8 times Earth gravity (here's a fun analysis). Since mass doesn't affect falling speed, it’s pretty easy to see that no matter how light these characters might be, gravity is crazy high. Assuming characters of normal height, that is.

But is normal height the right assumption? If we imagine the characters as being a few inches tall instead of a few feet, then gravity works out to be about right. And, by extrapolating a little from the square-cube law, it makes sense that such small characters might be able to jump many times their own heights. If instead of thinking about these games as controlling life size characters, we think about them as playing with toys of those characters, then the physics start to make a little more sense. Our view into the game is like looking at model playset of the gameworld. It’s a world in miniature.

That feeling of playing with a world rather playing inside a world is a characteristic of 3rd-person games, and especially 2D 3rd-person games. In 2D side-view games, the player usually views a large slice of the game world around the character, much more than the character would see themselves. There’s magic in evoking that feeling of “playing with” the character (and world), in contrast (or addition) to the usual immersive ideal of “playing as” the character. It’s a part of why gamers and developers alike can be nostalgic for 2D games, and a reason AtomJack decided to focus on 2D gameplay for Wayward. Exploring and seeing a world in miniature can be more playful and less daunting than being immersed in a 3D world, while still evoking a powerful sense of wonder and discovery.

### Related Jobs

Purdue University — West Lafayette, Indiana, United States
[02.14.20]

Assistant Professor in Game Development and Design
Sucker Punch Productions — Bellevue, Washington, United States
[02.14.20]

Gameplay Programmer
Airship Syndicate — Austin, Texas, United States
[02.14.20]

Senior Systems Designer
Futureplay — Helsinki, Finland
[02.14.20]

Senior Game Designer