Applying Constant Gravity

Introduction to Physics Simulation in 2D Video Games

In 2D platformer development, gravity is not merely a planetary force of attraction as described by Newtonian physics; it is, first and foremost, a game feel tool. The way a character falls, the rate at which they accelerate downward, and how quickly they respond to player inputs directly define the game feel. If gravity is too low, the character feels floaty, imprecise, and difficult to control—as if walking on the Moon. Conversely, if downward acceleration is excessive, jumps feel stiff, heavy, and unpredictable.

To build this mechanic on a rock-solid technical foundation, you must understand how GameMaker handles spatial coordinates and execution timing. Unlike a continuous scientific simulation, a game engine updates the world state at discrete intervals called frames or 'steps.' In each of these cycles, our code must deterministically compute how much vertical velocity increases and how that change affects the object's vertical position. In this lesson, we will implement this system step by step using native GML Code, intentionally bypassing the engine's built-in automatic systems to give you complete control over movement and future collisions.

GameMaker's Coordinate System and the Inverted Y-Axis

One of the first conceptual hurdles beginners face in game programming is the orientation of Cartesian axes. In traditional school mathematics, the origin point (0, 0) typically sits at the center or bottom-left corner of a Cartesian plane, where X increases to the right and Y increases upward. However, in computer graphics and in GameMaker specifically, the standard originates from how cathode-ray tube (CRT) monitors scanned lines across the screen: left to right, top to bottom.

Consequently, in a GameMaker Room, the origin (x = 0, y = 0) is located at the top-left corner of the room. This has two immediate and essential consequences for movement programming:

1. The horizontal axis (x) works intuitively: increasing x moves the object right, while decreasing x moves it left. 2. The vertical axis (y) is inverted compared to standard math: increasing y moves the object downward (toward the bottom of the screen), while subtracting or decreasing y moves the object upward (toward the ceiling of the room).

Understanding this inverted Y-axis is an absolute prerequisite for programming gravity. If gravity is an acceleration pushing bodies toward the floor, in GameMaker that acceleration must be a positive value added progressively to the character's vertical position on every elapsed frame.

Built-in Variables vs. Custom Variables in GameMaker

Anyone browsing basic GameMaker documentation will quickly discover that the engine provides built-in variables like 'vspeed', 'hspeed', 'speed', 'direction', and 'gravity'. If you assign a value to 'gravity' (for example, gravity = 0.5), GameMaker automatically applies downward acceleration to the instance without requiring a single additional line of math. However, in professional and indie 2D platformer development, using these built-in variables is strongly discouraged.

The reason lies in the engine's internal event execution order. When you use 'vspeed' and 'gravity', GameMaker automatically adds velocity to the 'y' position between the Step event and the End Step event, before you have a chance to intervene and check whether the character is about to pass through a platform, a hazard, or a solid wall. This leads to erratic behavior such as characters sinking into floors, visual jitter, and game-breaking collision errors.

The standard, robust solution is to manage speed and acceleration using custom instance variables such as 'vspd' (vertical speed) and 'grav' (gravitational acceleration). By calculating velocity accumulation and position updates ourselves inside the Step event, we retain full control over every pixel traveled before the engine renders the frame.

💡 Golden Rule: In high-precision 2D platformers, never mix built-in variables (vspeed, hspeed, gravity) with custom movement variables (vspd, hspd, grav). Keep full control inside your own scripts and events.

Defining Variables in obj_player's Create Event

The first technical step is initializing the variables that define our main character's physical behavior, which we will call 'obj_player'. Remember that the Create event runs exactly once at the moment the object instance is instantiated in the Room. It is the ideal place to declare movement properties, parameters, and initial values.

Let's open 'obj_player' in the GameMaker workspace, select the Create event, and add the following GML Code block:

// obj_player Create Event

// Movement speeds
hspd = 0;              // Current horizontal speed in pixels per frame
vspd = 0;              // Current vertical speed in pixels per frame

// Acceleration parameters and physical limits
grav = 0.3;            // Gravity constant (acceleration per frame)
vspd_max = 9.0;        // Terminal velocity or maximum falling speed

// Horizontal control and jump parameters (declared in Module 4)
walk_spd = 3.5;        // Maximum walking speed
jump_spd = -7.5;       // Initial jump impulse (negative to move upward)

Let's examine the role of each variable introduced for gravity:

- 'vspd': Stores the number of pixels the instance should move vertically on the current frame. A value of 0 indicates rest; a negative value (for example, -7.5) means the character is rising; a positive value (for example, 4.2) means they are descending. - 'grav': Represents gravitational acceleration. On every frame, we add this amount to 'vspd'. A value of 0.3 pixels/frame² delivers a responsive, snappy feel typical of classic 16-bit platformers. - 'vspd_max': Represents terminal velocity. In the physical world, air drag prevents falling bodies from accelerating infinitely. In a video game, a terminal velocity is critical not just for aesthetics, but to prevent characters from falling so fast that they tunnel right through thin platforms in a single frame (a phenomenon known as 'tunneling').

Implementing Gradual Acceleration in the Step Event

The Step event runs constantly and periodically: exactly once per game frame. If your project runs at 60 frames per second (fps), the code inside the Step event is evaluated and executed 60 times every second. This is where we turn mathematical acceleration into visible movement.

The fundamental kinematic formula for this process consists of two sequential steps:

1. Update velocity with acceleration: new_velocity = current_velocity + acceleration 2. Update position with velocity: new_position = current_position + new_velocity

Here is how that translates into clean, efficient code within the Step event of 'obj_player':

// obj_player Step Event

// 1. Gradually apply gravity
vspd += grav;

// 2. Clamp to terminal velocity
if (vspd > vspd_max) {
    vspd = vspd_max;
}

// 3. Apply vertical movement to spatial coordinate
y += vspd;

The '+=' operator is shorthand for 'vspd = vspd + grav;'. In every 1/60th of a second cycle, 'vspd' increases by 0.3 units. When this value exceeds the threshold set in 'vspd_max' (9.0 pixels per frame), the 'if' condition steps in and caps it, keeping the speed locked at its maximum ceiling.

Using Native Functions to Bound Velocity: clamp() and min()

While the 'if' statement is completely valid and intuitive for beginners, GameMaker provides built-in math functions that let you write more concise, expressive code. Among the most useful here are 'min()' and 'clamp()'.

The 'min(val1, val2, ...)' function returns the smallest value among all supplied arguments. Consequently, we can combine the gravity increment and the terminal velocity cap into a single line:

// Clean alternative using min()
vspd = min(vspd + grav, vspd_max);

If 'vspd + grav' evaluates to 4.5 and 'vspd_max' is 9.0, the function chooses 4.5. However, once 'vspd + grav' reaches 9.3, the function discards that value and returns 9.0, ensuring the character never exceeds the allowed maximum falling speed.

Meanwhile, 'clamp(val, min, max)' constrains a numerical value between a lower and an upper bound. This is particularly helpful when you also want to ensure the character doesn't launch upward at an uncontrolled speed during powered jumps or bounce pads:

// Bidirectional alternative using clamp()
vspd += grav;
vspd = clamp(vspd, -12.0, vspd_max);