Level Testing (Playtesting) and Balancing

Introduction to Playtesting: The Novice Player's Perspective

Throughout this module, you have designed the spatial layout of your rooms, configured smooth camera tracking, and established data transitions between levels. However, every novice developer faces an invisible hurdle: loss of perspective. As the creator of your game, you know every pixel-perfect jump by heart, the exact patrol pattern of every enemy, and the precise moment a trap will trigger. You always know where to go because you placed the blocks yourself.

In game design, this phenomenon is known as the "curse of knowledge." It leads developers to perceive their own levels as overly easy or predictable, often tempting them to boost enemy speeds or shrink landing platforms. The usual outcome is an unbalanced game that feels unfair and confusing to a newcomer. This is where playtesting becomes essential: the deliberate, systematic practice of observing real people interact with your game to uncover discrepancies between what you intended to convey and what the player actually experiences.

It is crucial to distinguish between technical debugging and playtesting. Debugging targets errors in code—crashes, memory leaks, or syntax bugs, which we will address formally in Module 12. Playtesting evaluates the human experience: pacing, visual clarity, the tension curve, the frustration curve, and whether your design intentions read clearly. A level can be completely bug-free while still offering a tedious, exasperating experience.

Player Psychology: The Flow Channel and Frustration

In 2D platformer design, your primary goal is to keep the player inside the "flow channel" (a theory formulated by psychologist Mihály Csíkszentmihályi). This optimal psychological state occurs when a challenge balances harmoniously with the player's current skill level. If the challenge is too low relative to their abilities, boredom sets in; if the challenge drastically outpaces their skill or fails to provide the tools to learn, it induces anxiety, frustration, and ultimately a rage quit.

Frustration in a platformer rarely stems from high difficulty alone. Celebrated titles like Celeste or Super Meat Boy feature punishing difficulty curves, yet players praise them for feeling fair. Destructive frustration arises from three primary design flaws:

1. **Lack of Information (Blindness):** The player dies to obstacles they could neither predict nor anticipate, such as blind leaps of faith into unseen pits or falling hazards with no telegraphing.

2. **Rule Inconsistency:** A solid surface stops the player in one instance but lets an enemy projectile pass through in another, or collision boxes (hitboxes) mismatch the visible sprites.

3. **Disproportionate Punishment:** Forcing the player to replay three minutes of trivial, slow platforming just to re-attempt a tricky one-second jump creates resentment and mental fatigue.

Spatial Metrics and Mechanical Tolerances

Balancing is achieved through measurement, not guesswork. Before placing enemies or hazard pits in a GameMaker room, you must formalize your avatar's core spatial metrics. These metrics depend directly on the movement physics variables implemented in Modules 4 and 5 (`vspd`, `hspd`, `grav`, `jump_speed`).

If you design a gap that matches the player's exact mathematical maximum reach (for example, exactly 5 full tiles to the single pixel), a one-frame error will result in death. In a standard level—outside of dedicated precision-platformers or "Kaizo" hacks—your maximum designed jump distance should fall between 70% and 85% of the character's physical limit. Providing this margin of error absorbs human execution variance without inflicting frustrating penalties.

In-Engine Diagnostic Tools: Basic Telemetry

To balance objectively, you need concrete data. During playtests, you cannot rely solely on tester recall. If three people play your level, how many times did each person die in the midsection? Exactly how long did they spend trying to clear the moving platform sequence?

You can implement a lightweight telemetry and diagnostic system directly in GameMaker. We will build a persistent manager object, `obj_playtest_manager`, that tracks deaths per room, elapsed time, and renders an on-screen debug dashboard toggled by a hotkey during testing sessions.

/// @description obj_playtest_manager Create Event
// Make this object persistent so it tracks the session across rooms.
persistent = true;

// Toggle flag for the playtest overlay
show_playtest_overlay = true;

// Tracked metrics
session_timer = 0;           // Total elapsed frames across the session
room_timer = 0;              // Elapsed frames in the current room
deaths_current_room = 0;     // Deaths recorded in the current room
total_deaths = 0;            // Cumulative deaths across the entire session
coins_collected_room = 0;    // Coins collected in the current room

// Death coordinate history (used to identify spatial chokepoints)
death_positions_x = [];
death_positions_y = [];

In the same object's Step event, increment the timers and configure a hotkey to toggle data visibility on screen without disrupting the playtester's run.

/// @description obj_playtest_manager Step Event
// Increment timers
session_timer++;
room_timer++;

// Toggle visual metrics overlay with F1
if (keyboard_check_pressed(vk_f1)) {
    show_playtest_overlay = !show_playtest_overlay;
}

// Reset local counters upon room restart or level progression
// (Room transitions will trigger the 'Room Start' event)

In the Room Start event of `obj_playtest_manager`, reset the per-room counters while preserving your cumulative session totals:

/// @description obj_playtest_manager Other -> Room Start Event
room_timer = 0;
deaths_current_room = 0;
coins_collected_room = 0;

// Clear death coordinates from the previous room
death_positions_x = [];
death_positions_y = [];

Next, connect player deaths to this manager. Inside `obj_player`, wherever your character loses a life (such as colliding with a hazard or falling out of bounds, before restarting or respawning at a checkpoint), record the event:

/// Snippet to place inside obj_player death logic
if (instance_exists(obj_playtest_manager)) {
    obj_playtest_manager.total_deaths++;
    obj_playtest_manager.deaths_current_room++;
    
    // Record the exact coordinates where death occurred
    array_push(obj_playtest_manager.death_positions_x, x);
    array_push(obj_playtest_manager.death_positions_y, y);
    
    // Print confirmation to the GameMaker output console
    show_debug_message("PLAYTEST: Death recorded in Room [" + room_get_name(room) + "] Coords: (" + string(x) + ", " + string(y) + ")");
}

Finally, render these diagnostics cleanly on the screen using the Draw GUI event so you can monitor them while observing a tester:

/// @description obj_playtest_manager Draw GUI Event
if (!show_playtest_overlay) exit;

// Convert frames to seconds (assuming a target game speed of 60 FPS)
var _seconds_room = floor(room_timer / 60);
var _seconds_total = floor(session_timer / 60);

// Dashboard background styling
draw_set_font(-1);
draw_set_color(c_black);
draw_set_alpha(0.65);
draw_rectangle(10, 10, 310, 140, false);
draw_set_alpha(1.0);

draw_set_color(c_lime);
draw_text(20, 20, "-- PLAYTEST DIAGNOSTICS (F1) --");
draw_set_color(c_white);
draw_text(20, 42, "Room: " + room_get_name(room));
draw_text(20, 62, "Room Time: " + string(_seconds_room) + " s");
draw_text(20, 82, "Room Deaths: " + string(deaths_current_room));
draw_text(20, 102, "Total Deaths: " + string(total_deaths));
draw_text(20, 122, "Session Time: " + string(_seconds_total) + " s");

💡 Pro tip: During a formal session with external testers, hide the overlay using F1 so the UI does not distract them or influence their play style. Let the system record data quietly to the console via show_debug_message().

Playtesting Methodology in Practice

Inviting friends, family, or colleagues to try your game sounds simple, but gathering valid, actionable feedback requires a structured protocol. Many developers make the mistake of sitting next to the player and offering running commentary: "Jump there," "Watch out, that enemy is fast," "Don't go left." "Backseat gaming" invalidates the test by masking whether the game can communicate clearly on its own.

Keep these four golden rules in mind when running effective playtest sessions:

1. **Practice Strict Silence:** Do not explain how to play, do not specify buttons, and do not hint at puzzle solutions or jump timings. If the player gets lost or confused, it is an unmistakable sign that your visual design, tutorial pacing, or signposting needs improvement.

2. **Observe Non-Verbal Cues:** Pay close attention to physical reactions. Are they furrowing their brow? Sighing? Relaxing their shoulders in relief upon landing on a platform? If a player attempts a jump five times with neutral focus, but on the sixth attempt lets go of the keyboard or checks their phone, you have pinpointed their disengagement threshold.

3. **Use the "Think Aloud" Protocol:** Politely ask participants to verbalize their thought process as they play: "I think I need to climb up there," "I'm not sure what this lever does," "That enemy felt cheap because I couldn't see it coming." This gives you direct insight into their mental model without needing to interrupt them.

4. **Ask Open-Ended Follow-Up Questions:** When the session concludes (or if the player gives up), avoid leading questions like "Did you find Level 2 fun?" Instead, ask neutral, probing questions: "Which part felt the most confusing?", "If you could remove one obstacle from that room, which would it be?", "How would you describe the character's movement pacing?"