Movimiento horizontal y velocidad

Del registro de teclas a la traslación física en pantalla

En la lección anterior aprendiste a capturar las intenciones del jugador a través de las funciones de entrada de GameMaker, abstrayendo las pulsaciones de teclado o gamepad en un valor direccional normalizado dentro del rango [-1, 1]. No obstante, saber que el usuario desea desplazarse a la derecha o a la izquierda es únicamente la mitad del trabajo; la otra mitad consiste en traducir ese deseo en una respuesta cinemática convincente, precisa y coherente con el género de plataformas retro que estamos construyendo.

En el desarrollo de videojuegos bidimensionales, la traslación de un objeto a lo largo del eje X puede abordarse desde dos filosofías de diseño mecánico fundamentales: el movimiento rígido o instantáneo, donde la entidad alcanza su velocidad de desplazamiento en el mismo fotograma en que se detecta la pulsación y se detiene en seco al soltarla, y el movimiento con aceleración gradual e inercia (fricción), donde la velocidad incrementa progresivamente con el tiempo y decae con suavidad al cesar la entrada. A lo largo de esta lección descompondremos paso a paso ambas aproximaciones, analizando su implementación matemática en GameMaker Language (GML Code), el uso de variables especializadas y el impacto que tienen en el control del personaje.

El sistema de coordenadas de GameMaker y el eje X

Antes de escribir una sola línea de código para mover al jugador, es imprescindible repasar cómo gestiona GameMaker el espacio bidimensional dentro de una habitación (room). A diferencia del plano cartesiano convencional utilizado en matemáticas escolares, el sistema de coordenadas de pantalla sitúa el origen (0, 0) en la esquina superior izquierda:

Cada instancia posee de forma predeterminada las variables nativas 'x' e 'y', que almacenan sus coordenadas en píxeles con precisión de punto flotante. Si incrementamos 'x', la instancia se desplaza a la derecha; si reducimos 'x', la instancia se desplaza a la izquierda. Sin embargo, modificar directamente la variable 'x' sumándole directamente una constante (como 'x += 4') sin una estructura intermedia de velocidad nos impedirá gestionar rebotes, fuerzas externas, inercia o las colisiones que abordaremos en el siguiente módulo.

💡 Buenas prácticas: Aunque GameMaker incluye variables integradas de movimiento como 'hspeed', 'vspeed', 'speed' y 'direction', en el desarrollo profesional de plataformas 2D se recomienda utilizar variables personalizadas (por ejemplo, 'hsp' o 'vel_x'). Las variables nativas actualizan automáticamente la posición de la instancia antes de que puedas evaluar colisiones personalizadas con precisión de píxel.

Arquitectura de variables en el evento Create

Para construir un sistema de movimiento robusto en nuestro objeto del jugador ('obj_player'), debemos inicializar una serie de variables de control en el evento 'Create'. Este evento se ejecuta una sola vez cuando la instancia se genera en la room, lo que lo convierte en el lugar idóneo para definir los parámetros físicos del personaje.

Abre el proyecto que venimos desarrollando en el curso, selecciona 'obj_player', abre su evento 'Create' y añade las variables de velocidad horizontal que utilizaremos a partir de ahora:

/// @description Configuración inicial de movimiento horizontal
// obj_player - Evento Create

// Velocidad horizontal actual en píxeles por fotograma
hsp = 0;

// Velocidad máxima que el jugador puede alcanzar en el eje X
move_speed = 3.5;

// Tasa de aceleración (cuántos píxeles por fotograma gana al presionar una tecla)
accel = 0.3;

// Tasa de fricción o desaceleración (cuántos píxeles por fotograma pierde al soltar)

Analicemos el propósito de cada una de estas variables: 1. 'hsp' (Horizontal Speed): Almacena la velocidad real calculada para el fotograma en curso. Puede ser positiva (movimiento a la derecha), negativa (movimiento a la izquierda) o cero (reposo absoluto). 2. 'move_speed': Establece la cota superior del movimiento regular. Con 3.5, el personaje recorrerá un máximo de 3.5 píxeles en cada ciclo de actualización si la tasa de fotogramas es estable. 3. 'accel': Define la rapidez con la que el personaje gana impulso. Un valor bajo (ej. 0.05) crea una sensación resbaladiza o pesada, mientras que un valor cercano a 'move_speed' hace que la aceleración sea prácticamente inmediata. 4. 'fric': Determina la fuerza de frenado del suelo. Un valor moderado como 0.4 permite que el personaje patine brevemente antes de detenerse.

Aproximación 1: Movimiento horizontal instantáneo (Digital/Arcade)

El enfoque más simple y directo consiste en aplicar la velocidad de forma inmediata multiplicando la dirección de entrada por la velocidad máxima. Este modelo es característico de clásicos como 'Mega Man' o títulos de acción donde la precisión quirúrgica prima sobre la inercia física.

En el evento 'Step' de 'obj_player', combinamos la captura de controles vista en la clase previa con la actualización directa de 'hsp' y de la coordenada 'x':

/// @description Movimiento horizontal instantáneo
// obj_player - Evento Step

// 1. Obtención del vector de entrada (-1, 0, 1)
var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));
var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
var _move = _key_right - _key_left;

// 2. Cálculo directo de velocidad
hsp = _move * move_speed;

// 3. Aplicación a la posición horizontal
x += hsp;

El funcionamiento matemático es impecable en su simplicidad: si el jugador pulsa la tecla derecha, '_move' vale 1 y 'hsp' pasa a valer 3.5 en un solo fotograma; la posición 'x' aumenta 3.5 píxeles en ese instante. Si el jugador pulsa la tecla izquierda, '_move' vale -1 y 'hsp' es -3.5, desplazando al personaje a la izquierda. Al soltar las teclas, '_move' es 0, lo que anula de inmediato 'hsp' y detiene la instancia en el sitio exacto.

Aproximación 2: Aceleración gradual y fricción realista

Aunque el movimiento instantáneo es muy responsivo, muchos juegos de plataformas (como 'Super Mario World' o 'Sonic the Hedgehog') emplean una física más orgánica que simula el peso del cuerpo y el agarre sobre la superficie. Para lograr esto, no asignamos la velocidad directamente; en su lugar, la modificamos de forma acumulativa fotograma tras fotograma.

El proceso lógico se divide en dos ramas condicionales dentro del evento 'Step': - Si hay entrada activa (_move != 0): incrementamos 'hsp' en la dirección indicada a razón de 'accel', asegurándonos de no exceder 'move_speed'. - Si no hay entrada activa (_move == 0): reducimos 'hsp' hacia 0 a razón de 'fric', impidiendo que sobrepase el reposo y cambie de sentido involuntariamente.

Control de límites con clamp() y evaluación de sentido con sign()

Para programar la aceleración y la inercia sin generar anomalías numéricas, GameMaker ofrece dos funciones matemáticas fundamentales:

1. 'clamp(val, min, max)': Devuelve el valor 'val' acotado estrictamente entre un mínimo y un máximo. Si 'val' es inferior a 'min', devuelve 'min'; si supera 'max', devuelve 'max'. Esto nos permite evitar que la aceleración incremente la velocidad al infinito. 2. 'sign(val)': Devuelve 1 si el número es positivo, -1 si es negativo, y 0 si es exactamente cero. Esta función nos permite conocer el sentido del movimiento actual sin importar su magnitud.

Veamos cómo implementar la lógica completa de aceleración y fricción en el evento 'Step':

/// @description Movimiento horizontal con aceleración y fricción
// obj_player - Evento Step

// 1. Lectura de controles
var _key_right = keyboard_check(vk_right) || keyboard_check(ord("D"));
var _key_left  = keyboard_check(vk_left)  || keyboard_check(ord("A"));
var _move = _key_right - _key_left;

// 2. Gestión de aceleración y desaceleración
if (_move != 0)
{
    // Hay intención de movimiento: aceleramos en esa dirección
    hsp += _move * accel;
    
    // Restringimos la velocidad para no superar el límite permitido
    hsp = clamp(hsp, -move_speed, move_speed);
}
else
{
    // No hay teclas presionadas: aplicamos fricción para frenar
    if (abs(hsp) <= fric)
    {
        // Si la velocidad es menor o igual a la fricción, nos detenemos por completo
        hsp = 0;
    }
    else
    {
        // Restamos la fricción en el sentido opuesto al desplazamiento actual
        hsp -= sign(hsp) * fric;
    }
}

// 3. Aplicación del desplazamiento al eje X
x += hsp;

Fíjate con especial atención en la condición 'if (abs(hsp) <= fric)'. La función 'abs()' calcula el valor absoluto de un número (su magnitud sin signo). Si un personaje viaja a 'hsp = 0.2' y la fricción es de '0.4', al restar simplemente la fricción obtendríamos '0.2 - 0.4 = -0.2'. El personaje comenzaría a moverse hacia la izquierda sin que nadie pulse una tecla, entrando en una oscilación infinita de un lado a otro. Al verificar si la velocidad restante es inferior al paso de fricción, garantizamos una parada perfecta a cero absoluto.