Sistema de colisión entre jugador y enemigos

Introducción: El dilema del contacto continuo en videojuegos 2D

En la clase anterior dimos vida a nuestro primer enemigo con una rutina de patrullaje básico. Sin embargo, en este momento el enemigo y el jugador son como fantasmas que se cruzan en pantalla sin interactuar, o peor aún, si configuramos una colisión sólida sin lógica de daño, el enemigo empujará al jugador como si fuera una pared móvil. El objetivo fundamental de un juego de plataformas tradicional es que el contacto no deseado con una amenaza penalice al jugador reduciendo su salud o haciéndolo perder una vida.

Para un principiante, la primera intuición suele ser: «Cuando el jugador toque al enemigo, restamos 1 punto de vida». No obstante, en un motor como GameMaker que ejecuta su bucle principal a 60 cuadros por segundo (60 FPS), la función de colisión devolverá verdadero durante cada fotograma en el que las cajas de colisión (hitboxes) se superpongan. Si el jugador permanece en contacto con el enemigo durante apenas medio segundo (30 fotogramas), el sistema restará 30 puntos de vida de forma fulminante. Este fenómeno se conoce como daño por contacto continuo descontrolado.

Para resolver este problema y ofrecer una experiencia de juego justa y profesional, los videojuegos clásicos recurren a tres mecanismos coordinados: la detección de la colisión discreta, la aplicación de un impulso de retroceso (knockback) que separa físicamente a los personajes, y un período de inmunidad temporal (popularmente conocido como «i-frames» o invulnerability frames). Durante este intervalo de gracia, el jugador no puede recibir daño adicional y recibe una señal visual clara (generalmente un parpadeo intermitente) que comunica su estado de invulnerabilidad.

Métodos de detección en GameMaker: Collision Event vs. Código en Step

GameMaker ofrece dos vías principales para gestionar colisiones entre objetos. La primera es el evento nativo de colisión (Collision Event), accesible desde el panel de eventos del objeto. La segunda es la verificación manual mediante funciones de colisión en el evento Step utilizando GML Code. Aunque ambas son válidas, en proyectos profesionales y mecánicas que requieren alta precisión matemática (como el cálculo de vectores de retroceso y estados de daño), se recomienda centralizar la lógica en el evento Step.

Para nuestra lógica de daño utilizaremos la función instance_place(). A diferencia de place_meeting(), que solo nos avisa si existe una colisión o no con un simple sí o no, instance_place() nos devuelve el identificador único (id) de la instancia concreta del enemigo que nos está tocando. Este dato es vital porque necesitamos saber en qué posición exacta se encuentra ese enemigo respecto al jugador para calcular la dirección hacia la que el jugador debe salir despedido por el impacto.

Configuración de variables en el Jugador (obj_player)

Para que nuestro personaje soporte daño, retroceso e inmunidad, primero debemos definir las variables correspondientes en su evento Create. Retomando la base de movimiento que construimos en los módulos anteriores (donde ya contamos con variables como hspd, vspd, walk_speed, etc.), agregaremos las variables de salud y control de daño.

// --- Evento Create de obj_player ---

// Salud del jugador
hp_max = 3;
hp = hp_max;

// Sistema de inmunidad temporal (I-Frames)
is_invincible = false;           // Bandera que indica si el jugador es invulnerable
invincible_timer = 0;            // Contador regresivo en fotogramas
invincible_duration = 90;        // Duración de la inmunidad (90 fotogramas = 1.5 segundos a 60 FPS)

// Retroceso por impacto (Knockback)
knockback_speed_x = 4;           // Fuerza horizontal del golpe
knockback_speed_y = -3;          // Pequeño salto vertical al recibir daño
is_knockbacked = false;          // Estado de pérdida temporal de control por golpe
knockback_timer = 0;             // Duración de la pérdida de control
knockback_duration = 12;         // 12 fotogramas (0.2 segundos) de parálisis por impacto

Analicemos con detalle el propósito de estas variables. La variable invincible_duration define cuántos fotogramas estará protegido el jugador. En un juego configurado a 60 FPS, 90 fotogramas equivalen exactamente a un segundo y medio (90 / 60 = 1.5 s). Durante este tiempo, cualquier contacto adicional con enemigos será completamente ignorado.

Por su parte, is_knockbacked y knockback_timer se encargan de deshabilitar brevemente los controles del teclado o mando del jugador. Si no deshabilitamos el control durante el retroceso, la pulsación del jugador en dirección contraria neutralizaría de inmediato el empuje del impacto, haciendo que el golpe se sienta rígido, falso y carente de peso físico.

Lógica de detección y respuesta en el Evento Step

El evento Step de obj_player debe estructurarse de manera ordenada. Primero debemos actualizar los temporizadores activos; luego verificar si el jugador tiene el control para moverse; y finalmente, si no es invencible, comprobar si está tocando a un enemigo para desencadenar el impacto.

// --- Fragmento en Evento Step de obj_player ---

// 1. ACTUALIZAR TEMPORIZADORES DE INMUNIDAD Y RETROCESO
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. ENTRADA DEL JUGADOR (Solo permitida si no está sufriendo retroceso)
if (!is_knockbacked)
{
    // Lectura normal de teclas (reutilizando variables del módulo 4)
    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;
    
    // Lógica de salto habitual
    var _key_jump = keyboard_check_pressed(vk_space) || keyboard_check_pressed(ord("W"));
    if (_key_jump && is_grounded)
    {
        vspd = jump_speed;
    }
}

// 3. APLICACIÓN DE GRAVEDAD Y FÍSICA HABITUAL
vspd += grv;

// 4. DETECCIÓN DE COLISIÓN CON EL ENEMIGO
if (!is_invincible)
{
    // Buscamos si existe colisión con el objeto enemigo patrullero
    var _enemy_hit = instance_place(x, y, obj_enemy_patrol);
    
    if (_enemy_hit != noone)
    {
        // Restar vida
        hp -= 1;
        
        // Activar la inmunidad temporal
        is_invincible = true;
        invincible_timer = invincible_duration;
        
        // Activar retroceso (Knockback)
        is_knockbacked = true;
        knockback_timer = knockback_duration;
        
        // Determinar la dirección del empuje horizontal
        // Si el jugador está a la derecha del enemigo, es empujado hacia la derecha (+1)
        // Si está a la izquierda, es empujado hacia la izquierda (-1)
        var _push_direction = sign(x - _enemy_hit.x);
        if (_push_direction == 0) _push_direction = 1; // Salvaguarda si coinciden exactamente en X
        
        hspd = _push_direction * knockback_speed_x;
        vspd = knockback_speed_y; // Pequeño salto hacia arriba
    }
}

Examinemos la línea de cálculo de dirección: var _push_direction = sign(x - _enemy_hit.x);. La función sign() toma cualquier número real y devuelve 1 si es positivo, -1 si es negativo, y 0 si es cero. Si la posición X del jugador es mayor que la posición X del enemigo (_enemy_hit.x), la resta da un valor positivo, lo que significa que el jugador está a la derecha del enemigo; sign() devuelve 1, proyectando a nuestro protagonista a la derecha. Si el jugador está a la izquierda, la resta es negativa, y el jugador es proyectado a la izquierda. Añadir la salvaguarda if (_push_direction == 0) _push_direction = 1; previene que el jugador quede inmóvil si ambos orígenes de coordenadas coinciden en el mismo píxel.

💡 Recuerda que el código de movimiento horizontal y vertical con detección de paredes sólidas (visto en el Módulo 5) debe ejecutarse DESPUÉS de calcular estas velocidades. De este modo, si el retroceso empuja al jugador contra una pared sólida, el sistema de colisión física evitará que atraviese el escenario.

Distinción clásica de plataformas: Aplastamiento superior (Stomp)

En muchos juegos de plataformas clásicos (como Super Mario o Sonic), el jugador no siempre recibe daño al tocar al enemigo. Si el jugador cae desde arriba sobre la cabeza del enemigo, es el enemigo quien resulta dañado o eliminado, y el jugador rebota para continuar su salto. Esta mecánica aporta dinamismo y premia la destreza del usuario.

Para implementar esta condición, antes de aplicar el daño al jugador debemos verificar dos condiciones geométricas: que el jugador esté cayendo (vspd > 0) y que la base del jugador se encuentre por encima del centro o cabeza del enemigo. Si ambas condiciones se cumplen, destruimos o dañamos al enemigo y hacemos rebotar al jugador; de lo contrario, el jugador recibe el daño y el retroceso habituales.

Fíjate en la comprobación bbox_bottom - vspd <= _enemy_hit.bbox_top + 8. bbox_bottom representa la coordenada Y del borde inferior de la máscara de colisión del jugador. Restar vspd nos dice dónde estaba el pie del jugador en el fotograma anterior. Si en el fotograma anterior los pies estaban a la altura o por encima del borde superior del enemigo (bbox_top), confirmamos que la trayectoria fue un pisotón legítimo y no una colisión lateral con caída tardía.