Ground Contact Detection (Grounded)

Ground Contact Detection (Grounded): Fundamentals and Purpose

In 2D platformer development, one of the most fundamental questions the game engine must answer on every single frame is: is the character standing on a solid surface, or are they suspended in mid-air? To the human eye, this is obvious simply by looking at the screen; however, to the processor, an object is merely a collection of numerical coordinates (x, y) and a bounding box. The computer never assumes the character is 'standing' unless we write an explicit logical check to verify it.

Knowing whether the player is resting on solid ground—a state universally referred to as being 'grounded'—is the cornerstone upon which nearly every core platformer mechanic rests. Without a reliable way to detect the ground, the character could perform infinite jumps in mid-air simply by mashing the jump button, float erratically, or play a walking animation while plummeting into a pit. Ground detection is also essential for resetting mechanics like double jumps, applying proper horizontal friction, and triggering landing impact sound effects.

In the previous lessons of this module, we configured constant downward acceleration via a gravity variable (`grav`) and resolved vertical physical contact against solid objects (`obj_solid`), zeroing out vertical speed (`vspd = 0`) to prevent the avatar from clipping through platforms. In this lesson, we will take our character's architecture a step further: we will introduce a dedicated boolean flag (`is_grounded`), explain how to query the collision engine one pixel below the player's feet without altering their actual position, and organize the code so that ground state remains consistent throughout the entire frame cycle.

What Is a Boolean Flag in GML?

In computer science and software development, a flag is a variable that can hold only one of two possible states: true (`true`) or false (`false`). In GameMaker Language (GML), booleans are handled internally as numbers where `true` equals 1 and any value less than or equal to 0 evaluates to `false`. Nonetheless, writing clean, readable code requires using the explicit constants `true` and `false`, or evaluating conditional expressions directly.

By creating a boolean flag like `is_grounded`, we abstract a complex geometric condition into a simple binary answer accessible anywhere in our project. Instead of running expensive collision checks every time the code needs to know if the player can jump, play footstep sounds, or switch from a 'falling' sprite to an 'idle' sprite, the geometric check runs only once per frame and stores the result in the boolean variable.

This separation between physics detection and decision-making not only makes the code cleaner and easier for beginners to grasp, but also saves processing power and prevents logical bugs such as race conditions or desynced states within the same frame.

The Bottom-Pixel Technique: place_meeting(x, y + 1, obj_solid)

To determine whether a body rests on a surface without being embedded inside it, we must run a hypothetical query. If we tested `place_meeting(x, y, obj_solid)`, the function would return `false` while the character is resting properly, because the vertical collision algorithm we developed in the previous lesson ensures the player is placed in tangential contact with the surface without penetrating it by even a single pixel.

If `place_meeting(x, y, obj_solid)` were to return `true`, it would mean the character is stuck inside the floor or wall, which indicates a collision bug. Therefore, the industry-standard technique is to ask what would happen if we shifted the player exactly one pixel downward along the vertical axis: `place_meeting(x, y + 1, obj_solid)`.

The built-in function `place_meeting(x_virtual, y_virtual, object)` does not modify the instance's actual `x` and `y` position variables. Under the hood, it temporarily shifts the instance's collision mask to the specified coordinates, checks whether it overlaps with the mask of any instance of the given object (`obj_solid` in our case), and returns a boolean value (`true` or `false`). Immediately afterward, the collision mask returns to its original position without anything visible changing on screen.

By adding 1 to the vertical coordinate (`y + 1`), we are essentially asking the physics engine: 'If the character were to take a microscopic 1-pixel step downward, would it collide with a solid object?' If the answer is yes, the player is zero pixels away from the floor—meaning they are grounded. If the answer is no, the player is more than one pixel away from the nearest floor—meaning they are airborne.

Declaration and Initial Setup in the Create Event

Continuing the step-by-step architecture of our retro platformer project, open the player object (`obj_player`). In its **Create** event, make sure to initialize the `is_grounded` variable. A golden rule in GameMaker: any variable evaluated in a recurring event like **Step** must first be declared in **Create** to avoid compile-time errors or uninitialized variable crashes.

Here is how `obj_player`'s **Create** event should look, keeping the horizontal movement, vertical movement, and jump variables we built across Module 4 and earlier lessons in Module 5:

/// obj_player Create Event

// --- Horizontal movement variables ---
move_spd = 4;        // Maximum horizontal movement speed in pixels per frame
hspd = 0;            // Current horizontal speed

// --- Vertical movement and physics variables ---
vspd = 0;            // Current vertical speed
grav = 0.3;          // Gravity acceleration applied each frame
jsp = -7.5;          // Jump impulse force (negative moves upward)
max_vspd = 10;       // Terminal fall speed

// --- Logical state flags ---
is_grounded = false; // Indicates whether the player is currently touching the ground

When the player instance is created in the room, we set `is_grounded = false` as a safeguard. We don't assume the character spawns touching the floor; we let the very first frame evaluate the environment and determine the true ground state automatically.

Execution Order in the Step Event

In game development, the order of statements within the **Step** event is paramount. A typical physics pipeline consists of four sequential stages that must execute in this exact sequence:

If we attempted to evaluate `is_grounded` before calculating and resolving vertical collisions, the variable would hold the previous frame's state. This causes an imperceptible one-frame lag that can lead to subtle glitches in jumping or animations.