Refining Controls and Movement Variables

The Importance of Game Feel and Responsive Controls

In 2D platformer development, the difference between a frustrating experience and a deeply rewarding one rarely comes down to art style or storyline complexity; it almost entirely hinges on what game designers call "game feel" or control responsiveness. When players press a button on their keyboard or gamepad, they expect an immediate, predictable, and fair reaction. If the character takes a fraction of a second too long to stop, fails to jump because the button was hit a millisecond before landing, or moves along an unyielding airborne arc, players will not blame their own reflexes—they will blame the game.

Up to this point in the module, you have built the essential foundations: polling keyboard and gamepad inputs, calculating horizontal direction, flipping sprites horizontally with scale, and applying a simple vertical impulse to leave the ground. However, instantaneous velocity (where the character snaps from 0 to full speed in a single frame and halts on a dime) can feel stiff or overly robotic for many gameplay styles. Likewise, a fixed-height jump prevents players from modulating their trajectory to clear low ceilings or land precisely on tight ledges.

The goal of this lesson is to refine those rudimentary mechanics. You will learn how to structure fine-tuning variables for acceleration and friction, allow jump height to scale with how long the button is held (variable jump), and implement two cornerstone input-forgiveness techniques in modern platformer design: coyote time and jump buffering.

💡 While GameMaker offers a visual scripting alternative called GML Visual (using interconnected action blocks and icons), we will continue using GML Code throughout this course. Writing raw code grants complete control over the mathematical order of operations and makes fine-tuning physical formulas significantly easier.

Controlled Inertia: Horizontal Acceleration and Friction

In the previous lesson on horizontal movement, we assigned the target speed directly by multiplying the direction vector by maximum speed: whenever the player pressed right, the horizontal velocity jumped immediately from zero to, say, four pixels per frame. For strict arcade-style games, this provides immediate responsiveness, but it often lacks weight and organic motion.

To give the character a smooth transition without sacrificing responsiveness, we introduce two complementary variables: acceleration and friction. Acceleration defines how many pixels per frame we add to current velocity until reaching top speed. Friction dictates how many pixels per frame we strip away when no directional input is held, bringing the character smoothly down to zero.

A common beginner mistake is subtracting friction directly without checking if the value crosses zero. For instance, if the character is moving right at 0.2 pixels per frame and we apply 0.5 friction to the left, the resulting speed becomes -0.3, causing the character to jitter or slide backward infinitely. To prevent this, we write safe mathematical approximations or use precise logical comparisons with standard GML functions.

Horizontal Setup Variables in the Create Event

Open your primary player object, `obj_player`, and open its **Create** event. We will reorganize and expand the movement variables created in previous lessons to allow easy calibration from a single location in your project.

/// obj_player Create Event

// --- HORIZONTAL MOVEMENT VARIABLES ---
vel_x = 0;              // Current horizontal speed in pixels per frame
vel_x_max = 3.5;        // Maximum reachable horizontal speed
acel_x = 0.4;           // Speed increase per frame while holding direction
fric_x = 0.35;          // Speed reduction per frame after releasing controls

// --- VERTICAL MOVEMENT AND GRAVITY VARIABLES ---
vel_y = 0;              // Current vertical speed
vel_y_max = 8.0;        // Terminal fall speed cap
gravedad = 0.35;        // Constant downward force
vel_salto = -6.5;       // Initial jump impulse (negative value moves upward)

Pay close attention to these numeric values: `acel_x` is set to 0.4 and `fric_x` to 0.35. At a standard 60 frames per second, an increment of 0.4 means the character takes under ten frames (about one-sixth of a second) to ramp up from a dead stop to the top speed of 3.5. This provides a subtle sense of momentum without feeling sluggish or introducing perceptible input lag.

Calculating Acceleration and Deceleration in the Step Event

Inside the **Step** event of `obj_player`, replace the direct horizontal speed assignment with a conditional block that checks whether the player is actively providing movement input.

/// obj_player Step Event snippet: Horizontal movement

// 1. Directional input collection (-1 for left, 1 for right, 0 if idle)
var _tecla_der = keyboard_check(vk_right) || keyboard_check(ord("D"));
var _tecla_izq = keyboard_check(vk_left) || keyboard_check(ord("A"));
var _dir = _tecla_der - _tecla_izq;

// 2. Horizontal speed modification using acceleration or friction
if (_dir != 0) {
    // Player wants to move: accelerate toward target direction
    vel_x += _dir * acel_x;
    
    // Ensure speed does not exceed the allowed cap
    vel_x = clamp(vel_x, -vel_x_max, vel_x_max);
} else {
    // Player released controls: apply friction to stop
    if (vel_x > 0) {
        vel_x = max(0, vel_x - fric_x);
    } else if (vel_x < 0) {
        vel_x = min(0, vel_x + fric_x);
    }
}

Let's examine the native `clamp(val, min, max)` function used here. It evaluates a value and ensures it never drops below `min` or climbs above `max`. In our code, it prevents continuous additions of `acel_x` from accelerating the player indefinitely. In the friction block, `max(0, vel_x - fric_x)` ensures that subtracting friction from a positive speed will never drop below zero, eliminating jitter or unwanted backward sliding.

Variable Jump: Airborne Adaptability

In classics like Super Mario Bros., Celeste, and Mega Man, jump height depends on how long the player holds the button: a quick tap produces a short hop to avoid low ceilings or settle onto nearby ledges, while holding the button propels the character to the peak of their jump arc. If jumps were always a fixed height, players would lose significant tactical freedom when navigating platforming routes.

The most elegant and responsive way to achieve this without altering base gravity is cutting upward momentum the exact moment the player releases the button. When the jump key is released while the character is still traveling upward (meaning vertical velocity `vel_y` is negative), we multiply that velocity by a fractional multiplier (such as 0.4 or 0.5) or clamp it to a smaller threshold.

Implementing Jump Cut in GML

To implement this behavior, first declare a multiplier variable in the **Create** event of `obj_player`, defining how much upward momentum remains when the button is released early:

/// Added to obj_player Create Event
multiplicador_corte_salto = 0.45; // Percentage of upward vertical speed retained upon releasing the button

Next, in the **Step** event, detect when the jump key is released using `keyboard_check_released()`:

/// obj_player Step Event snippet: Variable jump

// Detect release of common jump keys
var _solto_salto = keyboard_check_released(vk_space) || keyboard_check_released(ord("W")) || keyboard_check_released(vk_up);

// If player releases the button while ascending, dampen the ascent
if (_solto_salto && vel_y < 0) {
    vel_y = vel_y * multiplicador_corte_salto;
}

Notice the condition `vel_y < 0`. In GameMaker's 2D coordinate system, the Y axis increases downward; therefore, negative vertical velocity indicates upward motion on screen. If the player releases the button while already falling back toward the ground (`vel_y >= 0`), the condition evaluates to false, allowing downward gravity to continue uninterrupted.