Pruebas de nivel (Playtesting) y balance

Introducción al Playtesting: La mirada del jugador novato

A lo largo de este módulo has diseñado la arquitectura espacial de tus salas (rooms), configurado cámaras suaves y establecido la transición de datos entre niveles. Sin embargo, existe un obstáculo invisible que afecta a todo desarrollador novato: la pérdida de perspectiva. Como creador de tu videojuego, conoces de memoria cada salto milimétrico, el patrón exacto de patrulla de cada enemigo y el momento preciso en el que aparecerá una trampa. Sabes hacia dónde caminar porque tú mismo colocaste los bloques.

Este fenómeno se conoce en el diseño de juegos como la «maldición del conocimiento». Provoca que el desarrollador perciba su propio nivel como excesivamente fácil o predecible, lo que a menudo le empuja a incrementar la velocidad de los enemigos o reducir las plataformas de aterrizaje. El resultado habitual es un juego desequilibrado que resulta injusto e incomprensible para un jugador nuevo. Aquí radica la importancia vital del playtesting o prueba de juego: el proceso deliberado y sistemático de observar a personas reales interactuar con tu obra para descubrir discrepancias entre lo que intentaste comunicar y lo que el jugador realmente experimenta.

Es fundamental distinguir entre depuración técnica (debugging) y playtesting. La depuración busca fallos en el código (crashes, fugas de memoria o errores de sintaxis que abordaremos formalmente en el Módulo 12). El playtesting evalúa la experiencia humana: el ritmo, la legibilidad visual, la curva de tensión, la curva de frustración y la claridad de las intenciones de diseño. Un nivel puede no contener una sola línea de código errónea y, al mismo tiempo, ser una experiencia tediosa o desesperante.

La psicología del jugador: El canal de flujo y la frustración

En el diseño de videojuegos de plataformas 2D, el objetivo central es mantener al jugador dentro del llamado «canal de flujo» (teoría formulada por el psicólogo Mihály Csíkszentmihályi). Este estado psicológico óptimo ocurre cuando el nivel de desafío de una tarea se equilibra armónicamente con la habilidad del sujeto que la ejecuta. Si el reto es muy bajo en relación con la destreza del jugador, sobreviene el aburrimiento; si el reto supera drásticamente su capacidad o no le proporciona herramientas para aprender, se genera ansiedad, frustración y, finalmente, el abandono de la partida (el clásico «rage quit»).

La frustración en un juego de plataformas rara vez proviene de una dificultad elevada per se. Obras aclamadas como Celeste o Super Meat Boy presentan niveles de dificultad extremos, pero son celebradas por su equidad. La frustración destructiva surge de tres fallos de diseño fundamentales:

1. **Falta de información (Ceguera):** Ocurre cuando el jugador muere por elementos que no podía prever ni anticipar, como los «saltos de fe» hacia fosos invisibles o trampas que caen sin previo aviso.

2. **Inconsistencia de reglas:** Sucede si un objeto sólido unas veces detiene al personaje y otras permite que un proyectil lo atraviese, o si las cajas de colisión (hitboxes) son mayores que los sprites visibles.

3. **Castigo desproporcionado:** Obligar al usuario a repetir tres minutos de saltos triviales y lentos para volver a intentar un salto difícil de un segundo genera resentimiento y fatiga mental.

Métricas espaciales y tolerancias mecánicas

El balance no se logra adivinando, sino midiendo. Antes de colocar enemigos o fosos en una room de GameMaker, debes formalizar las «métricas maestras» de tu avatar. Estas métricas están determinadas por las variables físicas que programamos en el Módulo 4 y 5 (`vspd`, `hspd`, `grav`, `jump_speed`).

Si diseñas un abismo que mide exactamente la distancia máxima física del personaje (por ejemplo, 5 tiles completos al píxel exacto), cualquier desviación de un solo frame por parte del jugador resultará en muerte. En un nivel estándar (no enfocado a un género de ultra-precisión extrema o Kaizo), la distancia máxima de diseño debe situarse entre el 70% y el 85% de la capacidad matemática del avatar. Dejar un margen de tolerancia permite absorber las imprecisiones humanas sin penalizaciones frustrantes.

Herramientas de diagnóstico en el motor: Telemetría básica

Para balancear objetivamente, necesitas datos. Durante las pruebas de juego no puedes confiar únicamente en la memoria de los evaluadores. Si tres personas jugaron el nivel, ¿cuántas veces murió cada una en el tramo central? ¿Cuánto tiempo tardaron en resolver la sección de las plataformas móviles?

Podemos implementar un sistema ligero de telemetría y diagnóstico en GameMaker. Crearemos un objeto gestor llamado `obj_playtest_manager` que registrará las muertes por nivel, el tiempo transcurrido y mostrará una interfaz de depuración rápida activable con una tecla durante las sesiones de prueba.

/// @description Create Event de obj_playtest_manager
// Este objeto debe ser persistente para registrar la sesión a través de rooms.
persistent = true;

// Bandera para activar/desactivar la visualización del panel de playtesting
show_playtest_overlay = true;

// Métricas registradas
session_timer = 0;           // Tiempo total en frames transcurridos
room_timer = 0;              // Tiempo transcurrido en la room actual
deaths_current_room = 0;     // Muertes registradas en la sala actual
total_deaths = 0;            // Muertes acumuladas en toda la sesión
coins_collected_room = 0;    // Monedas recogidas en la sala actual

// Historial de muertes por coordenadas (para detectar cuellos de botella espaciales)
death_positions_x = [];
death_positions_y = [];

En el evento Step del mismo objeto, actualizamos los contadores de tiempo y configuramos un atajo de teclado para alternar la visibilidad de los datos en pantalla sin interferir con la sesión del evaluador.

/// @description Step Event de obj_playtest_manager
// Incrementar cronómetros
session_timer++;
room_timer++;

// Alternar el panel visual de métricas pulsando la tecla F1
if (keyboard_check_pressed(vk_f1)) {
    show_playtest_overlay = !show_playtest_overlay;
}

// Detectar reinicio o cambio de nivel para reiniciar los contadores locales
// (Asumimos que al cambiar de room se ejecuta un evento 'Room Start')

En el evento Room Start de `obj_playtest_manager`, reiniciamos las variables locales de la room pero conservamos las métricas acumuladas de la partida global:

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

// Limpiamos los puntos de muerte específicos de la sala previa
death_positions_x = [];
death_positions_y = [];

Ahora necesitamos conectar la muerte del jugador con este gestor. En el objeto `obj_player`, dentro del script o bloque donde el personaje pierde su vida (por ejemplo, al colisionar con un enemigo o caer al vacío, antes de reiniciar o reaparecer en el checkpoint), ejecutamos el siguiente registro:

/// Fragmento a incluir en la lógica de muerte de obj_player
if (instance_exists(obj_playtest_manager)) {
    obj_playtest_manager.total_deaths++;
    obj_playtest_manager.deaths_current_room++;
    
    // Registrar la coordenada exacta donde ocurrió el deceso
    array_push(obj_playtest_manager.death_positions_x, x);
    array_push(obj_playtest_manager.death_positions_y, y);
    
    // Imprimir mensaje directo en la consola de depuración de GameMaker
    show_debug_message("PLAYTEST: Muerte registrada en Room [" + room_get_name(room) + "] Coords: (" + string(x) + ", " + string(y) + ")");
}

Finalmente, para visualizar estos indicadores de manera limpia en la pantalla mientras observamos jugar a un tercero, dibujamos el reporte en el evento Draw GUI:

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

// Convertir frames a segundos reales (asumiendo 60 FPS en Game Speed)
var _seconds_room = floor(room_timer / 60);
var _seconds_total = floor(session_timer / 60);

// Configuración visual del panel informativo
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, "-- DIAGNÓSTICO DE PLAYTEST (F1) --");
draw_set_color(c_white);
draw_text(20, 42, "Sala: " + room_get_name(room));
draw_text(20, 62, "Tiempo en Sala: " + string(_seconds_room) + " s");
draw_text(20, 82, "Muertes en Sala: " + string(deaths_current_room));
draw_text(20, 102, "Muertes Totales: " + string(total_deaths));
draw_text(20, 122, "Tiempo de Sesión: " + string(_seconds_total) + " s");

💡 Consejo técnico: Durante una sesión formal con evaluadores externos, mantén el panel oculto mediante la tecla F1 para no distraerlos ni condicionar su comportamiento. Deja que el sistema registre los datos internamente en la consola mediante show_debug_message().

Metodología de una sesión de Playtesting real

Conseguir que amigos, familiares o colegas prueben tu juego parece sencillo, pero obtener información útil y válida requiere seguir un protocolo estricto. La mayoría de los desarrolladores cometen el error de sentarse al lado del jugador y guiarlo: «Ahí tienes que saltar», «Cuidado que ese enemigo corre rápido», «No vayas por la izquierda». Hacer esto arruina por completo la prueba, pues invalida la capacidad del juego para comunicarse por sí mismo.

A continuación, se detallan las cuatro reglas de oro para conducir sesiones de playtesting eficaces:

1. **La ley del silencio absoluto:** No expliques cómo jugar, no digas qué botón presionar y no des pistas sobre los acertijos o saltos. Si el jugador no sabe qué hacer, es una señal inequívoca de que el diseño visual, el tutorial integrado o la composición del nivel han fallado.

2. **Observa el lenguaje no verbal:** Presta atención a las reacciones físicas. ¿Frunce el ceño? ¿Suspira profundamente? ¿Afloja los hombros de alivio al alcanzar una plataforma? Si el jugador repite un salto cinco veces con expresión neutra y a la sexta vez suelta el teclado o mira el teléfono móvil, has identificado el umbral de desconexión.

3. **La técnica del «Pensamiento en Voz Alta» (Think Aloud):** Pídele amablemente al participante que exprese en palabras lo que piensa mientras juega: «Creo que debo subir por allí», «No entiendo qué hace esa palanca», «Ese enemigo me pareció injusto porque no lo vi venir». Esto te otorga una ventana directa a su modelo mental sin necesidad de interrumpirlo.

4. **Preguntas abiertas tras la sesión:** Cuando el jugador termine (o decida abandonar), no hagas preguntas inductivas como: «¿Te pareció divertido el nivel 2?». Formula preguntas neutrales: «¿Cuál fue la parte donde sentiste mayor confusión?», «Si tuvieras que eliminar un obstáculo de la sala, ¿cuál sería?», «Describe el ritmo del personaje al moverse».