Player-Enemy Collision System

Introduction: The Continuous Contact Dilemma in 2D Video Games

In the previous lesson, we brought our first enemy to life with a basic patrol routine. Right now, however, the enemy and player act like ghosts passing through each other on screen without interacting—or worse, if solid collisions are enabled without damage logic, the enemy pushes the player around like a moving wall. The core design principle of a traditional platformer is that unwanted contact with a hazard penalizes the player by reducing their health or costing a life.

For a beginner, the initial instinct is usually: "When the player touches the enemy, subtract 1 hit point." However, GameMaker runs its main loop at 60 frames per second (60 FPS), meaning collision functions return true on every single frame where hitboxes overlap. If the player stays in contact with an enemy for just half a second (30 frames), the system rapidly depletes 30 hit points. This issue is known as uncontrolled continuous contact damage.

To solve this problem and deliver a fair, polished gameplay experience, classic video games rely on three coordinated mechanics: discrete collision detection, applying a knockback impulse that physically separates the characters, and a grace period of temporary immunity (commonly known as "i-frames" or invulnerability frames). During this grace window, the player cannot take further damage and receives clear visual feedback (usually an intermittent blinking effect) signaling their invulnerable state.

Detection Methods in GameMaker: Collision Event vs. Step Code

GameMaker provides two primary ways to handle collisions between objects. The first is the native Collision Event, accessible from the object's event panel. The second is manual verification using collision functions inside the Step event with GML Code. While both approaches work, professional projects and mechanics requiring precise mathematical control (such as knockback vectors and hurt states) benefit from centralizing logic inside the Step event.

For our damage logic, we will use instance_place(). Unlike place_meeting(), which only tells us whether an overlap exists using a simple yes-or-no check, instance_place() returns the unique instance identifier (id) of the specific enemy touching the player. This information is vital because we need to know where that enemy is located relative to the player to calculate which direction the player should be knocked back after the hit.

Player Variable Setup (obj_player)

Before our character can handle damage, knockback, and invulnerability, we must initialize the appropriate variables in its Create event. Building upon the movement base established in earlier lessons (where variables like hspd, vspd, and walk_speed are already defined), we will add our health and damage management variables.

// --- obj_player Create Event ---

// Player health
hp_max = 3;
hp = hp_max;

// Temporary invincibility system (I-Frames)
is_invincible = false;           // Flag indicating whether player is invulnerable
invincible_timer = 0;            // Countdown timer in frames
invincible_duration = 90;        // Invincibility duration (90 frames = 1.5 seconds at 60 FPS)

// Hit knockback
knockback_speed_x = 4;           // Horizontal hit force
knockback_speed_y = -3;          // Small vertical pop upon taking damage
is_knockbacked = false;          // State flag for temporary loss of control
knockback_timer = 0;             // Duration of control loss
knockback_duration = 12;         // 12 frames (0.2 seconds) of hitstun

Let's break down the role of each variable. The invincible_duration variable sets how many frames the player stays protected. In a project running at 60 FPS, 90 frames equals exactly one and a half seconds (90 / 60 = 1.5 s). During this window, any further contact with enemies is completely ignored.

Meanwhile, is_knockbacked and knockback_timer temporarily disable the player's directional input. If player control were left enabled during knockback, pressing an opposite directional key would instantly cancel out the impact velocity, making hits feel floaty, rigid, and devoid of physical weight.

Detection and Response Logic in the Step Event

The Step event of obj_player needs a clean, orderly structure. First, update active timers; second, verify whether the player currently has movement control; and finally, if not currently invincible, check for enemy contact to trigger the hit sequence.

// --- obj_player Step Event snippet ---

// 1. UPDATE INVINCIBILITY AND KNOCKBACK TIMERS
if (is_invincible)
{
    invincible_timer -= 1;
    if (invincible_timer <= 0)
    {
        is_invincible = false;
    }
}

if (is_knockbacked)
{
    knockback_timer -= 1;
    if (knockback_timer <= 0)
    {
        is_knockbacked = false;
    }
}

// 2. PLAYER INPUT (Only allowed when not in hitstun)
if (!is_knockbacked)
{
    // Standard input reading
    var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
    var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));
    var _move_dir  = _key_right - _key_left;
    
    hspd = _move_dir * walk_speed;
    
    // Standard jump logic
    var _key_jump = keyboard_check_pressed(vk_space) || keyboard_check_pressed(ord("W"));
    if (_key_jump && is_grounded)
    {
        vspd = jump_speed;
    }
}

// 3. APPLY GRAVITY AND STANDARD PHYSICS
vspd += grv;

// 4. DETECT COLLISION WITH ENEMY
if (!is_invincible)
{
    // Check for collision with the patrolling enemy object
    var _enemy_hit = instance_place(x, y, obj_enemy_patrol);
    
    if (_enemy_hit != noone)
    {
        // Deduct health
        hp -= 1;
        
        // Trigger temporary invincibility
        is_invincible = true;
        invincible_timer = invincible_duration;
        
        // Trigger knockback hitstun
        is_knockbacked = true;
        knockback_timer = knockback_duration;
        
        // Determine horizontal push direction
        // If player is to the right of enemy, push right (+1)
        // If to the left, push left (-1)
        var _push_direction = sign(x - _enemy_hit.x);
        if (_push_direction == 0) _push_direction = 1; // Safeguard if X positions match exactly
        
        hspd = _push_direction * knockback_speed_x;
        vspd = knockback_speed_y; // Small upward pop
    }
}

Let's examine the directional calculation: var _push_direction = sign(x - _enemy_hit.x);. The sign() function takes any real number and returns 1 if positive, -1 if negative, and 0 if zero. If the player's X position is greater than the enemy's X position (_enemy_hit.x), the subtraction produces a positive value, indicating the player is to the right; sign() returns 1, launching the player rightward. If the player is to the left, the result is negative, pushing them leftward. Adding the fallback if (_push_direction == 0) _push_direction = 1; ensures the player doesn't freeze in place if both origin points happen to land on the exact same pixel.

💡 Remember that horizontal and vertical movement code with solid collision handling must run AFTER computing these velocities. That way, if knockback launches the player into a solid wall, the collision system safely stops the player instead of letting them clip through level geometry.

Classic Platformer Distinction: The Stomp Mechanic

In many traditional platformers (such as Super Mario or Sonic), touching an enemy doesn't always penalize the player. If the player lands directly on top of an enemy from above, the enemy takes damage or gets defeated instead, and the player bounces upward to maintain momentum. This mechanic adds dynamic pacing and rewards precision.

To implement this behavior, we verify two spatial conditions before applying player damage: the player must be falling downward (vspd > 0), and the player's feet must be positioned above the enemy's head or center. When both criteria are met, we destroy or damage the enemy and rebound the player; otherwise, the regular damage and knockback routine runs.

Pay close attention to bbox_bottom - vspd <= _enemy_hit.bbox_top + 8. The built-in variable bbox_bottom represents the Y coordinate of the bottom edge of the player's bounding box. Subtracting vspd tells us where the player's feet were located on the previous frame. If on that previous frame the feet were level with or above the enemy's top bounding edge (bbox_top), we confirm that this was an intentional downward stomp rather than a side collision with late downward drift.