Detección de contacto con el suelo (Grounded)

Detección de contacto con el suelo (Grounded): Fundamentos y necesidad

En el desarrollo de un videojuego de plataformas bidimensional, una de las preguntas fundamentales que el motor de juego debe responder en cada fotograma es: ¿está el personaje apoyado sobre una superficie sólida o se encuentra suspendido en el aire? A simple vista, para el ojo humano esto resulta evidente al observar la pantalla; sin embargo, para el procesador un objeto no es más que una colección de coordenadas numéricas (x, y) y una caja de colisión (bounding box). El ordenador no asume que el personaje está 'de pie' a menos que nosotros escribamos una comprobación lógica explícita que lo verifique.

Saber si el jugador está pisando tierra firme (concepto comúnmente denominado en inglés como estar 'grounded') es el pilar sobre el cual se apoyan prácticamente todas las mecánicas esenciales de un videojuego de plataformas. Si no disponemos de un método confiable para detectar el suelo, el personaje podría ejecutar saltos infinitos en pleno vuelo con solo presionar repetidamente el botón de salto, flotar de manera errática o reproducir la animación de caminar mientras cae hacia un abismo. Asimismo, esta detección es crucial para reiniciar mecánicas avanzadas como el doble salto, permitir la fricción horizontal adecuada o detonar efectos sonoros de impacto al aterrizar.

A lo largo de las lecciones previas de este módulo, configuramos una aceleración constante hacia abajo mediante la variable de gravedad (`grav`) y resolvimos el contacto físico vertical contra objetos sólidos (`obj_solid`), deteniendo la velocidad vertical (`vspd = 0`) para evitar que el avatar atraviese las plataformas. En esta clase daremos un paso más allá en la arquitectura de nuestro personaje: crearemos una bandera booleana dedicada (`is_grounded`), explicaremos cómo interrogar al motor de colisiones un píxel por debajo de los pies del jugador sin alterar su posición física y organizaremos el código para que el estado de contacto sea coherente durante todo el ciclo del fotograma.

¿Qué es una bandera lógica (Boolean Flag) en GML?

En informática y desarrollo de software, una bandera lógica (o flag) es una variable que solo puede albergar dos estados posibles: verdadero (`true`) o falso (`false`). En GameMaker Language (GML), los booleanos son tratados a nivel interno como valores numéricos donde `true` equivale a 1 y cualquier valor menor o igual a 0 se interpreta como `false`. No obstante, escribir código legible requiere utilizar explícitamente las constantes `true` y `false`, o bien evaluar expresiones condicionales directas.

Al crear una bandera lógica como `is_grounded`, estamos abstrayendo una condición geométrica compleja en una respuesta binaria simple y accesible desde cualquier parte de nuestro proyecto. En lugar de ejecutar costosas comprobaciones de colisión cada vez que el código necesita saber si el jugador puede saltar, si debe reproducir el sonido de pasos o si debe cambiar su sprite de 'caída' a 'reposo', la comprobación geométrica se efectúa una única vez por fotograma y el resultado se almacena en la variable booleana.

Esta separación entre la detección física y la toma de decisiones no solo vuelve el código más limpio y comprensible para cualquier programador principiante, sino que además ahorra recursos de procesamiento y previene inconsistencias lógicas (bugs conocidos como 'race conditions' o estados desincronizados dentro del mismo fotograma).

La técnica del píxel inferior: place_meeting(x, y + 1, obj_solid)

Para determinar si un cuerpo reposa sobre una superficie sin quedar atrapado dentro de ella, debemos proyectar una consulta hipotética. Si comprobáramos `place_meeting(x, y, obj_solid)`, la función devolvería `false` mientras el personaje esté perfectamente posado, ya que el algoritmo de colisión vertical que desarrollamos en la lección anterior se asegura precisamente de dejar al jugador en contacto tangencial con la superficie, pero sin penetrarla ni un solo píxel.

Si `place_meeting(x, y, obj_solid)` devolviera `true`, significaría que el personaje está incrustado dentro de la pared o del suelo, lo cual representaría un error de colisión. Por lo tanto, la técnica estándar en la industria consiste en consultar qué sucedería si desplazáramos al jugador exactamente un píxel hacia abajo en el eje vertical: `place_meeting(x, y + 1, obj_solid)`.

La función nativa `place_meeting(x_virtual, y_virtual, objeto)` no altera las variables de posición reales `x` e `y` de la instancia. Su comportamiento interno consiste en trasladar momentáneamente la máscara de colisión asignada a la instancia a las coordenadas indicadas, calcular si existe alguna intersección con la máscara de cualquier instancia del objeto especificado (en nuestro caso, `obj_solid`) y devolver un valor booleano (`true` o `false`). Acto seguido, la máscara regresa de inmediato a su posición original sin que nada visible haya cambiado en la pantalla.

Al sumar 1 a la coordenada vertical (`y + 1`), estamos formulando la siguiente pregunta al motor de físicas: 'Si el personaje diera un microscópico paso de 1 píxel hacia abajo, ¿colisionaría con un bloque sólido?'. Si la respuesta es afirmativa, significa que el jugador está exactamente a cero píxeles de distancia del suelo: está aterrizado. Si la respuesta es negativa, el jugador se encuentra a más de un píxel del suelo más cercano: está en el aire.

Declaración y configuración inicial en el evento Create

Siguiendo la arquitectura progresiva de nuestro proyecto de plataformas retro, abriremos el objeto del jugador (`obj_player`). En su evento **Create**, debemos asegurarnos de inicializar la variable `is_grounded`. Es una regla de oro en GameMaker: toda variable que vaya a ser evaluada en un evento cíclico como **Step** debe declararse previamente en **Create**, evitando errores de compilación o fallos de ejecución por variable no definida.

Revisemos cómo debe quedar el evento **Create** de `obj_player`, conservando las variables de movimiento horizontal, vertical y salto que hemos construido a lo largo de las lecciones del Módulo 4 y las clases anteriores de este Módulo 5:

/// Evento Create de obj_player

// --- Variables de movimiento horizontal ---
move_spd = 4;        // Velocidad máxima de desplazamiento horizontal en píxeles por fotograma
hspd = 0;            // Velocidad horizontal actual

// --- Variables de movimiento vertical y física ---
vspd = 0;            // Velocidad vertical actual
grav = 0.3;          // Aceleración de gravedad aplicada en cada fotograma
jsp = -7.5;          // Fuerza de impulso de salto (negativa hacia arriba)
max_vspd = 10;       // Velocidad terminal de caída libre

// --- Banderas lógicas de estado ---
is_grounded = false; // Indica si el jugador está actualmente en contacto con el suelo

Al instanciarse el jugador en la sala (`Room`), asignamos `is_grounded = false` por precaución. No asumimos que el personaje nace sobre el suelo; permitiremos que el primer fotograma del juego evalúe su entorno y determine de forma autónoma su verdadero estado de contacto.

El orden de ejecución en el evento Step

En el desarrollo de videojuegos, el orden de las instrucciones dentro del evento **Step** es de vital importancia. Un algoritmo de físicas típico consta de cuatro etapas secuenciales que deben ejecutarse rigurosamente en este orden:

Si intentáramos evaluar `is_grounded` antes de calcular y resolver las colisiones verticales, la variable contendría el estado del fotograma anterior, produciendo un retraso imperceptible de un fotograma (frame lag) que puede provocar anomalías sutiles en los saltos o en las animaciones.