Pulido de mecánicas (Juice) y respuesta visual

Introducción al concepto de «Juice» y Game Feel

En el desarrollo de videojuegos existe una distinción crucial entre una mecánica que funciona y una mecánica que se siente bien. Un personaje puede correr, saltar y colisionar con precisión matemática estricta según las reglas programadas en los módulos anteriores; sin embargo, si carece de respuesta sensorial inmediata, el jugador percibirá el control como rígido, acartonado o desconectado. En la industria del videojuego independiente, el término coloquial «Juice» (jugosidad) se refiere a todas aquellas capas de retroalimentación visual, sonora y temporal añadidas sobre una mecánica funcional para maximizar el placer táctil y visual al interactuar con el mundo virtual.

El «Game Feel» no altera las reglas fundamentales de la física del juego, sino cómo se comunican y cómo se toleran las imperfecciones del propio jugador humano. Cuando un personaje salta, no solo debe cambiar su posición vertical: el suelo debe emitir partículas, el cuerpo del personaje debe comprimirse antes de impulsarse y estirarse en el aire, la cámara puede reaccionar con un microtemblor si el impacto es contundente, y el juego debe conceder un pequeño margen de error si el usuario presiona el botón unos milisegundos antes o después del momento exacto. En esta clase abordaremos el pulido integral de nuestro juego de plataformas 2D en GameMaker, asegurando que cada movimiento transmita peso, dinamismo y satisfacción.

Tolerancia del control: Coyote Time y Jump Buffering

En un motor físico estricto, si el personaje deja de tocar el suelo durante un solo fotograma (por ejemplo, al caminar hacia el vacío desde el borde de un acantilado), la variable de contacto con el suelo pasa inmediatamente a false y el comando de salto queda inhabilitado. Para el cerebro humano y la tasa de refresco visual, esto suele percibirse como un fallo injusto del juego: el usuario cree haber presionado el botón cuando aún estaba en el borde, pero el procesador ya detectó caída libre. Para resolver esto implementamos dos mecánicas universales de tolerancia temporal: el Coyote Time y el Jump Buffering.

El «Coyote Time» (nombrado en honor al coyote de los dibujos animados que corre en el aire por un instante antes de caer) permite al jugador saltar durante una pequeña ventana de tiempo (habitualmente entre 5 y 8 fotogramas a 60 FPS) después de haber abandonado una superficie sólida sin haber saltado. Por su parte, el «Jump Buffering» (amortiguación de entrada) almacena en memoria la pulsación de salto si el jugador la ejecuta en el aire justo antes de tocar el suelo (en un intervalo similar de 5 a 8 fotogramas), disparando el salto automáticamente en el fotograma exacto en el que el personaje hace contacto con la plataforma.

// Objeto: obj_player
// Evento: Create

// Variables de movimiento base (ya existentes)
hsp = 0;
vsp = 0;
grav = 0.4;
walk_spd = 3.5;
jump_spd = -7.5;
grounded = false;

// Tolerancias de entrada (Juice: Control Feel)
coyote_max = 6;         // Fotogramas de gracia tras salir del suelo
coyote_timer = 0;       // Contador regresivo para el salto tardío

buffer_max = 6;         // Fotogramas que recordamos la pulsación de salto
buffer_timer = 0;       // Contador regresivo para el salto anticipado

En el evento Step del jugador, actualizamos estos temporizadores fotograma a fotograma antes de evaluar la lógica de salto. Si el jugador está sobre el suelo (`grounded == true`), recargamos el contador de Coyote Time a su valor máximo. En caso contrario, reducimos el contador en 1 unidad por cada paso. Para el Jump Buffer, si detectamos la pulsación de la tecla de salto, asignamos el valor máximo a la variable `buffer_timer`. El salto solo se consumirá si ambos márgenes convergen favorablemente.

// Objeto: obj_player
// Evento: Step (Sección de gestión de temporizadores y salto)

// 1. Lectura de entrada de salto
var _key_jump = keyboard_check_pressed(vk_space) || gamepad_button_check_pressed(0, gp_face1);

// 2. Gestión de Coyote Time
if (grounded) {
    coyote_timer = coyote_max;
} else {
    if (coyote_timer > 0) coyote_timer--;
}

// 3. Gestión de Jump Buffering
if (_key_jump) {
    buffer_timer = buffer_max;
} else {
    if (buffer_timer > 0) buffer_timer--;
}

// 4. Ejecución del salto utilizando las tolerancias
if (buffer_timer > 0 && coyote_timer > 0) {
    vsp = jump_spd;
    buffer_timer = 0;   // Consumimos el buffer inmediatamente para no repetir
    coyote_timer = 0;   // Consumimos la oportunidad del coyote
    grounded = false;
}

Con estas pocas líneas de código, la sensación del salto se transforma radicalmente. El jugador ya no experimentará caídas frustrantes al intentar apurar los saltos en los bordes de los precipicios ni perderá la fluidez rítmica al intentar encadenar saltos sucesivos al tocar tierra.

Deformación elástica: Squash and Stretch

El principio de animación clásica conocido como estiramiento y encogimiento («Squash and Stretch») es fundamental para conferir masa, elasticidad y dinamismo a un cuerpo 2D. Cuando un cuerpo orgánico choca fuertemente contra el suelo, se deforma ensanchándose horizontalmente y achatándose verticalmente (Squash) para disipar la energía cinética; a la inversa, cuando se impulsa hacia arriba o cae a gran velocidad, se elonga verticalmente y se estrecha horizontalmente (Stretch).

En GameMaker, alterar directamente `image_xscale` e `image_yscale` para efectos visuales presenta un riesgo crítico: si la máscara de colisión de la instancia depende de la escala de la imagen, modificar estas propiedades alterará la caja delimitadora (bounding box) física del personaje, lo que provocará que el personaje se atasque dentro de las paredes o del suelo. La solución profesional y segura consiste en mantener intactas las variables nativas de escala para la física y definir variables personalizadas destinadas exclusivamente al renderizado en el evento Draw.

// Objeto: obj_player
// Evento: Create

// Variables de deformación visual independiente de la colisión física
x_scale_display = 1.0;
y_scale_display = 1.0;

// Variable de ayuda para detectar el impacto exacto con el suelo
was_grounded = true;

En el evento Step, detectamos el momento exacto en el que el personaje salta y el momento exacto en el que aterriza tras una caída. Cuando esto ocurre, forzamos valores asimétricos en `x_scale_display` e `y_scale_display`. Acto seguido, en cada fotograma, utilizamos la función de interpolación lineal `lerp()` para devolver gradualmente estas variables a su valor neutro de 1.0.

// Objeto: obj_player
// Evento: Step (Sección de Squash and Stretch)

// Detección de salto para estirar al personaje (Stretch)
if (buffer_timer == 0 && coyote_timer == 0 && vsp == jump_spd) {
    x_scale_display = 0.7; // Se estrecha
    y_scale_display = 1.3; // Se estira hacia arriba
}

// Detección del impacto contra el suelo (Squash)
if (!was_grounded && grounded) {
    // El impacto aplasta al personaje contra el suelo
    x_scale_display = 1.35;
    y_scale_display = 0.65;
}

// Almacenamos el estado del suelo para el siguiente paso
was_grounded = grounded;

// Retorno elástico continuo hacia la escala neutra (1.0)
x_scale_display = lerp(x_scale_display, 1.0, 0.15);
y_scale_display = lerp(y_scale_display, 1.0, 0.15);

💡 Recuerda que `lerp(a, b, amt)` aproxima el valor 'a' hacia 'b' en un porcentaje 'amt' por fotograma. Con un factor de 0.15, la deformación retrocede de forma suave y amortiguada sin requerir complejas fórmulas trigonométricas de resortes.

Para que esta deformación tenga efecto real sin alterar la física del juego, reemplazamos el dibujado por defecto en el evento Draw del jugador. Usamos `draw_sprite_ext()`, multiplicando la dirección horizontal tradicional (`facing`, que toma valores de 1 o -1 para mirar a derecha o izquierda) por nuestra escala personalizada.

// Objeto: obj_player
// Evento: Draw

// Asegúrate de que el origen del sprite de obj_player esté situado en 'Bottom Centre'
// de modo que la deformación se asiente en los pies y no flote en el aire.

draw_sprite_ext(
    sprite_index,
    image_index,
    x,
    y,
    facing * x_scale_display,
    y_scale_display,
    0,
    c_white,
    image_alpha
);

Sacudida de cámara (Screen Shake)

La sacudida de pantalla (Screen Shake) es uno de los métodos más efectivos para transmitir fuerza, peso y violencia cinemática. Un impacto contra un obstáculo, el aterrizaje desde una gran altura o la eliminación de un enemigo cobran vida si el punto de vista se perturba brevemente. Sin embargo, un temblor mal calibrado o persistente produce mareo cinemático (motion sickness) y desorientación. Por tanto, el temblor debe ser súbito en su inicio y disiparse de forma exponencial rápida.

En el Módulo 10 aprendimos a configurar una cámara manual o seguidora utilizando la cámara de la vista (`view_camera[0]`). Para añadir sacudida sin que la cámara se desvíe progresivamente del objetivo, tomamos la posición teórica deseada de la cámara (centrada en el jugador) y le sumamos un desplazamiento aleatorio que decrece en cada fotograma.

// Objeto: obj_camera
// Evento: Create

target = obj_player;
cam = view_camera[0];
cam_w = camera_get_view_width(cam);
cam_h = camera_get_view_height(cam);

// Variables de Screen Shake
shake_magnitude = 0;   // Fuerza del temblor actual en píxeles
shake_remain = 0;      // Magnitud residual decreciente
shake_fade = 0.9;      // Coeficiente de atenuación multiplicativa

Para facilitar que cualquier entidad del juego (el jugador, un proyectil o un jefe) pueda solicitar un temblor sin preocuparse por la implementación interna de la cámara, creamos una función global o script llamada `screen_shake()`.

// Script: scr_screen_shake
// Función utilizable desde cualquier evento de cualquier objeto

function screen_shake(_magnitude, _force_overwrite = false) {
    if (instance_exists(obj_camera)) {
        with (obj_camera) {
            // Si la nueva sacudida es más potente que la que está ocurriendo, o si forzamos el reemplazo
            if (_magnitude > shake_remain || _force_overwrite) {
                shake_magnitude = _magnitude;
                shake_remain = _magnitude;
            }
        }
    }
}

Finalmente, en el evento Step (o preferiblemente en el evento End Step) de `obj_camera`, calculamos el seguimiento clásico y sumamos la perturbación pseudoaleatoria calculada mediante la función `random_range()` multiplicada por la fuerza restante.

// Objeto: obj_camera
// Evento: End Step

if (instance_exists(target)) {
    // Posición ideal sin perturbación
    var _dest_x = target.x - (cam_w / 2);
    var _dest_y = target.y - (cam_h / 2);

    // Suavizado de seguimiento continuo
    var _cur_x = camera_get_view_x(cam);
    var _cur_y = camera_get_view_y(cam);
    var _final_x = lerp(_cur_x, _dest_x, 0.1);
    var _final_y = lerp(_cur_y, _dest_y, 0.1);

    // Cálculo de la desviación por sacudida
    var _offset_x = random_range(-shake_remain, shake_remain);
    var _offset_y = random_range(-shake_remain, shake_remain);

    // Disipación del temblor residual
    shake_remain = lerp(shake_remain, 0, 0.1);
    if (shake_remain < 0.1) shake_remain = 0;

    // Límites de la habitación para evitar ver el vacío exterior
    _final_x = clamp(_final_x + _offset_x, 0, room_width - cam_w);
    _final_y = clamp(_final_y + _offset_y, 0, room_height - cam_h);

    camera_set_view_pos(cam, _final_x, _final_y);
}