Implementing a Basic Jump

Introduction: The Physics of Jumping in 2D Video Games

In two-dimensional platformer design, the jump is almost always the core mechanic around which the entire player experience revolves. A jump that feels imprecise, excessively floaty, or stiff undermines gameplay satisfaction, no matter how polished the visual art or deep the narrative. To make a jump feel natural and rewarding, you cannot simply move the character upward at a constant speed and then return them to the ground through uniform translation. Instead, you need to simulate the foundational principles of classical kinematics in a simplified, controlled manner: an instantaneous upward impulse followed by continuous gravitational acceleration.

In the previous lessons of this module, we configured keyboard input reading and horizontal character movement using a custom horizontal speed variable (`hsp`), along with flipping the sprite visually based on facing direction using `image_xscale`. In this lesson, we take the logical next step: introducing vertical displacement along the Y-axis. We will calculate vertical speed (`vsp`) step by step, apply an instantaneous upward impulse when the player presses the jump key, and subject that impulse to progressive deceleration caused by a constant downward force of gravity.

GameMaker's Coordinate System and the Vertical Axis

Before writing a single line of jump code, it is essential to understand how GameMaker interprets two-dimensional space inside a Room. In standard Cartesian geometry taught in school, the origin (0, 0) typically sits at the bottom-left corner or the center of a grid, with positive Y values pointing upward. In video game engines and digital 2D screen rendering, this convention is inverted.

In GameMaker, the origin point (0, 0) of any Room is located at the top-left corner. The axis orientations operate as follows:

This inverted Y-axis is one of the most common stumbling blocks for beginners. Moving upward on the screen requires subtracting pixels from the instance's `y` coordinate, whereas descending or falling requires adding pixels. Therefore, when making a character jump upward, you must assign an initial negative vertical speed. As gravity acts over time, you add a positive value to that speed on every frame, transitioning the velocity from a high negative number (rapid ascent), to zero (the apex of the jump), and finally to positive values (freefall back toward the ground).

Jump Kinematics: Impulse, Gravity, and the Parabola

The trajectory traced by a body moving upward against constant gravity is a parabola. This jump arc consists of three distinct phases that must be modeled within the per-frame Step Event:

1. Initial Impulse: At the exact moment the player presses the jump key, an instantaneous negative vertical speed of substantial magnitude is applied to the character (for example, `vsp = -9`). At this precise moment, the character moves upward at maximum vertical velocity. 2. Deceleration and the Apex: On each successive frame, gravity adds a small positive increment to vertical speed (for example, `vsp += 0.4`). As frames tick by, vertical velocity approaches zero: -9, -8.6, -8.2, ..., -0.6, -0.2, 0. When `vsp` reaches exactly zero, the character reaches the apex—the peak of the trajectory—remaining suspended in the air for an infinitesimal fraction of a second. 3. Accelerated Fall: Immediately after the apex, gravity continues to accumulate. Now `vsp` becomes positive (+0.4, +0.8, +1.2...), and the character descends, gaining downward speed until colliding with a solid surface or reaching a predefined terminal velocity cap.

Variables Needed in the Create Event

To build this behavior in a clean, scalable way, avoid hardcoded numeric literals ("magic numbers") scattered across your logic. Instead, declare descriptive variables in the Create Event of your player object (`obj_player`). We will keep our previously declared horizontal variables (`hsp` and `walk_speed`) and add dedicated variables for vertical motion.

/// obj_player Create Event

// --- Horizontal movement variables (from previous lessons) ---
hsp = 0;
walk_speed = 4;

// --- Vertical movement and jumping variables ---
vsp = 0;              // Current vertical speed (pixels per step)
grav = 0.4;           // Constant gravitational acceleration
jump_speed = 9;       // Upward jump impulse magnitude (pixels upward)
vsp_max = 12;         // Maximum terminal fall velocity (prevents falling too fast)

// --- Temporary ground reference variable ---
// Note: Module 5 covers formal solid tile and object collisions.
// For now, we use a fixed Y baseline as a temporary test floor.
ground_y = 500;

Let's break down the role of each newly declared vertical variable:

• `vsp`: Represents the vertical offset the object will experience during the current frame. Initialized to 0, meaning the character starts vertically at rest. • `grav`: The per-step increment added to `vsp`. A value between 0.3 and 0.6 typically yields a classic platformer feel that is neither too floaty nor too abrupt. • `jump_speed`: Determines jump strength. Defined as a positive number (9); when applied as an upward impulse, we negate it (`-jump_speed`). • `vsp_max`: Terminal velocity. In an uncapped physics simulation, falling from a great height accumulates so much downward velocity that the character could tunnel through thin platforms in a single step or become uncontrollable. Capping `vsp` guarantees stability. • `ground_y`: A temporary floor altitude within the Room (500 pixels from the top edge) so our character has a surface to stand on before we implement full collision systems with solid instances.

Input Handling: keyboard_check vs. keyboard_check_pressed

In the first lesson of this module, we explored GameMaker's various input functions. For jumping, the distinction between `keyboard_check` and `keyboard_check_pressed` is technically critical:

• `keyboard_check(key)` returns `true` continuously on every frame that the physical key remains held down. This is ideal for walking or running laterally, where movement should sustain as long as the key is pressed. • `keyboard_check_pressed(key)` returns `true` exclusively on the single frame in which the key transitions from released to pressed. If the player continues holding the key down for several seconds, the function returns `false` on every subsequent frame until the key is released and pressed again.

💡 Golden Rule: Always use keyboard_check_pressed to trigger a jump impulse. If keyboard_check were used instead, the code would reapply the jump impulse on every single frame while the spacebar is held, rocketing the character upward like a missile without being affected by gravity until the key is released.

Structuring Physics in the Step Event

The Step Event runs continuously at the game's room speed (typically 60 frames per second). Code inside this event should follow a strict, logical pipeline of gathering input, running calculations, and applying motion:

1. Input Gathering: Read the keyboard or gamepad state into local boolean variables. 2. Horizontal Processing: Compute `hsp` based on directional inputs. 3. Ground Detection: Check whether the character is currently standing on solid ground. 4. Jump Processing: Apply the upward impulse only if the jump input fired and the character is grounded. 5. Gravity Application: Increase `vsp` by `grav`, clamping to `vsp_max`. 6. Coordinate Updates: Update the instance's built-in `x` and `y` coordinates by adding `hsp` and `vsp`.

Here is the complete, annotated Step Event implementation for `obj_player`:

/// obj_player Step Event

// --------------------------------------------------------
// 1. INPUT GATHERING
// --------------------------------------------------------
var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));
var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
var _key_jump  = keyboard_check_pressed(vk_space) || keyboard_check_pressed(ord("W"));

// --------------------------------------------------------
// 2. HORIZONTAL MOVEMENT
// --------------------------------------------------------
var _move_dir = _key_right - _key_left;
hsp = _move_dir * walk_speed;

// Flip sprite horizontally based on movement direction
if (_move_dir != 0) {
    image_xscale = _move_dir;
}

// --------------------------------------------------------
// 3. TEMPORARY GROUND CHECK AND JUMPING
// --------------------------------------------------------
// Check if the character is at or below the floor baseline
var _is_on_ground = (y >= ground_y);

if (_is_on_ground) {
    // Grounded: lock vertical position to floor and zero out residual speed
    y = ground_y;
    vsp = 0;
    
    // Check for jump input while grounded
    if (_key_jump) {
        vsp = -jump_speed; // Apply negative upward impulse
    }
} else {
    // Airborne: apply downward gravitational acceleration
    vsp += grav;
    
    // Cap fall speed at terminal velocity
    if (vsp > vsp_max) {
        vsp = vsp_max;
    }
}

// --------------------------------------------------------
// 4. POSITION UPDATES
// --------------------------------------------------------
x += hsp;
y += vsp;

Let's examine how each logic block operates. The condition `var _is_on_ground = (y >= ground_y);` evaluates whether the player has touched or passed the baseline floor height. When true, we eliminate any lingering downward velocity (`vsp = 0`) and prevent the character from sinking by snapping `y = ground_y`.

Inside that grounded condition, we evaluate `if (_key_jump)`. Because jumping is gated strictly behind `_is_on_ground`, we solve the classic "infinite jump" exploit: the player cannot jump while already airborne. Once the impulse triggers (`vsp = -jump_speed`), on the very next frame `y` updates via `y += vsp`, making `y` smaller than `ground_y`. Instantly, `_is_on_ground` evaluates to false, directing execution to the `else` branch where gravity acts until the parabolic arc brings the character back to earth.