Creación de la máquina de estados visuales

Introducción a la máquina de estados visuales

En los módulos anteriores dotaste al jugador de movimiento horizontal, aceleración, gravedad, detección de suelo (`grounded`) y un sistema de colisiones sólido en los ejes horizontal y vertical. Sin embargo, un personaje que se desplaza deslizándose estáticamente o cuyas animaciones parpadean sin control carece de la respuesta táctil y estética fundamental en un juego de plataformas 2D retro. Para que un videojuego se sienta dinámico, el aspecto visual del personaje debe reflejar en cada cuadro de animación con absoluta precisión lo que está sucediendo a nivel físico y mecánico.

Muchos desarrolladores novatos cometen el error de insertar asignaciones directas de sprites dentro de cada comprobación de teclado (`if (keyboard_check(vk_right)) sprite_index = spr_player_run;`). Este enfoque degenera de inmediato en código espagueti: el sprite parpadea, la animación de salto se cancela antes de tiempo, el personaje corre en el aire o los cuadros quedan congelados al presionar dos teclas al mismo tiempo. Para resolver esta problemática de forma profesional y escalable en GameMaker, implementaremos una Máquina de Estados Visuales (Finite State Machine o FSM visual).

Concepto: Máquina de Estados Finitos (FSM) aplicada a la animación

Una Máquina de Estados Finitos es un modelo de computación que estipula que una entidad solo puede encontrarse exactamente en uno de un conjunto finito de estados en un momento determinado. En nuestro caso, el personaje no puede estar corriendo y descansando simultáneamente, ni puede considerarse en caída ascendente. En función de una serie de entradas (condiciones físicas como la velocidad horizontal `hsp`, la velocidad vertical `vsp` y el contacto con el suelo `grounded`), la máquina efectúa una transición de un estado a otro y actualiza las propiedades visuales correspondientes (`sprite_index`, `image_speed`, e `image_xscale`).

En GameMaker moderno, la forma más limpia, legible y optimizada de implementar estados es a través de un enumerador (`enum`). Un enumerador asigna nombres descriptivos a números enteros secuenciales entre bastidores, lo que evita el uso de cadenas de texto lentas y propensas a errores tipográficos (como `state = "running"`), garantizando que el compilador procese las comparaciones de manera instantánea.

Estandarización de recursos gráficos y colisiones

Antes de programar una sola línea de lógica visual, es imperativo establecer una regla de oro en el desarrollo de plataformas 2D: la coherencia espacial y dimensional de los sprites asociados a un mismo objeto. Cuando cambiamos el `sprite_index` de una instancia, GameMaker modifica automáticamente la máscara de colisión predeterminada y el punto de origen al nuevo sprite si no hemos tomado medidas preventivas. Si el sprite de correr tiene 32 píxeles de alto con origen en la base, y el sprite de salto tiene 40 píxeles de alto con origen en el centro, el personaje quedará incrustado en el suelo o flotará durante el salto, destruyendo la precisión física de las colisiones.

💡 Regla crítica: Para evitar que el personaje se atasque en plataformas o paredes al alternar entre sprites, asigna un sprite de colisión dedicado en la propiedad 'Collision Mask' del objeto 'obj_player' (por ejemplo, un rectángulo simple llamado 'spr_player_mask') o asegúrate de que todos los sprites de animación compartan con exactitud matemática el mismo origen y las mismas dimensiones de caja delimitadora (Bounding Box).

Configuración de variables en el Evento Create

En el objeto `obj_player`, dentro del evento Create, ya contamos con variables cinemáticas establecidas en módulos previos (`hsp`, `vsp`, `walk_spd`, `grav`, `jump_spd`, `grounded`). Añadiremos ahora el enumerador de estados, la variable que almacena el estado actual y una variable para rastrear el estado del cuadro anterior. Esta última nos permitirá detectar el momento exacto en el que ocurre una transición y reiniciar la subimagen `image_index` a cero, evitando que una animación comience a reproducirse por la mitad.

// ----------------------------------------------------------------------------
// OBJETO: obj_player
// EVENTO: Create
// ----------------------------------------------------------------------------

// Variables de movimiento y físicas (establecidas en módulos 4 y 5)
hsp = 0;
vsp = 0;
walk_spd = 4;
grav = 0.4;
jump_spd = -8.5;
grounded = false;

// Definición de los estados visuales del jugador
enum PLAYER_STATE {
    IDLE,
    RUN,
    JUMP,
    FALL
}

// Inicialización del estado actual y previo
state = PLAYER_STATE.IDLE;
state_previous = PLAYER_STATE.IDLE;

// Orientación horizontal del sprite (1 = derecha, -1 = izquierda)
facing = 1;

Observa que declaramos `facing = 1`. Aunque GameMaker utiliza la variable integrada `image_xscale` para escalar e invertir el dibujo de la instancia, almacenar la dirección deseada en una variable explícita (`facing`) antes de aplicarla a `image_xscale` permite desacoplar los controles de entrada de la renderización final y evita errores de escala no deseados.

Determinación del estado en el Evento Step

El flujo de ejecución en el evento Step debe estructurarse rigurosamente en etapas sucesivas. Si intentamos cambiar sprites mientras calculamos colisiones, el motor gráfico procesará datos inconsistentes. El orden canónico recomendado es el siguiente:

A continuación presentamos el bloque completo de evaluación de estados y asignación visual que debe integrarse en la sección final del evento Step de `obj_player`, justo después de resolver el movimiento horizontal, vertical y las colisiones con el suelo y paredes.

// ----------------------------------------------------------------------------
// OBJETO: obj_player
// EVENTO: Step (Sección final: Máquina de Estados Visuales)
// ----------------------------------------------------------------------------

// --- ETAPA 4: EVALUACIÓN DEL ESTADO SEGÚN CONDICIONES FÍSICAS ---
if (grounded) {
    // Si el jugador está sobre una superficie sólida
    if (hsp == 0) {
        state = PLAYER_STATE.IDLE;
    } else {
        state = PLAYER_STATE.RUN;
    }
} else {
    // Si el jugador está en el aire (no está grounded)
    if (vsp < 0) {
        state = PLAYER_STATE.JUMP;
    } else {
        state = PLAYER_STATE.FALL;
    }
}

// --- ETAPA 5: APLICACIÓN VISUAL Y CONTROL DE ANIMACIÓN ---
// Si hubo un cambio de estado en este cuadro, reiniciamos el índice de animación
if (state != state_previous) {
    image_index = 0;
}

// Selección del sprite según el estado determinado
switch (state) {
    case PLAYER_STATE.IDLE:
        sprite_index = spr_player_idle;
        image_speed = 1.0;
        break;
        
    case PLAYER_STATE.RUN:
        sprite_index = spr_player_run;
        // Ajuste opcional: la velocidad de animación se sincroniza con la velocidad real
        image_speed = 1.0;
        break;
        
    case PLAYER_STATE.JUMP:
        sprite_index = spr_player_jump;
        image_speed = 1.0;
        break;
        
    case PLAYER_STATE.FALL:
        sprite_index = spr_player_fall;
        image_speed = 1.0;
        break;
}

// --- ORIENTACIÓN HORIZONTAL (FACING) ---
// Solo actualizamos la dirección si el jugador se está moviendo activamente
if (hsp != 0) {
    facing = sign(hsp);
}

// Aplicamos la escala visual horizontal respetando la magnitud base
image_xscale = facing;

// Actualizamos el registro del estado previo para el siguiente cuadro
state_previous = state;