Horizontal Collisions with Solids

Step-by-Step Project Implementation

Now let's integrate this logic into our retro platformer project in a clean, modular way. Make sure your Asset Browser contains the necessary resources before adding the code.

1. Create spr_wall: Make a 32x32 pixel sprite styled as a stone or brick tile. Keep the origin at Top Left (x: 0, y: 0) and verify under Collision Mask that the Mode is set to "Automatic" and the Type is set to "Rectangle".

2. Create obj_wall: Create a new object, name it obj_wall, and assign it spr_wall. Leave the "Solid" checkbox unchecked in the object properties; that checkbox is tied to GameMaker's legacy drag-and-drop collision system and can cause unexpected behavior with custom scripts.

3. Review obj_player's Create Event: In our player object, confirm that the horizontal movement, acceleration, and base speed variables from earlier lessons are properly initialized.

// ====================================================================
// OBJECT: obj_player
// EVENT: Create
// ====================================================================

// Horizontal movement variables
hsp = 0;              // Current horizontal speed in pixels per frame
move_speed = 4;       // Player's maximum horizontal speed

// Gravity and vertical variables (from previous lesson)
vsp = 0;              // Current vertical speed
grav = 0.3;           // Gravitational acceleration
grav_max = 8;         // Terminal fall velocity

4. Structure obj_player's Step Event: The Step event should follow three strict, sequential stages: Input gathering and velocity calculation, Collision detection and resolution, and Final coordinate updates. Below is the complete block with horizontal collision handling integrated.

// ====================================================================
// OBJECT: obj_player
// EVENT: Step
// ====================================================================

// --------------------------------------------------------------------
// STAGE 1: INPUT AND INTENDED VELOCITY
// --------------------------------------------------------------------
// Read keyboard input (arrow keys or A/D)
var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));

// Calculate net direction (-1, 0, 1)
var _move = _key_right - _key_left;

// Determine desired horizontal speed
hsp = _move * move_speed;

// Apply preliminary gravity on the vertical axis (covered in Lesson 1)
vsp += grav;
if (vsp > grav_max) {
    vsp = grav_max;
}

// --------------------------------------------------------------------
// STAGE 2: HORIZONTAL COLLISION DETECTION AND RESOLUTION
// --------------------------------------------------------------------
// Check if projected position (x + hsp) collides with obj_wall
if (place_meeting(x + hsp, y, obj_wall)) {
    // If a collision lies along that span, step pixel-by-pixel
    // using sign(hsp) to advance exactly 1 pixel toward the obstacle
    while (!place_meeting(x + sign(hsp), y, obj_wall)) {
        x += sign(hsp);
    }
    
    // Once the player is flush against the surface (1 pixel away from overlap),
    // cancel horizontal speed completely for this frame
    hsp = 0;
}

// --------------------------------------------------------------------
// STAGE 3: APPLY MOVEMENT
// --------------------------------------------------------------------
// Apply resolved horizontal movement to actual position
x += hsp;

// (Note: Vertical resolution and vsp handling are detailed in the next lesson)
y += vsp;

Edge Cases, Common Pitfalls, and Optimization

As your project grows in scope, this basic collision logic can run into edge cases that cause unwanted behavior or severe performance drops if left unaddressed.

1. Infinite Loop Risk with sign(0)

If hsp ever equals 0 when the collision branch is reached (for instance, due to external position nudges or physics impulses from other objects), sign(0) returns 0. Inside a while loop advancing by sign(hsp), x += 0 would never change the instance's position, the collision condition would never change, and the game would hang in an infinite loop, freezing GameMaker's main thread.

To guard against this, wrap the check in a guard clause ensuring horizontal speed is non-zero (hsp != 0), or verify that its absolute value exceeds a minimum threshold:

if (hsp != 0) {
    if (place_meeting(x + hsp, y, obj_wall)) {
        while (!place_meeting(x + sign(hsp), y, obj_wall)) {
            x += sign(hsp);
        }
        hsp = 0;
    }
}

2. Grouping Collision Objects with Parents

In a full platformer, obj_player collides with far more than static walls—locked doors, breakable crates, metal platforms, and stone pillars all share physical solidity. Writing a separate if (place_meeting(...)) block for every distinct object in the Step event is poor architecture: it wastes CPU cycles and makes the code difficult to maintain.

The solution is object inheritance using Parents in GameMaker. Create an empty object called obj_solid or par_solid (with no sprite and no code). Then, on every solid obstacle (obj_wall, obj_block_wood, obj_iron_gate), open its properties and set its Parent to obj_solid.

Thanks to GameMaker's inheritance hierarchy, place_meeting(x + hsp, y, obj_solid) checks for collisions against obj_solid and any of its children in one go, consolidating your entire horizontal collision pass into a single, clean check.

3. Fractional Speeds and Sub-Pixel Precision

When you introduce acceleration curves or friction (such as move_speed = 3.75), position and speed variables accumulate fractional values. In modern versions of GameMaker, place_meeting handles sub-pixel positions using floating-point checks aligned with the rendering pipeline. However, stepping x += sign(hsp) when x has a fractional component (like x = 12.4) yields 13.4, 14.4, and so on.

For standard pixel-art platformers on an integer grid, this rarely causes visual issues. But if you notice sub-pixel jitter or microscopic seams when stopping, common remedies include snapping the coordinate to an integer upon collision or maintaining a dedicated fractional accumulator (a pattern we explore in our advanced physics optimization module).

Practical Exercises

Complete the following three hands-on exercises in your GameMaker project to solidify what you have learned.

Exercise 1: Observe the Gap Problem Directly In obj_player, temporarily comment out the while loop with double slashes (//), leaving only if (place_meeting(x + hsp, y, obj_wall)) { hsp = 0; }. Set your movement speed to an odd, high value like move_speed = 7. Run the game, dash straight into a wall, and observe how often the character stops with empty space between its sprite and the wall. Then uncomment the while loop and verify that contact is pixel-perfect every time, regardless of running speed. Success criteria: With the while loop restored, the character touches the wall texture with zero pixel separation whether approaching from the left or right.

Exercise 2: Create a Breakable Block Using Parents Create a new 32x32 sprite named spr_crate with a wooden box texture. Create an object called obj_crate and assign it the sprite. Next, create an empty parent object named obj_solid, and set obj_solid as the Parent for both obj_wall and obj_crate. Update obj_player's Step event to check against obj_solid instead of obj_wall. Success criteria: Place crates and walls in your room. The player must stop flush against both objects identically without any crate-specific collision code added to obj_player.

Exercise 3: Visual Debugging with a Collision Vector Open obj_player's Draw event. Make sure to call draw_self() first so the sprite continues rendering. Right below it, draw a colored line showing where the collision check is projecting each frame using draw_line_color(x, y, x + hsp, y, c_red, c_red). Success criteria: Moving left or right in the room should project a visible red line from the player's origin forward, showing the exact distance checked ahead before committing movement.