Aplicación de gravedad constante

Introducción a la simulación física en videojuegos 2D

En el desarrollo de videojuegos de plataformas bidimensionales, la gravedad no es simplemente una fuerza de atracción planetaria como la describe la física clásica de Isaac Newton; es, ante todo, una herramienta de diseño lúdico. La forma en que un personaje cae, la aceleración con la que gana velocidad hacia abajo y la rapidez con la que reacciona a los comandos del jugador determinan de manera directa la sensación de juego o 'game feel'. Si la gravedad es demasiado baja, el personaje se sentirá flotante, impreciso y difícil de controlar, como si estuviera caminando en la Luna. Por el contrario, si la aceleración descendente es excesiva, los saltos parecerán secos, pesados e impredecibles.

Para construir esta mecánica con total solidez técnica, es indispensable comprender cómo GameMaker procesa las coordenadas espaciales y el tiempo de ejecución. A diferencia de un simulador científico continuo, un motor de videojuegos actualiza el estado del mundo en intervalos discretos llamados fotogramas o 'steps'. En cada uno de estos ciclos, nuestro código debe calcular de forma determinista cuánto se incrementa la velocidad vertical y cómo impacta ese cambio en la posición vertical del objeto. En esta lección, implementaremos este sistema paso a paso utilizando código nativo en GML Code, prescindiendo deliberadamente de los sistemas automáticos del motor para otorgarte un control absoluto sobre el movimiento y las futuras colisiones.

El sistema de coordenadas de GameMaker y el eje Y invertido

Uno de los primeros obstáculos conceptuales que enfrentan quienes se inician en la programación de videojuegos es la orientación de los ejes cartesianos. En las matemáticas tradicionales que se enseñan en la escuela, el punto de origen (0, 0) suele ubicarse en el centro o en la esquina inferior izquierda de un plano cartesiano, donde los valores de X crecen hacia la derecha y los valores de Y crecen hacia arriba. Sin embargo, en la computación gráfica y en GameMaker en particular, el estándar proviene de la forma en que los antiguos monitores de tubo de rayos catódicos (CRT) dibujaban las líneas en pantalla: de izquierda a derecha y de arriba hacia abajo.

Por lo tanto, en una Room de GameMaker, el origen de coordenadas (x = 0, y = 0) se sitúa exactamente en la esquina superior izquierda de la sala. Esto tiene dos consecuencias inmediatas y vitales para la programación de cualquier movimiento:

1. El eje horizontal (x) funciona de manera intuitiva: aumentar el valor de x desplaza el objeto hacia la derecha, mientras que disminuir el valor de x lo desplaza hacia la izquierda. 2. El eje vertical (y) se encuentra invertido respecto a la intuición escolar: aumentar el valor de y desplaza el objeto hacia abajo (hacia el fondo de la pantalla), mientras que restar o disminuir el valor de y eleva al objeto hacia arriba (hacia el techo de la sala).

Entender esta inversión del eje Y es el requisito indispensable para programar la gravedad. Si la gravedad es una aceleración que empuja los cuerpos hacia el suelo, en GameMaker dicha aceleración debe ser una cantidad positiva que se sume de manera progresiva a la posición vertical del personaje en cada fotograma transcurrido.

¿Variables integradas de GameMaker o variables personalizadas?

Quienes exploran la documentación básica de GameMaker descubrirán rápidamente que el motor posee variables internas predeterminadas como 'vspeed', 'hspeed', 'speed', 'direction' y 'gravity'. Si asignas un valor a 'gravity' (por ejemplo, gravity = 0.5), GameMaker aplicará automáticamente una aceleración hacia abajo a la instancia sin requerir una sola línea adicional de cálculo. Sin embargo, en el desarrollo profesional e independiente de juegos de plataformas 2D, el uso de estas variables integradas se desaconseja de forma unánime.

La razón de esta advertencia radica en el orden interno de ejecución de eventos del motor. Cuando utilizas 'vspeed' y 'gravity', GameMaker suma automáticamente la velocidad a la posición 'y' entre el evento Step y el evento End Step, antes de que puedas intervenir para validar si el personaje va a atravesar una plataforma, una trampa o un muro sólido. Esto genera comportamientos erráticos, tales como personajes que se hunden parcialmente en el suelo, vibraciones visuales (jittering) y fallos graves al calcular colisiones milimétricas.

La solución estándar y robusta consiste en gestionar la velocidad y la aceleración mediante variables personalizadas de instancia, tales como 'vspd' (velocidad vertical) y 'grav' (fuerza de aceleración de la gravedad). Al calcular nosotros mismos la acumulación de velocidad y el cambio de posición dentro del evento Step, conservamos el control absoluto de cada píxel recorrido antes de que el motor dibuje el fotograma en pantalla.

💡 Regla de oro: En plataformas 2D de alta precisión, jamás mezcles las variables integradas (vspeed, hspeed, gravity) con tus variables personalizadas de movimiento (vspd, hspd, grav). Mantén todo el control dentro de tus propios scripts y eventos.

Definición de variables en el evento Create de obj_player

El primer paso técnico es inicializar las variables que definirán el comportamiento físico de nuestro personaje principal, al que llamaremos 'obj_player'. Recuerda que el evento Create se ejecuta una única vez en el momento exacto en que la instancia del objeto nace dentro de la Room. Es el lugar idóneo para declarar propiedades, parámetros y valores iniciales de movimiento.

Abramos nuestro objeto 'obj_player' en el espacio de trabajo de GameMaker, seleccionemos el evento Create y añadamos el siguiente bloque de código en GML Code:

// Evento Create de obj_player

// Velocidades de desplazamiento
hspd = 0;              // Velocidad horizontal actual en píxeles por frame
vspd = 0;              // Velocidad vertical actual en píxeles por frame

// Parámetros de aceleración y límites físicos
grav = 0.3;            // Constante de gravedad (aceleración por frame)
vspd_max = 9.0;        // Velocidad terminal o límite máximo de caída

// Parámetros de control horizontal y salto (declarados en el Módulo 4)
walk_spd = 3.5;        // Velocidad máxima de caminata
jump_spd = -7.5;       // Impulso inicial de salto (negativo para subir)

Analicemos la función de cada variable introducida para la gravedad:

- 'vspd': Almacena la cantidad de píxeles que la instancia debe desplazarse verticalmente en el fotograma actual. Un valor de 0 indica reposo; un valor negativo (por ejemplo, -7.5) significa que el personaje se eleva; un valor positivo (por ejemplo, 4.2) significa que desciende. - 'grav': Representa la aceleración de gravedad. En cada fotograma, sumaremos esta cantidad a 'vspd'. Un valor de 0.3 píxeles/frame² ofrece una respuesta elástica y controlable, típica de juegos retro de 16 bits. - 'vspd_max': Representa la velocidad terminal. En el mundo real, la resistencia aerodinámica del aire impide que los cuerpos aceleren de forma infinita en caída libre. En un videojuego, una velocidad terminal es crucial no solo por estética, sino para evitar que un personaje caiga tan rápido que atraviese plataformas delgadas en un solo fotograma (fenómeno conocido como 'tunneling').

Implementación del incremento gradual en el evento Step

El evento Step se ejecuta de forma constante y periódica: exactamente una vez por cada fotograma del juego. Si nuestro proyecto está configurado a 60 fotogramas por segundo (fps), el código escrito dentro del evento Step se evaluará y ejecutará 60 veces en un segundo. Es aquí donde transformamos la aceleración matemática en movimiento visual perceptible.

La fórmula fundamental de la cinemática para este proceso consta de dos operaciones secuenciales:

1. Actualizar la velocidad mediante la aceleración: velocidad_nueva = velocidad_anterior + aceleración 2. Actualizar la posición mediante la velocidad: posición_nueva = posición_anterior + velocidad_nueva

Veamos cómo se traduce esto a código limpio y eficiente dentro del evento Step de 'obj_player':

// Evento Step de obj_player

// 1. Aplicación gradual de la gravedad
vspd += grav;

// 2. Limitación a la velocidad terminal (Terminal Velocity)
if (vspd > vspd_max) {
    vspd = vspd_max;
}

// 3. Aplicación del movimiento vertical a la coordenada espacial
y += vspd;

El operador '+=' es una forma abreviada de escribir 'vspd = vspd + grav;'. En cada ciclo de 1/60 de segundo, 'vspd' incrementa su magnitud en 0.3 unidades. Cuando este valor supera el límite establecido en 'vspd_max' (9.0 píxeles por fotograma), la estructura condicional 'if' interviene y trunca el exceso, manteniendo la velocidad fijada en su valor tope.

Uso de funciones nativas para acotar la velocidad: clamp() y min()

Aunque la estructura condicional 'if' es completamente válida y muy intuitiva para principiantes, GameMaker pone a nuestra disposición funciones matemáticas integradas que permiten escribir un código más conciso, expresivo y elegante. Una de las más utilizadas en este escenario es la función 'min()' o, de manera aún más completa, la función 'clamp()'.

La función 'min(val1, val2, ...)' devuelve el número más bajo entre todos los argumentos provistos. Por lo tanto, podemos resumir el incremento de gravedad y el límite de caída en una sola línea:

// Alternativa elegante usando min()
vspd = min(vspd + grav, vspd_max);

Si 'vspd + grav' resulta en 4.5, y 'vspd_max' es 9.0, la función escoge 4.5. Sin embargo, si 'vspd + grav' alcanza 9.3, la función descarta ese valor y devuelve 9.0, garantizando que el personaje jamás sobrepase la velocidad máxima permitida.

Por otro lado, la función 'clamp(val, min, max)' restringe un valor numérico entre un límite inferior y un límite superior. Esto resulta especialmente útil cuando queremos garantizar que el personaje tampoco ascienda a una velocidad desmedida durante un salto propulsado:

// Alternativa bidireccional usando clamp()
vspd += grav;
vspd = clamp(vspd, -12.0, vspd_max);