Managing Persistent Data Across Levels

The Persistence Challenge: Why Does Data Disappear Between Levels?

In previous lessons, you learned how to build interactive rooms, place obstacles, and configure portals or doors that transport the player character from one room to another using the `room_goto()` function. However, when testing that transition for the first time, a classic game development problem emerges: the player collects coins in the first level, earns 350 points, walks through the exit door into level two, and suddenly their score drops back to zero while their lives reset to default. This behavior often baffles beginners, but it stems from a fundamental GameMaker operating principle: room memory cleanup.

By default, whenever GameMaker executes a room transition, it automatically destroys all active instances in the departing room to free system RAM. That means your player object (`obj_jugador`), enemies, collectibles, and UI panels vanish entirely. When the new room loads, the engine parses the layout you configured in the Room Editor and creates brand-new instances from scratch. As they instantiate, each object runs its Create event again, resetting any internal variables to factory defaults. If you wrote `puntos = 0;` and `vidas = 3;` in your player's Create event, every new level inevitably resets the user's hard-earned progress.

To build a cohesive gameplay experience where players feel continuous progression across multiple worlds and challenges, you must decouple vital data from the transient physical instances in each level. There are two primary approaches in GameMaker to solve this problem: making specific objects persistent, or storing critical data in global-scoped variables. Throughout this lesson, we will examine both techniques, focusing especially on global variables—the cleanest, most predictable, and easiest-to-debug industry standard for both beginners and experienced developers.

Variable Scopes in GameMaker: Local, Instance, and Global

To master persistence, you must clearly understand how GameMaker categorizes and isolates memory using variable scopes. A variable is simply a named container that holds a value in memory; its scope dictates which parts of your code have permission to read or modify that container, as well as how long it survives during the game's lifecycle.

Local variables (declared with the `var` keyword) are ephemeral and used for short calculations within a single step. Instance variables belong to a specific object instance: if you have three coins on screen, each possesses its own `x` and `y` instance variables. If a coin is destroyed, its variables disappear with it. Global variables, on the other hand, do not belong to any physical entity in the room; they attach directly to the engine's core memory space. This independence makes them the ideal mechanism for tracking remaining health, player inventory, accumulated currency, and high scores.

Strategies for Initializing Global Variables

One of the most common pitfalls when working with global variables is initializing them inside the Create event of an object that respawns in every room, such as the player or a HUD controller. If you place `global.puntuacion = 0;` inside `obj_jugador`'s Create event, every time a new level loads and the player spawns, that line executes and overwrites accumulated score back to zero. To prevent this, global variables must be initialized exactly once during game startup.

In modern GameMaker versions, there are two secure, professional ways to guarantee a single, bulletproof initialization: using an auto-executing configuration script, or routing startup through a dedicated initialization room (`rm_init`). Let's examine both so you can pick the right fit for your project structure.

Method 1: Declaration in an Initialization Script (Recommended in Modern GameMaker)

Any code written at the root of a GML script file (outside of any explicit `function` declaration) executes automatically the very moment the game boots, before the first room even renders on screen. This behavior makes scripts ideal for declaring all initial global states in a clean, centralized configuration file.

Create a new Script asset in the Asset Browser and name it `scr_game_init`. Inside, add the following foundational configuration code:

// Script: scr_game_init
// This code executes once when the game boots up.

// Player progression and state
global.vidas = 3;
global.vidas_maximas = 3;
global.puntuacion = 0;
global.monedas = 0;

// Level control tracking
global.nivel_actual = 1;
global.juego_pausado = false;

// Debug log in the output console
show_debug_message("Global system initialized successfully: Lives = " + string(global.vidas));

By prefixing these variables with `global.`, GameMaker allocates dedicated global memory immediately. From that point on, any room or object can read or write `global.puntuacion` without any risk of accidental reinitialization during level transitions.

Method 2: Dedicated Startup Room (rm_init)

The second method, frequently seen in larger games with complex title menus, uses a lightweight, empty room placed at the absolute top of the room list in the Asset Browser, conventionally named `rm_init` or `rm_preload`. This room contains only one instance: a manager object (`obj_game_manager`). In its Create event, this manager initializes your global data and immediately transitions to the title screen or Level 1 using `room_goto(rm_nivel_1)`.

💡 Golden Rule: Whichever method you choose, never initialize a persistent global variable inside the Create event of your player object or any entity placed directly within regular gameplay rooms.

The Central Controller Object: Creating obj_game_manager

Although global variables float independently in engine memory, software architecture best practices recommend having a dedicated controller object to handle overarching game logic: checking if lives have reached zero to trigger Game Over, firing celebration sound effects on high scores, or orchestrating scene transitions. We will name this object `obj_game_manager`.

Create a new object in the Asset Browser and call it `obj_game_manager`. You do not need to assign it a sprite, as it acts as an invisible coordinator. In its Object Properties panel, make sure to check the **Persistent** box.

When an object's **Persistent** flag is checked, GameMaker alters its default lifecycle: calling `room_goto()` will no longer destroy this instance. Instead, it travels smoothly into the incoming room, maintaining all its internal variables and running its events without interruption.

// Object: obj_game_manager
// Event: Create

// Check if another manager already exists to prevent duplicates
if (instance_number(obj_game_manager) > 1)
{
    instance_destroy();
    exit;
}

// Object will survive room transitions thanks to the Persistent property
persistent = true;

// Controller local tracking variable
tiempo_en_nivel = 0;

The `if (instance_number(obj_game_manager) > 1)` check is a simple Singleton safeguard. If you accidentally place an `obj_game_manager` in Level 1 and another in Level 2 in the Room Editor, the duplicate detects an existing manager arriving from the previous room and promptly destroys itself, preventing logic collisions.

Rewriting Collectibles: Adding to Global Memory

In earlier exercises, collecting a coin might have modified an instance variable directly on the player (`puntos += 10;`). Now that our global persistence system is ready, we need to update our collectible items (`obj_moneda`) so they write directly to global memory. This ensures collected points outlive the room in which they were picked up.

Open `obj_moneda`. If handling pickup collisions on the coin itself against `obj_jugador`, navigate to its Collision Event with `obj_jugador` and insert the following code:

// Object: obj_moneda
// Event: Collision with obj_jugador

// Increment global variables directly
global.monedas += 1;
global.puntuacion += 100;

// Bonus check: 100 coins award an extra life
if (global.monedas >= 100)
{
    global.monedas -= 100;
    global.vidas += 1;
    
    // Play extra life audio cue (if available)
    if (audio_exists(snd_vida_extra))
    {
        audio_play_sound(snd_vida_extra, 10, false);
    }
}

// Play standard coin collection sound
if (audio_exists(snd_moneda))
{
    audio_play_sound(snd_moneda, 5, false);
}

// Destroy this coin instance so it cannot be collected twice
instance_destroy();

Notice the architecture: when collecting a coin, it no longer matters whether the player reaches an exit door two seconds later or triggers a room shift immediately. The 100 points and the collected coin now live safely in global memory, ready to be read by any future room.