Gestión de datos persistentes entre niveles

El reto de la persistencia: ¿Por qué desaparecen los datos al cambiar de nivel?

En las lecciones anteriores aprendiste a construir salas interactivas, colocar obstáculos y configurar portales o puertas que transportan al personaje de una habitación (`room`) a otra mediante la función `room_goto()`. Sin embargo, al probar esa transición por primera vez, surge un problema estructural clásico en el desarrollo de videojuegos: el jugador recoge monedas en el primer nivel, acumula 350 puntos, cruza la puerta hacia el nivel dos y, de repente, su marcador vuelve a marcar cero y sus vidas se restauran al valor inicial. Este fenómeno suele desconcertar a los desarrolladores principiantes, pero responde a una regla operativa fundamental de GameMaker: la limpieza de memoria entre salas.

Por defecto, cuando GameMaker ejecuta una transición de sala, destruye automáticamente todas las instancias presentes en la sala saliente para liberar la memoria RAM del dispositivo. Esto significa que tu objeto jugador (`obj_jugador`), los enemigos, los coleccionables y los paneles de interfaz desaparecen por completo. Cuando la nueva sala se carga, el motor lee el diseño que preparaste en el editor de salas y crea instancias completamente nuevas desde cero. Al crearse, cada objeto ejecuta nuevamente su evento Create, restableciendo cualquier variable interna a sus valores predeterminados de fábrica. Si definiste `puntos = 0;` y `vidas = 3;` en el Create de tu jugador, cada nivel nuevo reiniciará irremediablemente el progreso acumulado por el usuario.

Para construir una experiencia de juego cohesiva donde el jugador sienta que su esfuerzo tiene continuidad a lo largo de múltiples mundos y desafíos, necesitamos desacoplar los datos esenciales de la existencia física de las instancias temporales de cada nivel. Existen dos caminos principales en GameMaker para resolver este dilema: hacer que ciertos objetos sean persistentes o almacenar la información en variables de ámbito global. A lo largo de esta clase examinaremos ambas técnicas, centrándonos especialmente en las variables globales, que constituyen el estándar más limpio, predecible y fácil de depurar para principiantes y profesionales.

Ámbitos de variables en GameMaker: Locales, de instancia y globales

Para dominar la persistencia, es indispensable repasar con precisión quirúrgica cómo GameMaker clasifica y aísla la memoria a través de los ámbitos de variables (variable scopes). Una variable no es más que un contenedor con nombre que almacena un dato en la memoria; el ámbito determina quién tiene permiso para leer o modificar ese contenedor y durante cuánto tiempo existe en el ciclo de vida del juego.

Las variables locales (precedidas por la palabra clave `var`) son efímeras y se utilizan para cálculos matemáticos rápidos dentro de un solo paso de simulación. Las variables de instancia pertenecen al cuerpo de un objeto concreto: si tienes tres monedas en pantalla, cada una tiene su propia variable de instancia `x` e `y`. Si una moneda desaparece, sus variables desaparecen con ella. En cambio, las variables globales no le pertenecen a ningún objeto físico del escenario; pertenecen directamente al núcleo central del juego. Esta independencia las convierte en la herramienta perfecta para almacenar la salud restante, el inventario, las monedas y el récord de puntuación.

Estrategias de inicialización de variables globales

Uno de los errores más frecuentes al trabajar con variables globales es definir su valor inicial dentro del evento Create de un objeto que se repite en cada sala, como el jugador o el marcador. Si escribes `global.puntuacion = 0;` en el Create de `obj_jugador`, cada vez que cargues un nuevo nivel y el jugador nazca en la nueva posición, esa línea sobreescribirá la puntuación acumulada devolviéndola a cero. Para evitar esta trampa, las variables globales deben inicializarse exactamente una sola vez durante el arranque del juego.

En las versiones modernas de GameMaker, disponemos de dos métodos seguros y profesionales para lograr una inicialización única y blindada: el uso de scripts de configuración global automática y el diseño de una sala de arranque dedicada (`rm_init`). Analizaremos ambos mecanismos para que elijas el que mejor se adapte a tu flujo de trabajo.

Método 1: Declaración en un Script de inicialización (Recomendado en GameMaker moderno)

Cualquier fragmento de código escrito en la raíz de un script de GML (fuera de cualquier declaración de función) se ejecuta automáticamente en el mismísimo primer microsegundo en que arranca el juego, incluso antes de que se dibuje la primera sala en pantalla. Esta característica permite establecer el estado inicial de toda la aventura en un archivo centralizado y ordenado.

Crea un nuevo recurso de tipo Script en el panel del explorador de recursos (Asset Browser) y asígnale el nombre `scr_game_init`. Dentro de él, escribe el siguiente bloque de código fundamental:

// Script: scr_game_init
// Este código se ejecuta una sola vez al arrancar el juego completo.

// Progresión y estado del jugador
global.vidas = 3;
global.vidas_maximas = 3;
global.puntuacion = 0;
global.monedas = 0;

// Registro de control de niveles
global.nivel_actual = 1;
global.juego_pausado = false;

// Registro para depuración en la consola de salida
show_debug_message("Sistema global inicializado con éxito: Vidas = " + string(global.vidas));

Al declarar estas variables con el prefijo `global.`, GameMaker reserva el espacio de memoria de inmediato. A partir de ese momento, cualquier sala puede leer o reescribir `global.puntuacion` sin temor a que el valor vuelva a inicializarse inadvertidamente durante los cambios de escenario.

Método 2: Sala de precarga o inicialización (rm_init)

El segundo método, ampliamente utilizado en proyectos de mediana escala y con menús complejos, consiste en crear una sala vacía y ligera ubicada en la primera posición de la lista de salas en el Asset Browser, llamada convencionalmente `rm_init` o `rm_preload`. Esta sala solo contiene una instancia de un objeto gestor (`obj_game_manager`). En su evento Create, dicho objeto define las variables y, en la siguiente línea, salta inmediatamente al menú principal o al primer nivel mediante `room_goto(rm_nivel_1)`.

💡 Regla de oro: Sea cual sea el método que elijas, nunca declares el valor inicial de una variable global dentro del evento Create del objeto del jugador ni de ningún objeto que aparezca físicamente dentro de las salas de juego comunes.

El Objeto Controlador Central: Creación de obj_game_manager

Aunque las variables globales flotan de manera independiente en la memoria, es una buena práctica de arquitectura de software contar con un objeto coordinador que se encargue de supervisar la lógica global: detectar si el jugador se ha quedado sin vidas para enviarlo a la pantalla de Game Over, reproducir efectos de felicitación cuando se alcanza un nuevo récord o gestionar el paso ordenado entre fases. A este objeto lo llamaremos `obj_game_manager`.

Crea un nuevo objeto en el Asset Browser con el nombre `obj_game_manager`. No es necesario que le asignes ningún sprite, ya que actuará como una entidad lógica invisible en el mundo del juego. En su panel de propiedades, asegúrate de marcar la casilla **Persistent** (Persistente).

Cuando la casilla **Persistent** está activada en un objeto, GameMaker altera su ciclo de vida habitual: al cambiar de sala mediante `room_goto()`, la instancia de este objeto no se destruye; en su lugar, se traslada intacta a la nueva sala, conservando todas sus variables de instancia y continuando la ejecución de sus eventos sin interrupción.

// Objeto: obj_game_manager
// Evento: Create

// Verificamos si ya existe otro gestor para evitar duplicados indeseados
if (instance_number(obj_game_manager) > 1)
{
    instance_destroy();
    exit;
}

// El objeto no se destruirá al cambiar de sala gracias a la propiedad Persistent
persistent = true;

// Variable de control local del gestor
tiempo_en_nivel = 0;

El condicional `if (instance_number(obj_game_manager) > 1)` es una salvaguarda conocida como patrón Singleton simple. Si por descuido dejaste colocado un `obj_game_manager` en el editor del Nivel 1 y otro en el Nivel 2, el objeto duplicado detectará que ya hay un gestor veterano viniendo de la sala anterior y se autodestruirá de inmediato, protegiendo al juego de conflictos lógicos.

Reescritura de los coleccionables: Sumando a la memoria global

En el Módulo 7 programamos la recolección de monedas modificando una variable local dentro del jugador (`puntos += 10;`). Ahora que disponemos de un sistema persistente robusto, debemos actualizar el comportamiento de nuestros coleccionables (`obj_moneda`) para que alteren directamente la bolsa de recursos global. De esta forma, el valor ganado existirá al margen de la sala donde se recogió.

Abre el objeto `obj_moneda`. Si estás gestionando la colisión dentro de la propia moneda frente al jugador, accede a su evento de colisión con `obj_jugador` y escribe el siguiente bloque de código depurado:

// Objeto: obj_moneda
// Evento: Collision con obj_jugador

// Incrementamos las variables globales directamente
global.monedas += 1;
global.puntuacion += 100;

// Comprobación de bonificación: 100 monedas otorgan una vida extra
if (global.monedas >= 100)
{
    global.monedas -= 100;
    global.vidas += 1;
    
    // Reproducir sonido especial de vida extra (si está disponible en audio)
    if (audio_exists(snd_vida_extra))
    {
        audio_play_sound(snd_vida_extra, 10, false);
    }
}

// Reproducir sonido de moneda común
if (audio_exists(snd_moneda))
{
    audio_play_sound(snd_moneda, 5, false);
}

// Destruir la moneda recolectada para que no se sume dos veces
instance_destroy();

Fíjate en la lógica: al recolectar la moneda, no nos importa si el jugador cambia de nivel diez segundos después o salta por una puerta inmediatamente. Los 100 puntos y la moneda recolectada ya no residen en la memoria efímera de la sala, sino en las variables globales, listas para ser leídas por cualquier sala futura.