Configuración de la cámara seguidora en GameMaker

Introducción al sistema de visión en videojuegos 2D

Hasta este punto del curso, la mayoría de nuestras pruebas se han desarrollado en escenarios contenidos donde la acción transcurre dentro de los límites visibles de una única pantalla fija. Sin embargo, en el diseño clásico de juegos de plataformas (plataformeros 2D de estilo retro como Super Mario World, Sonic the Hedgehog o Celeste), el mundo del juego es sustancialmente más grande que la ventana de visualización del jugador. Para que el jugador pueda explorar cavernas subterráneas, cumbres montañosas o largos recorridos llenos de obstáculos, el motor debe decidir con precisión milimétrica qué porción del escenario proyectar en la pantalla en cada instante.

El sistema encargado de esta tarea es la cámara virtual. Lejos de ser un simple adorno, la cámara es una herramienta narrativa y mecánica fundamental: determina el ritmo de juego, proporciona anticipación frente a los peligros, previene saltos a ciegas (los temidos 'blind jumps') y comunica sensaciones físicas mediante sacudidas, aceleraciones y encuadres dramáticos. En GameMaker, el manejo de la visión se basa en una arquitectura de tres capas: la Room (escenario), la Camera (lente matemática) y el Viewport (puerto de visualización o monitor).

Fundamentos: Rooms, Cameras y Viewports

Para evitar confusiones habituales entre principiantes, es imprescindible clarificar la distinción entre estos tres conceptos fundamentales de GameMaker:

Imagina que la Room es una maqueta gigante de una ciudad en miniatura. La Camera es una cámara de cine que colocas sobre un trípode o un dron por encima de la maqueta, grabando un área de 480 por 270 milímetros. El Viewport es el televisor del salón donde sintonizas la señal que emite esa cámara de cine. Si la cámara se desplaza hacia la derecha, la imagen del televisor cambiará, aunque la maqueta completa permanezca inmóvil en la habitación.

Configuración nativa desde el Editor de Rooms

GameMaker ofrece un mecanismo integrado sin código para asignar una cámara seguidora directamente desde la interfaz gráfica del Inspector de Salas. Aunque este método tiene limitaciones en proyectos comerciales avanzados, es la forma más rápida de comprender el funcionamiento interno del subsistema de vistas.

Para activar este sistema paso a paso en tu sala de plataformas:

1. Abre en el Asset Browser la sala de tu nivel (por ejemplo, `rm_nivel_1`). 2. En el panel izquierdo de propiedades de la sala, despliega la sección denominada **Viewports and Cameras**. 3. Marca la casilla **Enable Viewports** (Habilitar puertos de vista). Si esta casilla no está marcada, GameMaker dibujará toda la sala estirada o recortada a la ventana principal sin utilizar cámaras. 4. Despliega la pestaña **Viewport 0** y marca la casilla **Visible**. 5. En la subsección **Camera Properties**, define el ancho y alto del encuadre. Para mantener la estética retro de nuestro proyecto con píxeles nítidos y formato panorámico 16:9, configuraremos `Width: 480` y `Height: 270`. 6. En la subsección **Viewport Properties**, define el tamaño con el que se mostrará esa ventana. Puedes fijar `Width: 1920` y `Height: 1080` (una relación exacta de 4 veces la resolución interna). 7. En la subsección **Object Following**, haz clic en el selector de objetos y selecciona a nuestro personaje jugable: `obj_jugador`. 8. Ajusta los bordes horizontales y verticales (**Horizontal Border** y **Vertical Border**). Estos valores representan la distancia mínima (en píxeles) que el jugador puede aproximarse al borde del encuadre antes de que la cámara comience a empujar su posición. Configura `Horizontal Border: 200` y `Vertical Border: 100`. 9. Los campos **Horizontal Speed** y **Vertical Speed** determinan la velocidad máxima a la que se desplazará la cámara para alcanzar al jugador. Si colocas `-1`, la cámara seguirá al jugador de manera instantánea y rígida.

💡 Importante: Si dejas la velocidad en -1, cada micro-movimiento o salto del jugador se reflejará sin amortiguación en la pantalla, lo que puede causar fatiga visual y sensación de rigidez mecánica. Sin embargo, si estableces una velocidad fija como 4 o 6 píxeles por cuadro, si el jugador se mueve más rápido que ese valor (por ejemplo, corriendo o cayendo), el personaje se saldrá de la pantalla.

Debido a estas limitaciones del seguimiento automático básico (carencia de aceleración elástica, incapacidad para anticipar caídas, falta de sacudidas de pantalla o zooms programados), en desarrollo profesional se suele prescindir del 'Object Following' del editor de salas en favor de un objeto controlador dedicado programado en GML Code.

El Objeto Controlador de Cámara: obj_camara

Para tener control total sobre la experiencia de visualización, crearemos un objeto gestor llamado `obj_camara`. Este objeto será el único responsable de calcular las coordenadas óptimas de la vista, garantizar que la cámara no revele los bordes vacíos fuera del nivel y aplicar técnicas de suavizado matemático.

Crea un nuevo objeto en tu árbol de recursos y nómbralo `obj_camara`. No requiere ningún sprite asignado, ya que actuará exclusivamente como un ente lógico invisible en la escena.

Inicialización en el Evento Create

En el evento **Create** de `obj_camara`, inicializaremos la cámara virtual activa, definiremos la resolución de diseño y configuraremos el puerto de vista mediante las funciones del motor de GameMaker. Añade el siguiente código en el evento Create:

/// Evento Create de obj_camara

// 1. Definir la resolución base del encuadre (formato 16:9 retro)
ancho_camara = 480;
alto_camara  = 270;
escala_ventana = 3; // Escala para la ventana en el escritorio (480*3 = 1440, 270*3 = 810)

// 2. Crear la cámara interna de GameMaker
camara = camera_create_view(0, 0, ancho_camara, alto_camara, 0, -1, -1, -1, 0, 0);

// 3. Habilitar el sistema de vistas y enlazar la cámara al Viewport 0
view_enabled = true;
view_visible[0] = true;
view_set_camera(0, camara);

// 4. Configurar el tamaño físico de la ventana y el búfer de dibujo (Application Surface)
window_set_size(ancho_camara * escala_ventana, alto_camara * escala_ventana);
surface_resize(application_surface, ancho_camara * escala_ventana, alto_camara * escala_ventana);

// Centrar la ventana en el monitor del jugador tras el redimensionamiento
alarm[0] = 1;

// 5. Variables de seguimiento e interpolación
objetivo = obj_jugador;
suavizado = 0.1; // Factor de interpolación (entre 0.01 y 1.0)

// Posición inicial centrada en el objetivo si existe
if (instance_exists(objetivo)) {
    x = objetivo.x - (ancho_camara / 2);
    y = objetivo.y - (alto_camara / 2);
} else {
    x = 0;
    y = 0;
}

// Aplicar la posición inicial directamente a la cámara
camera_set_view_pos(camara, x, y);

Para asegurarnos de que la ventana quede centrada en la pantalla de la computadora después de llamar a `window_set_size()`, añadimos el evento **Alarm 0** en `obj_camara` con una sola instrucción:

/// Evento Alarm 0 de obj_camara
window_center();

La elección crítica del evento: ¿Step o End Step?

Uno de los errores más frecuentes en el desarrollo con GameMaker es colocar la lógica de seguimiento de la cámara en el evento **Step**. Si la cámara actualiza su posición en el evento Step, se produce una condición de carrera temporal dependiente del orden de ejecución interna de las instancias.

Si `obj_camara` ejecuta su evento Step antes de que `obj_jugador` procese sus pulsaciones de teclado, velocidades y colisiones en su propio evento Step, la cámara se posicionará basándose en las coordenadas anteriores del jugador. Cuando el jugador se mueva un instante después, el renderizado final dibujará al personaje desfasado un fotograma con respecto al fondo. El resultado visual es un temblor o vibración incómoda (conocida en inglés como 'camera jitter') que degrada notablemente la fluidez visual.

Por esta razón, la cámara debe posicionarse SIEMPRE en el evento **End Step** (Paso Final). En este evento, GameMaker garantiza que todas las entidades del juego ya han resuelto sus velocidades, colisiones físicas e integraciones de movimiento, permitiendo que la cámara capture la posición espacial definitiva del jugador antes de que comiencen los eventos de dibujo (**Draw**).

Seguimiento elástico con Interpolación Lineal (lerp)

Un seguimiento cinematográfico y agradable no clava rígidamente al personaje en el centro geométrico de la pantalla, sino que utiliza una amortiguación elástica. En matemáticas y programación de videojuegos, esto se logra mediante la función `lerp()` (abreviatura de *Linear Interpolation*).

La función `lerp(a, b, t)` toma un punto de partida `a`, un punto destino `b`, y un porcentaje o factor normalizado `t` (donde 0 representa el 0% y 1 representa el 100%). Cada fotograma, la función calcula una posición intermedia desplazándose un porcentaje de la distancia restante. A medida que la cámara se aproxima al objetivo, la distancia se reduce, produciendo una suave desaceleración orgánica.