Doors and Multi-Room Transitions

Introduction to Level Transitions in GameMaker

In 2D platformer development, spatial progression keeps the player engaged. Reaching the end of a stage, crossing a threshold, or opening a gate should feel clear and rewarding. In GameMaker, every level, screen, or menu is structured within an asset called a Room. Switching levels therefore means telling the engine to unload the current room's data and load the next room's content into memory.

While switching rooms can be done with a single line of code, doing so carelessly introduces common issues: the screen cuts abruptly, the player spawns at incorrect coordinates in the new room, or accumulated data (such as coins and lives) unintentionally resets. In this lesson, we will build a modular, elegant, and reusable level-transition mechanic across our entire project, ensuring the player moves from one area to another using an interactive door or goal post and a smooth visual fade.

The Room Change Lifecycle

When executing a room change instruction in GameMaker using GML Code, the engine performs a series of critical cleanup and reconstruction steps in its execution order:

1. The 'Other -> Room End' event triggers on all active instances that contain this event. 2. All instances not marked as 'Persistent' are destroyed and freed from RAM. 3. The graphic structure and tile layers of the room you are leaving are unloaded. 4. Visual assets, background layers, and tilemaps of the new room are loaded. 5. Instances defined in the new room's layers are created, executing their respective 'Create' events. 6. The 'Other -> Room Start' event fires for all instances present in the new room.

💡 Remember that regular instance variables (such as 'x', 'y', or local variables created in an instance's Create event) are wiped out when that instance is destroyed upon exiting the room. To persist a value across room changes, you must store it in a global variable or in a persistent controller object.

Essential GML Room Control Functions

GameMaker provides built-in functions to query and control room flow. Here are the most essential ones used throughout this module:

💡 Avoid calling 'room_goto_next()' directly without verifying if a next room exists via 'room_next(room)'. Trying to navigate past the last room registered in your project will cause GameMaker to throw a fatal error, crashing the game.

Designing the Interactive Object: obj_puerta

Rather than creating a separate door object for every level ('obj_puerta_nivel1', 'obj_puerta_nivel2'), we apply modular design principles: a single 'obj_puerta' object capable of teleporting the player to any target room and any specific coordinates using per-instance variables.

Start by creating a sprite named 'spr_puerta'. This could be a 32x48-pixel wooden frame with a dark interior, or an animated portal drawn in the sprite editor with two or three frames. Set its collision mask to a precise or closed rectangle covering the area where the player will interact.

Next, create the object 'obj_puerta', assign it the 'spr_puerta' sprite, and uncheck 'Solid' (the player needs to overlap with the door rather than colliding with it like a solid wall). In its Create event, define the default values:

// Resource: obj_puerta
// Event: Create

// Target room for this door (default: no specific room)
destino_room = noone;

// Target coordinates where the player will spawn in the new room
destino_x = 0;
destino_y = 0;

// Flag to prevent multiple activations across consecutive frames
activada = false;

GameMaker allows overriding these variables on individual instances placed in the room. When placing an instance of 'obj_puerta' in a room, double-click it in the Room Editor, click 'Variables', and specify the target room name (such as 'rm_nivel_2') along with the exact arrival coordinates. You can also configure this using the instance's Creation Code directly in the room.

Detecting Activation: Collision and Interactivity

Classic platformers typically handle doors in one of two ways: entering automatically on contact (common for end-of-level goal posts or pipe exits), or pressing an interact key like the Up arrow or 'W' while standing in front of it. We will implement the second approach, giving players full control and preventing accidental room changes when moving near the doorway.

// Resource: obj_puerta
// Event: Step

// If the door has already been triggered, exit early
if (activada) exit;

// Check if the player is overlapping with the door
if (place_meeting(x, y, obj_jugador))
{
    // Check if the player presses the interact key / Up arrow
    var tecla_entrar = keyboard_check_pressed(vk_up) || keyboard_check_pressed(ord("W"));
    
    if (tecla_entrar)
    {
        // Validate that the target room exists in the project
        if (destino_room != noone && room_exists(destino_room))
        {
            activada = true;
            
            // Store target coordinates in global variables
            global.jugador_spawn_x = destino_x;
            global.jugador_spawn_y = destino_y;
            global.aplicar_spawn = true;
            
            // Create the transition effect instead of cutting abruptly
            var trans = instance_create_depth(0, 0, -9999, obj_transicion_fade);
            trans.sala_objetivo = destino_room;
        }
        else
        {
            show_debug_message("Warning: The door at (" + string(x) + ", " + string(y) + ") does not have a valid target room assigned.");
        }
    }
}

Controlling the Spawn Point in the New Room

A frequent pitfall for beginners is assuming the character will retain their position or that the new room will know where to place them. Unless 'obj_jugador' is marked persistent, loading 'rm_nivel_2' spawns the player at the exact coordinates set inside that room's editor.

To resolve this cleanly without complex pointer management, we use the 'Global Spawn Variables' pattern ('global.jugador_spawn_x' and 'global.jugador_spawn_y'). We initialize these variables in a game controller object or a global boot script, and configure the player object to read those coordinates upon entering any new room.

In the 'Create' event of our game controller object (for example, 'obj_game_manager'), initialize the variables:

// Resource: obj_game_manager
// Event: Create

global.jugador_spawn_x = -1;
global.jugador_spawn_y = -1;
global.aplicar_spawn = false;

Then, in 'obj_jugador', add the 'Other -> Room Start' event. This event fires automatically whenever a new room begins executing:

// Resource: obj_jugador
// Event: Other -> Room Start

// Check if the previous door requested repositioning the player
if (global.aplicar_spawn)
{
    x = global.jugador_spawn_x;
    y = global.jugador_spawn_y;
    
    // Reset the flag so regular room restarts retain normal placement
    global.aplicar_spawn = false;
    
    // Reset accumulated velocities to avoid shooting forward on entry
    hspeed = 0;
    vspeed = 0;
    if (variable_instance_exists(id, "vel_x")) vel_x = 0;
    if (variable_instance_exists(id, "vel_y")) vel_y = 0;
}