Diseño y programación de un enemigo patrullero básico

Introducción al comportamiento autónomo en videojuegos 2D

Hasta este punto del curso, la interacción en nuestro proyecto de plataformas ha estado impulsada principalmente por la entrada del usuario: el jugador presiona una tecla o mueve una palanca, y el personaje responde en pantalla. Sin embargo, para que un mundo de videojuego se sienta vivo, desafiante y dinámico, es imprescindible introducir entidades cuyos movimientos respondan a reglas lógicas internas e independientes de los controles del jugador. Este conjunto de reglas predefinidas constituye lo que en desarrollo de videojuegos denominamos Inteligencia Artificial (IA) básica o scripting de comportamiento.

El arquetipo fundamental de la IA en los juegos de plataformas bidimensionales es el enemigo patrullero. Desde los icónicos Goombas de Super Mario Bros. hasta los metools de Mega Man o los caballeros errantes de Hollow Knight, el patrón de desplazamiento horizontal constante de izquierda a derecha, rebotando contra las paredes o evitando precipicios, es una convención de diseño clásica. En esta clase, crearemos desde cero un enemigo de patrulla que se desplazará de forma autónoma por el escenario, interactuará con las plataformas existentes (`obj_wall`) y cambiará de dirección al detectar un obstáculo sólido.

Preparación de recursos: Sprite y máscara de colisión

Antes de escribir una sola línea de código, debemos preparar la representación gráfica de nuestro enemigo y configurar adecuadamente su geometría de colisión en GameMaker. La precisión física y visual dependerá directamente de cómo definamos el origen del sprite y su máscara.

Comenzaremos creando un nuevo recurso de tipo Sprite en el panel del Asset Browser (clic derecho en la carpeta de Sprites -> Create -> Sprite) y le asignaremos el nombre canónico `spr_enemy_patrol`. Para mantener la coherencia estética con nuestro protagonista retro, utilizaremos una resolución de 16x16 o 32x32 píxeles. Si aún no cuentas con una animación final de caminado, puedes dibujar un bloque o criatura estilizada de color distintivo (por ejemplo, rojo o púrpura) con dos ojos que apunten claramente hacia la derecha.

💡 Regla de oro de orientación: Por convención universal en el desarrollo de videojuegos 2D, todos los sprites con dirección lateral deben dibujarse orientados hacia la DERECHA de forma predeterminada. Esto simplifica los cálculos matemáticos, ya que la dirección positiva del eje horizontal (+X) se corresponde directamente con un escalado positivo de la imagen.

Existen dos parámetros críticos que deben configurarse dentro del editor de sprites de `spr_enemy_patrol`:

Una vez creado y configurado el sprite, crearemos el objeto correspondiente. Haz clic derecho en la carpeta de Objetos, selecciona Create -> Object, nómbralo `obj_enemy_patrol` y asígnale el sprite `spr_enemy_patrol`. No es necesario marcar la casilla 'Solid' integrada de GameMaker; gestionaremos todas las interacciones físicas mediante programación explícita en GML Code para garantizar un control exacto y libre de comportamientos anómalos.

Estructura de variables en el Evento Create

El enemigo necesita almacenar en memoria su estado cinemático: a qué velocidad camina, hacia qué lado se mueve en cada instante, su velocidad vertical actual y la fuerza de gravedad que lo mantiene anclado al suelo. Todas estas variables deben inicializarse en el evento **Create** de `obj_enemy_patrol`.

Abre `obj_enemy_patrol`, añade el evento **Create** y escribe el siguiente bloque de código en GML:

/// @description Inicialización del enemigo patrullero

// Parámetros de movimiento horizontal
move_speed = 1.5;         // Magnitud de desplazamiento en píxeles por fotograma
move_dir = 1;             // Dirección: 1 = Derecha, -1 = Izquierda
hsp = 0;                  // Velocidad horizontal calculada (hspeed personalizada)

// Parámetros de movimiento vertical y gravedad
vsp = 0;                  // Velocidad vertical actual
grav = 0.3;               // Fuerza gravitatoria descendente
vsp_max = 8;              // Límite terminal de caída libre

// Sincronización visual inicial
image_xscale = move_dir;

Analicemos la lógica detrás de estas variables. En lugar de utilizar las variables integradas `hspeed` y `vspeed` de GameMaker —las cuales mueven la instancia automáticamente de forma interna antes de que podamos comprobar colisiones precisas—, declaramos `hsp` y `vsp`. Esta técnica, que ya utilizamos al programar al jugador en módulos anteriores, nos permite calcular exactamente hacia dónde desea moverse el objeto y verificar si el espacio está libre antes de modificar sus coordenadas reales `x` e `y`.

La variable `move_dir` actúa como un vector unitario unidimensional. Solo tomará dos valores en esta implementación: `1` (hacia la derecha) o `-1` (hacia la izquierda). Al multiplicar `move_dir` por `move_speed`, obtenemos de forma directa la velocidad y sentido exactos del movimiento sin necesidad de ramificar el código con múltiples condicionales.

Lógica de movimiento y colisiones en el Evento Step

El evento **Step** se ejecuta una vez por cada fotograma del juego (habitualmente 60 veces por segundo). Aquí procesaremos la física elemental, evaluaremos las colisiones con la geometría sólida (`obj_wall`) e invertiremos la dirección de avance cuando el enemigo impacte de frente contra un obstáculo.

Añade el evento **Step -> Step** a `obj_enemy_patrol` y añade el siguiente código estructurado en tres fases: cálculo de fuerzas, resolución de colisiones y actualización de coordenadas.

/// @description Lógica de patrulla y colisiones físicas

// =========================================================================
// 1. APLICACIÓN DE GRAVEDAD
// =========================================================================
if (vsp < vsp_max) {
    vsp += grav;
}

// =========================================================================
// 2. CÁLCULO DE VELOCIDAD HORIZONTAL
// =========================================================================
hsp = move_dir * move_speed;

// =========================================================================
// 3. DETECCIÓN Y RESOLUCIÓN DE COLISIÓN HORIZONTAL (PAREDES)
// =========================================================================
// Comprobamos si en la posición hacia la que nos movemos existe un objeto sólido
if (place_meeting(x + hsp, y, obj_wall)) {
    // Nos aproximamos píxel a píxel hasta quedar pegados al obstáculo
    while (!place_meeting(x + sign(hsp), y, obj_wall)) {
        x += sign(hsp);
    }
    
    // Detenemos el desplazamiento en este fotograma
    hsp = 0;
    
    // Invertimos el sentido de la marcha para los siguientes fotogramas
    move_dir = -move_dir;
}

// Aplicamos el desplazamiento horizontal resultante en el eje X
x += hsp;

// =========================================================================
// 4. DETECCIÓN Y RESOLUCIÓN DE COLISIÓN VERTICAL (SUELOS Y TECHOS)
// =========================================================================
if (place_meeting(x, y + vsp, obj_wall)) {
    // Nos aproximamos píxel a píxel verticalmente hacia la superficie
    while (!place_meeting(x, y + sign(vsp), obj_wall)) {
        y += sign(vsp);
    }
    
    // Anulamos la velocidad vertical al impactar contra el suelo o techo
    vsp = 0;
}

// Aplicamos el desplazamiento vertical resultante en el eje Y
y += vsp;

// =========================================================================
// 5. ORIENTACIÓN VISUAL (ESPEJADO DE SPRITE)
// =========================================================================
if (move_dir != 0) {
    image_xscale = move_dir;
}

Desglose matemático de la inversión de dirección

Observa con atención la línea `move_dir = -move_dir;`. Esta elegante operación matemática elimina la necesidad de escribir sentencias complejas con `if/else`. Si `move_dir` vale `1`, `-1 * 1` resulta en `-1`. En el siguiente ciclo, si vale `-1`, `-(-1)` resulta en `1`. Con una única línea conmutamos la orientación indefinidamente cada vez que se produce una colisión frontal.

La función `sign(hsp)` devuelve `1` si el valor es positivo, `-1` si es negativo y `0` si es cero. Al combinarla con el bucle `while (!place_meeting(x + sign(hsp), y, obj_wall))`, logramos un contacto 'pixel-perfect' (exacto al píxel). El enemigo nunca quedará suspendido a 0.5 píxeles de la pared ni se incrustará dentro de ella antes de dar media vuelta, eliminando vibraciones gráficas o atascamientos indeseados.

La función place_meeting frente a otras alternativas

En GameMaker existen tres funciones habituales para comprobar contactos entre objetos: `place_meeting`, `position_meeting` e `instance_place`. Es fundamental comprender sus diferencias para no utilizarlas erróneamente en el diseño de IA:

Prevención de caídas: Detección de precipicios (Ledge Detection)

Con el código implementado hasta este punto, el enemigo patrullará de pared a pared de forma impecable. No obstante, si situamos al enemigo sobre una plataforma suspendida en el aire que no cuenta con paredes a los lados, el enemigo caminará hacia el borde y caerá por efecto de la gravedad hasta aterrizar en el fondo del escenario.

En el diseño de niveles, frecuentemente deseamos que ciertos patrulleros permanezcan confinados a su plataforma asignada, custodiando un segmento elevado sin arrojarse al vacío. Para conseguir esto, dotaremos a nuestro enemigo de un 'sensor de suelo adelantado'.

La lógica consiste en proyectar una comprobación virtual ligeramente por delante del enemigo y unos píxeles por debajo de sus pies. Si en ese punto proyectado no hay suelo (`!position_meeting` o `!place_meeting`), significa que el enemigo se encuentra al borde de un abismo, por lo que debe frenar e invertir su marcha exactamente igual que si hubiera impactado contra un muro.

Esta comprobación debe ejecutarse antes de aplicar `x += hsp`, permitiendo que el enemigo reaccione de inmediato al borde antes de dar el paso que lo haría caer al vacío.