Main Level Assembly and Transition Screens

Game Flow and Screen Architecture

Up to this point in the course, you have built isolated mechanics: a player character with tight physical controls, platform and tilemap collisions, patrolling enemies, collectible coins, health bars, and interfaces drawn in the Draw GUI event. However, a commercial video game is not merely a collection of disconnected prototypes tested straight from the editor; it requires a structured and cohesive game flow.

Game flow describes the continuous journey the player experiences from launching the application to quitting it. For players to perceive a polished experience, the game must manage clean state changes: booting into a technical initialization room, presenting a functional main menu, transitioning into the fully assembled playable level, and culminating in resolution screens (Victory or Game Over) that allow restarting the loop without memory leaks or orphaned variables.

In GameMaker, this journey is orchestrated through an ordered sequence of Rooms and persistent control objects. If you switch rooms abruptly using a direct call to the built-in room_goto() function, the visual cut feels jarring, breaks immersion, and can cause visual stutter if the new room takes a frame or two to upload textures. For this reason, professional assembly demands an intermediate visual transition layer that masks state changes.

Room Planning and Hierarchy in the Asset Browser

The first step is auditing GameMaker's Asset Browser. The order in which rooms appear inside the 'Rooms' section in the room manager defines the default starting room of your project. While during development we often launch directly into whatever room we are currently editing, the final compiled build will always run the very first room listed from top to bottom.

For this complete platformer, we will establish a strict architecture composed of five essential rooms:

The rm_init room lasts for exactly one frame. Its sole purpose is to execute bootstrap code inside the Create event of a global initialization object and immediately transition to the main menu. This technique prevents repetitive global variable declarations inside rooms that will be visited multiple times.

The Visual Transition System: obj_transition

To execute smooth fades (fade out / fade in), we will create a persistent controller object called obj_transition. A persistent object (checked 'Persistent' in its properties) is not destroyed when changing rooms; it carries over intact between scenes while preserving its variables and active states.

The transition manager will operate as a simple three-state machine: idle, darkening the current screen (fade out), and brightening the new screen (fade in). We will use the Draw GUI event to render a solid black rectangle covering the entire viewport interface, unaffected by camera movement or world coordinates.

Create the object obj_transition in your Asset Browser, check its 'Persistent' box, and add the following logic to its Create event:

// Create Event of obj_transition
// Visual fade controls
alpha = 0;
fade_speed = 0.04;
target_room = noone;

// States: 0 = idle, 1 = fading out, 2 = fading in
transition_state = 0;

// Ensure the object does not duplicate if one already exists in memory
if (instance_number(obj_transition) > 1) {
    instance_destroy();
}

The next step is programming the progression logic in the Step event. When a transition is triggered (state 1), the alpha value increases progressively. The moment the screen turns completely black (alpha >= 1), we call room_goto() behind the dark veil and switch to state 2 to begin fading into the new room:

// Step Event of obj_transition
switch (transition_state) {
    case 1: // Fade Out phase
        alpha += fade_speed;
        if (alpha >= 1) {
            alpha = 1;
            if (target_room != noone && room_exists(target_room)) {
                room_goto(target_room);
            }
            transition_state = 2; // Transition to fade-in phase in the new room
        }
        break;
        
    case 2: // Fade In phase
        alpha -= fade_speed;
        if (alpha <= 0) {
            alpha = 0;
            target_room = noone;
            transition_state = 0; // Return to idle
        }
        break;
        
    case 0: // Idle
    default:
        alpha = 0;
        break;
}

To draw the overlay on top of all game elements, we use the Draw GUI event. By utilizing GUI rendering functions, we detach ourselves from world coordinates and camera view matrices:

// Draw GUI Event of obj_transition
if (alpha > 0) {
    var _gui_w = display_get_gui_width();
    var _gui_h = display_get_gui_height();
    
    draw_set_color(c_black);
    draw_set_alpha(alpha);
    draw_rectangle(0, 0, _gui_w, _gui_h, false);
    
    // Reset default drawing parameters so other objects remain unaffected
    draw_set_alpha(1.0);
    draw_set_color(c_white);
}

To make this system accessible from any script or event across the project, we will wrap the transition call inside a global convenience function. Create a Script named scr_transitions and add the following:

/// @function transition_to(_target)
/// @description Initiates a smooth transition to the specified room.
/// @param {Asset.GMRoom} _target Target room asset.
function transition_to(_target) {
    if (instance_exists(obj_transition)) {
        with (obj_transition) {
            if (transition_state == 0) {
                target_room = _target;
                transition_state = 1;
            }
        }
    } else {
        // Safety fallback if obj_transition has not been instantiated
        room_goto(_target);
    }
}

💡 Golden Rule of Drawing in GML: whenever you modify draw_set_alpha() or draw_set_color(), always restore them to their default values (1.0 and c_white) at the end of the block. Otherwise, any subsequent draw calls will inherit that transparency or tint, causing subtle HUD glitches and discolored character sprites.

Main Level Assembly: Layers, Actors, and Triggers

Now that the visual bridge is in place, we can assemble the interactive level inside rm_level_1. In earlier lessons, you set up tilemaps and placed standalone test instances. Now we will integrate the full environment using a strict Room Layer hierarchy that guarantees proper render order and optimal performance.

Open rm_level_1 and set up the following layer stack in the layer inspector, listed from top (foreground visual layer) to bottom (deepest background layer):

To connect the level to the victory screen or the next stage, we need an interactive goal object. We will create obj_door (or a level goal marker) using an easily identifiable door or shining banner sprite. This object will detect player contact and trigger the resolution sequence.

In the Collision event between obj_door and obj_player, implement the goal check:

// Collision Event of obj_door with obj_player
// If the player touches the goal, lock inputs and trigger victory
with (other) {
    can_move = false;
    hsp = 0;
    vsp = 0;
}

// Play victory sound effect if imported
if (audio_exists(snd_stage_clear)) {
    audio_play_sound(snd_stage_clear, 10, false);
}

// Start transition to victory screen
transition_to(rm_win);