Asked to make something fall, almost everyone writes this:
y = y + 5
Move it down a bit, every frame. It does go down. It also looks completely wrong, and the reason is easy to feel: drop something off your hand and watch it. It leaves your hand slowly and hits the floor fast. Our version leaves slowly and arrives just as slowly. That is an elevator, not a fall.
Gravity does not move things down. Gravity adds to the speed, and the speed moves things down. Two separate adds, in that order, every frame:
vy = vy + gravity then y = y + vy
That is the entire thing. Two lines. Every falling object in every game you have ever played is doing those two adds, sixty times a second.
In the table, the speed column counts up by the same amount every row, because that is literally what the first line does. And since the speed is what gets added to the position, the moved column counts up by that same amount too. Set gravity to 0.5 and the ball falls 0.5, then 1, then 1.5, then 2. The pattern IS the gravity.
If you built the ghost trail in the last lesson, switch it on during a fall. In a steady run the dots were evenly spaced, because the runner covered the same distance every frame. Falling, the gaps grow. Even spacing means steady speed. Stretching spacing means the speed itself is changing, and a changing speed has its own name: acceleration.
Science class writes gravity as 9.8 metres per second, per second. That "per second, per second" looks like a typo the first time you see it, and it is the same idea you just coded: it is how much the speed changes each second, not how much the position changes. Yours is 0.5 pixels per frame, per frame.
In your toolkit this becomes applyGravity(body, g): two lines that make crates drop,
arrows arc, and characters land. Next lesson you turn it upside down and get a jump, which is the
same two lines with one shove at the start.