Refinamiento de controles y variables de movimiento

La importancia del «Game Feel» y la precisión en el control

En el desarrollo de videojuegos de plataformas en dos dimensiones, la diferencia entre una experiencia frustrante y una gratificante rara vez radica en los gráficos o en la complejidad del argumento; reside casi en su totalidad en lo que en la industria se conoce como «game feel» (la sensación de juego) o respuesta de control. Cuando un jugador pulsa un botón en su teclado o mando, espera una respuesta inmediata, predecible y justa. Si el personaje tarda una fracción de segundo de más en detenerse, si no responde a un salto por haber pulsado una milésima de segundo antes de tocar el suelo, o si la trayectoria en el aire resulta rígida e inalterable, el jugador no culpará a sus propios reflejos: culpará al juego.

Hasta este punto del módulo, has construido las bases indispensables: capturar las entradas del teclado y gamepad, calcular la dirección horizontal, invertir visualmente al personaje mediante la escala del sprite y aplicar un impulso vertical simple para despegarse del suelo. No obstante, un movimiento con velocidad instantánea pura (donde el personaje pasa de 0 a máxima velocidad en un solo fotograma y se detiene en seco) puede resultar tosco o demasiado plano para ciertos estilos de juego, mientras que un salto de altura fija impide que el jugador calibre sus trayectorias para esquivar obstáculos a diferentes alturas.

El objetivo de esta lección es refinar esas mecánicas rudimentarias. Aprenderás a estructurar variables de ajuste milimétrico para la aceleración y la fricción, a permitir que la altura del salto dependa directamente del tiempo durante el cual el usuario mantenga pulsada la tecla (salto variable), y a incorporar dos técnicas de tolerancia fundamentales del diseño moderno: el tiempo coyote y el buffer de salto.

💡 Aunque en GameMaker existe la alternativa de programación visual denominada GML Visual (basada en bloques de acciones e iconos que encajan entre sí), a lo largo de este curso continuaremos utilizando GML Code. Escribir código textual directamente proporciona un control absoluto sobre el orden matemático de ejecución y simplifica de forma extraordinaria el ajuste fino de fórmulas físicas.

Inercia controlada: Aceleración y fricción horizontal

En la lección anterior sobre movimiento horizontal, asignamos directamente la velocidad deseada multiplicando la dirección por la velocidad máxima: cuando el jugador pulsaba la tecla derecha, la variable horizontal pasaba instantáneamente de cero a, por ejemplo, cuatro píxeles por fotograma. Para un control de estilo puramente arcade, esto ofrece reactividad inmediata, pero a menudo carece de peso o fluidez orgánica.

Para dotar al personaje de una transición suave sin sacrificar la agilidad, recurrimos a dos variables complementarias: aceleración y fricción. La aceleración determina cuántos píxeles por fotograma añadimos a la velocidad actual hasta alcanzar el límite máximo; la fricción determina cuántos píxeles por fotograma sustraemos a dicha velocidad cuando el jugador no presiona ninguna dirección, hasta hacerla regresar exactamente a cero.

Un error común entre principiantes consiste en aplicar restas directas para la fricción sin verificar si el valor cruza el cero. Por ejemplo, si el personaje se mueve a una velocidad de 0.2 hacia la derecha y aplicamos una fricción de 0.5 hacia la izquierda, la velocidad resultante sería -0.3, provocando que el personaje vibre o retroceda infinitamente hacia el lado contrario. Para evitar este problema, programamos una función de aproximación matemática o empleamos comparaciones lógicas precisas con funciones estándar de GML.

Variables de configuración horizontal en el evento Create

Abrimos nuestro objeto principal del jugador, `obj_player`, y accedemos a su evento **Create**. Vamos a reorganizar y enriquecer las variables de desplazamiento que creamos en lecciones previas para permitir una calibración cómoda desde un único punto del proyecto.

/// Evento Create de obj_player

// --- VARIABLES DE MOVIMIENTO HORIZONTAL ---
vel_x = 0;              // Velocidad horizontal actual en píxeles por fotograma
vel_x_max = 3.5;        // Velocidad horizontal máxima alcanzable
acel_x = 0.4;           // Cuánto incrementa la velocidad por cada fotograma de pulsación
fric_x = 0.35;          // Cuánto se reduce la velocidad por fotograma al soltar el control

// --- VARIABLES DE MOVIMIENTO VERTICAL Y GRAVEDAD ---
vel_y = 0;              // Velocidad vertical actual
vel_y_max = 8.0;        // Límite de caída terminal
gravedad = 0.35;        // Fuerza constante hacia abajo
vel_salto = -6.5;       // Impulso inicial de salto (valor negativo hacia arriba)

Observa con atención los valores numéricos: `acel_x` está configurado en 0.4 y `fric_x` en 0.35. A una tasa de refresco estándar de 60 fotogramas por segundo, un incremento de 0.4 significa que el personaje tardará menos de diez fotogramas (aproximadamente una sexta parte de segundo) en pasar del reposo absoluto a su velocidad tope de 3.5. Esto confiere una sutil sensación de aceleración natural sin que el jugador sienta pesadez o retraso involuntario («input lag»).

Cálculo de la aceleración y desaceleración en el evento Step

Dentro del evento **Step** de `obj_player`, reemplazaremos la asignación directa de velocidad horizontal por un bloque condicional que verifique si existe o no intención de movimiento por parte del usuario.

/// Fragmento del evento Step de obj_player: Gestión horizontal

// 1. Obtención de entrada direccional (-1 para izquierda, 1 para derecha, 0 si está quieto)
var _tecla_der = keyboard_check(vk_right) || keyboard_check(ord("D"));
var _tecla_izq = keyboard_check(vk_left) || keyboard_check(ord("A"));
var _dir = _tecla_der - _tecla_izq;

// 2. Modificación de la velocidad horizontal mediante aceleración o fricción
if (_dir != 0) {
    // El jugador desea moverse: aceleramos hacia la dirección deseada
    vel_x += _dir * acel_x;
    
    // Aseguramos que la velocidad no sobrepase el tope permitido
    vel_x = clamp(vel_x, -vel_x_max, vel_x_max);
} else {
    // El jugador soltó los controles: aplicamos fricción para detenerlo
    if (vel_x > 0) {
        vel_x = max(0, vel_x - fric_x);
    } else if (vel_x < 0) {
        vel_x = min(0, vel_x + fric_x);
    }
}

Analicemos la función nativa `clamp(val, min, max)` utilizada en el código. Esta función devuelve el valor evaluado asegurando que jamás sea inferior a `min` ni superior a `max`. En nuestro caso, impide que la suma continua de `acel_x` acelere al personaje de manera desmedida. En el bloque de fricción, `max(0, vel_x - fric_x)` garantiza que, al restar fricción a una velocidad positiva, esta nunca descienda por debajo de cero, evitando así el temblor o rebote inverso.

Salto variable: Adaptabilidad en el aire

En clásicos como Super Mario Bros., Celeste o Mega Man, la altura del salto depende de la duración de la pulsación: un toque breve genera un salto corto («hop») para evitar techos bajos o aterrizar sobre un saliente próximo, mientras que mantener el botón pulsado impulsa al personaje hasta el punto más elevado de su parábola. Si el salto tuviera siempre la misma altura fija, los jugadores perderían una enorme cantidad de opciones tácticas al diseñar rutas a través de las plataformas.

La manera matemática más elegante y reactiva de lograr este comportamiento sin alterar la gravedad base consiste en interrumpir la inercia ascendente en el instante exacto en que el jugador suelta el botón. Cuando soltamos la tecla de salto y el personaje todavía se está desplazando hacia arriba (es decir, su velocidad vertical `vel_y` es negativa), multiplicamos dicha velocidad por una fracción decimal (por ejemplo, 0.4 o 0.5), o bien la truncamos directamente a un umbral menor.

Implementación del corte de salto en GML

Para integrar este comportamiento, primero definimos una variable de proporción en el evento **Create** de `obj_player`, que representará cuánto impulso conservamos si se interrumpe la pulsación:

/// Añadido al evento Create de obj_player
multiplicador_corte_salto = 0.45; // Porcentaje de velocidad vertical conservado al soltar el botón

Posteriormente, en el evento **Step**, gestionamos la lectura de la liberación de la tecla mediante `keyboard_check_released()`:

/// Fragmento del evento Step de obj_player: Salto variable

// Detección de liberación de las teclas de salto habituales
var _solto_salto = keyboard_check_released(vk_space) || keyboard_check_released(ord("W")) || keyboard_check_released(vk_up);

// Si el jugador suelta el botón mientras el personaje asciende, amortiguamos la subida
if (_solto_salto && vel_y < 0) {
    vel_y = vel_y * multiplicador_corte_salto;
}

Fíjate en la condición `vel_y < 0`. En los ejes de coordenadas 2D de GameMaker, el eje Y crece hacia abajo; por consiguiente, una velocidad negativa implica que el cuerpo se desplaza hacia la parte superior de la pantalla. Si el jugador suelta el botón mientras el personaje ya está cayendo de vuelta hacia el suelo (`vel_y >= 0`), la condición se evalúa como falsa y la gravedad regular sigue operando sin alteraciones abruptas.