## Learning and Applying Mathematics using Computing

### What Goes Up Must Come Down

This post is about making things jump up and fall down (e.g. for platform games), or: modelling acceleration.

When building 2D games and simulations in environments like Scratch or Greenfoot, you can either use the 2D view to provide a top-down view on the world, or a side-on view. Platform games (Sonic, Mario, etc) are the main examples of the latter, and in these games, you often want to make things fall down when there is no solid ground beneath them, and to allow the character to jump around. This post will look at how to do this: it’s actually best to start by implementing falling first, and then implement jumping.

## Falling Down

One way to make things fall is to move them down the screen at a constant rate. However, this often doesn’t look quite right — because it’s not the way that the real world works! Gravity produces an acceleration downwards, so when things fall down, they increase speed as they fall. In order to model the effect of acceleration, you must keep track of the current speed in a variable. Here’s the code in Greenfoot:

```public class AccFall extends Actor
{
double speed = 0;
double exactY;

public void act()
{
speed += 0.4;
exactY += speed;
setLocation(getX(), (int)exactY);
}

{
exactY = getY();
}
}
```

This code is a bit more fiddly than it needs to be, due to Greenfoot using integers to store coordinates, and me using an acceleration to fall at that’s not a whole number (otherwise it’s a bit too fast). To visualise the difference between falling at a constant rate, and falling at an accelerating rate, I’ve coded both in the same scenario. You can watch by clicking the apples below — the green apple on the left-hand side falls at a constant rate, while the red apple on the right-hand side falls at an accelerating rate. Try covering up one side with your hand and just watch the other side, to try to see the difference:

## Jumping Up

The other half of implementing a platform game is allowing the character to jump. It turns out that this is quite simple to model: you can make the character jump up by setting the speed variable to be a large negative value (in effect, an instantaneous upwards acceleration). This causes the character to move upwards, and thereafter gravity takes over by reducing the speed (downwards acceleration is equivalent to a slowing of upwards speed) until the speed takes the character downwards again, just like the red apple was falling.

You may not have followed all that in text, so here’s how you can see it in action. I made a scenario with a frog on a log that can jump (press up to jump). If you watch carefully, you can see that the frog slows until it hits the peak of its jump and then accelerates as it comes back down. Greenfoot has a useful “Inspect” feature that allows us to see exactly what is happening.

If you want to play along yourself, open the scenario in Greenfoot. Hit compile in the bottom-right, and make sure you can see the frog on the log. Right-click on the Frog and go to “Inspect”. Move the inspect window so you can see it alongside the main Greenfoot window:

The two variables of interest are “int y” (currently 222) and “private int verticalSpeed” (currently 0). Right-click on the frog and select the method “void jump()” to call it. You’ll notice the frog will jump up (by 30: y becomes 192, and verticalSpeed becomes -30). That’s the instant upwards acceleration. Press the Act button once. You’ll see that verticalSpeed becomes -27, and y becomes 165 (which is 192 + (-27), old position plus vertical speed). Press it again, and you get -24 and 141 and so on. Press Act a few more times in quick succession and you’ll be able to see (looking at the frog) that the speed of the frog’s rise slows until it hits the peak of its jump, when verticalSpeed is zero. After that, verticalSpeed increases and the frog falls faster and faster downwards (keep clicking Act) until it hits the log again, when the speed is set back to zero.

So the whole time, the verticalSpeed increases at a rate of +3. On the way up this causes the negative speed to get closer to zero, slowing the frog, but on the way down it increases the positive speed, causing the frog to fall faster and faster. This can seem a bit magical, but this is simply the effect of a constant acceleration from gravity, causing the arc of the frog’s jump. If you don’t quite understand, I encourage you to play more with the scenario to get a feel for it.