Colisiones horizontales con sólidos

Implementación paso a paso en el proyecto

Veamos ahora cómo integrar esta lógica de manera limpia y modular en nuestro proyecto de plataformas retro. Asegúrate de tener creados los recursos necesarios en el Asset Browser antes de proceder con el código.

1. Creación del recurso spr_wall: Crea un sprite de 32x32 píxeles con la apariencia de un bloque de piedra o ladrillo. Deja el origen en Top Left (x: 0, y: 0) y verifica en sus propiedades de Collision Mask que el modo sea «Automatic» y la forma «Rectangle».

2. Creación del objeto obj_wall: Crea un nuevo objeto, nómbralo obj_wall y asígnale el sprite spr_wall. No necesitas marcar la casilla «Solid» que incluye GameMaker en la interfaz de objetos; dicha casilla pertenece al sistema de físicas clásico de arrastrar y soltar (DnD/GML Visual heredado) y puede generar comportamientos erráticos con nuestro sistema manual de scripts.

3. Revisión del evento Create de obj_player: En el objeto de nuestro jugador, nos aseguramos de tener declaradas las variables de velocidad horizontal, aceleración y velocidad base calculadas en las lecciones anteriores.

// ====================================================================
// OBJETO: obj_player
// EVENTO: Create
// ====================================================================

// Variables de movimiento horizontal
hsp = 0;              // Velocidad horizontal actual en píxeles por fotograma
move_speed = 4;       // Velocidad horizontal máxima del jugador

// Variables de gravedad y verticales (de la lección anterior)
vsp = 0;              // Velocidad vertical actual
grav = 0.3;           // Aceleración de la gravedad
grav_max = 8;         // Velocidad terminal de caída

4. Estructuración del evento Step de obj_player: El evento Step debe organizarse en tres fases secuenciales estrictas: Lectura de entradas y cálculo de intenciones, Gestión y resolución de colisiones, y Aplicación final de coordenadas. El siguiente código muestra el bloque completo con la colisión horizontal integrada.

// ====================================================================
// OBJETO: obj_player
// EVENTO: Step
// ====================================================================

// --------------------------------------------------------------------
// FASE 1: ENTRADAS Y CÁLCULO DE VELOCIDAD
// --------------------------------------------------------------------
// Lectura del teclado (flechas o teclas A/D)
var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));

// Cálculo de la dirección neta (-1, 0, 1)
var _move = _key_right - _key_left;

// Determinación de la velocidad horizontal deseada
hsp = _move * move_speed;

// Aplicación preliminar de gravedad en el eje vertical (explicada en la lección 1)
vsp += grav;
if (vsp > grav_max) {
    vsp = grav_max;
}

// --------------------------------------------------------------------
// FASE 2: DETECCIÓN Y RESOLUCIÓN DE COLISIONES HORIZONTALES
// --------------------------------------------------------------------
// Verificamos si en la posición proyectada (x + hsp) hay contacto con obj_wall
if (place_meeting(x + hsp, y, obj_wall)) {
    // Si hay colisión global en ese trayecto, avanzamos píxel a píxel
    // usando sign(hsp) para movernos exactamente 1 píxel hacia el obstáculo
    while (!place_meeting(x + sign(hsp), y, obj_wall)) {
        x += sign(hsp);
    }
    
    // Una vez que el jugador está en contacto exacto (a 1 píxel de solaparse),
    // cancelamos por completo la velocidad horizontal para este fotograma
    hsp = 0;
}

// --------------------------------------------------------------------
// FASE 3: APLICACIÓN DEL MOVIMIENTO
// --------------------------------------------------------------------
// Aplicamos el desplazamiento horizontal resultante a la posición real
x += hsp;

// (Nota: La resolución vertical y la aplicación de vsp se profundizarán en la siguiente lección)
y += vsp;

Casos especiales, errores comunes y optimización

A medida que los juegos crecen en complejidad, el sistema básico de colisiones puede tropezar con situaciones singulares que causan comportamientos no deseados o caídas drásticas de rendimiento si no se previenen adecuadamente.

1. El riesgo de bucles infinitos con sign(0)

Si por alguna circunstancia hsp llegase a valer 0 pero el código entrase al bloque de colisión (por ejemplo, por modificaciones externas de posición o empujes de otros objetos), sign(0) devolvería 0. Si esto ocurriera dentro de un while que busca avanzar en la dirección sign(hsp), x += 0 no movería la instancia, la condición de colisión nunca cambiaría y el juego se congelaría por completo en un bucle infinito que colgaría el hilo de ejecución de GameMaker.

Para blindar el código contra fallos imprevistos, es una excelente práctica condicionar la comprobación horizontal a que la velocidad sea distinta de cero (hsp != 0), o bien asegurarse de que el valor absoluto de la velocidad sea mayor que un umbral mínimo:

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. El uso de familias de colisión mediante Parents (Objetos Padres)

En un videojuego real, obj_player no solo colisionará con muros estáticos. También interactuará con puertas cerradas, bloques destructibles, plataformas metálicas y pilares de roca. Crear un bloque if (place_meeting(...)) independiente para cada tipo de bloque en el evento Step es una pésima práctica de arquitectura de software, ya que multiplica el consumo de CPU y vuelve el código insostenible.

La solución es la herencia mediante Parents en GameMaker. Creamos un objeto vacío llamado obj_solid o par_solid (sin sprite ni código). Luego, en cada objeto con solidez física (obj_wall, obj_block_wood, obj_iron_gate), abrimos sus propiedades y asignamos como Parent a obj_solid.

Gracias al sistema de herencia de GameMaker, place_meeting(x + hsp, y, obj_solid) comprobará simultáneamente el solapamiento con cualquier instancia de obj_solid o con cualquiera de sus objetos hijos, unificando toda la física horizontal en un único bloque de código limpio y eficiente.

3. Velocidades con decimales y precisión fraccionaria

Cuando implementamos aceleraciones o fricciones (por ejemplo, move_speed = 3.75), las variables de posición y velocidad acumulan fracciones decimales. En versiones modernas de GameMaker, place_meeting evalúa las coordenadas con precisión flotante redondeando internamente según el subsistema de renderizado. Sin embargo, si sumas x += sign(hsp) mientras x contiene un decimal (por ejemplo, x = 12.4), x pasará a 13.4, 14.4, etcétera.

En la mayoría de los casos de estética retro pixel-art, esto no causa problemas perceptibles si los muros están alineados en la rejilla de coordenadas enteras (Grid Snapping). No obstante, si notas que en ocasiones el personaje queda separado por una fracción minúscula de píxel, una técnica habitual consiste en redondear la posición al detenerse o utilizar un acumulador de fracciones (técnica que exploraremos en el capítulo de optimización de físicas).

Ejercicios prácticos

Para afianzar los conocimientos adquiridos en esta clase, realiza las siguientes tres actividades prácticas en tu proyecto de GameMaker.

Ejercicio 1: Verificación del espacio residual (El experimento del «Gap») En tu objeto obj_player, desactiva temporalmente el bucle while comentándolo con barras dobles (//), dejando únicamente el if (place_meeting(x + hsp, y, obj_wall)) { hsp = 0; }. Configura la velocidad de movimiento horizontal con un valor alto y poco común, como move_speed = 7. Ejecuta el juego, corre hacia un muro y observa detenidamente con qué frecuencia el personaje se detiene dejando un hueco visible entre su cuerpo y los ladrillos. Vuelve a habilitar el bucle while y comprueba cómo el contacto se vuelve milimétrico independientemente de la velocidad. Criterio de comprobación: Al restaurar el bucle while, el personaje debe tocar físicamente la textura del muro sin un solo píxel de separación visual, tanto al moverse a la izquierda como a la derecha.

Ejercicio 2: Creación de un bloque rompible usando Herencia (Parents) Crea un nuevo sprite llamado spr_crate de 32x32 píxeles con textura de caja de madera. Crea un objeto obj_crate y asígnale el sprite. Define un objeto maestro obj_solid y configura tanto a obj_wall como a obj_crate para que tengan a obj_solid como su «Parent». Modifica el código del evento Step de obj_player para que evalúe colisiones contra obj_solid en lugar de obj_wall. Criterio de comprobación: Coloca cajas y muros en tu room. El jugador debe detenerse de forma perfecta e idéntica ante ambos elementos sin haber añadido ninguna línea de código adicional para la caja.

Ejercicio 3: Dibujo del vector de colisión para depuración visual (Debug Visual) Abre el evento Draw de obj_player. Asegúrate de ejecutar draw_self() para que el sprite del personaje no desaparezca. Justo debajo, dibuja una línea o rectángulo semitransparente que represente hacia dónde está proyectando la colisión el jugador en cada instante utilizando draw_line_color(x, y, x + hsp, y, c_red, c_red). Criterio de comprobación: Al moverte hacia la izquierda o derecha en la sala, deberás ver una línea roja proyectándose desde el origen del personaje hacia el frente, indicando la longitud exacta de la comprobación horizontal anticipada.