Prueba integral del videojuego de principio a fin

Introducción a la prueba integral y el aseguramiento de calidad

A lo largo de los diez módulos previos y de las clases anteriores de este Módulo 11, has construido componente por componente los pilares de un videojuego de plataformas bidimensional: el motor de movimiento con simulación de inercia y gravedad, la detección de colisiones horizontales y verticales, las máquinas de estados finitos para la animación, los enemigos patrulleros, los coleccionables, el sistema de interfaz gráfica (HUD), el gestor de audio y la transición entre múltiples niveles. Sin embargo, un ensamblaje técnico no garantiza por sí solo una experiencia sólida y libre de fallos.

La prueba integral (a menudo denominada en la industria como *End-to-End Playtesting* o pruebas de extremo a extremo) consiste en evaluar el videojuego como una unidad cohesiva e ininterrumpida. En lugar de comprobar un script o un objeto de manera aislada dentro de una sala de prueba provisional (*sandbox room*), la prueba integral recorre el camino real que experimentará el usuario final: desde el inicio de la aplicación en el menú principal, pasando por la pantalla de introducción, el desarrollo de todos los niveles secuenciales con sus riesgos y recompensas, hasta desembocar en la pantalla de victoria o en el reinicio tras el temido *Game Over*.

Es fundamental distinguir entre dos actividades que a menudo se confunden en los desarrolladores principiantes: jugar al propio juego por diversión y evaluar metódicamente el software con mentalidad de control de calidad (*Quality Assurance* o QA). Cuando juegas como creador, tu subconsciente tiende a tomar los caminos previstos, respetar los tiempos programados y evitar los bordes problemáticos de la geometría. La prueba metodológica exige exactamente lo opuesto: forzar los límites de la lógica, presionar teclas de manera inesperada, ejecutar combinaciones de acciones simultáneas y explorar cada rincón con el objetivo explícito de hacer que el juego falle para poder subsanarlo antes del lanzamiento.

El flujo completo del juego (Game Flow) y transiciones críticas

Para asegurar que el flujo de juego sea hermético, es necesario mapear de manera estricta todas las transiciones que conectan las salas (*rooms*) del proyecto. En GameMaker, la gestión inadecuada de salas suele ser la fuente principal de errores de referencia nula, duplicación de objetos gestores o fugas de memoria por estructuras de datos no liberadas.

Analicemos las fases del recorrido completo que debes verificar en tu proyecto:

Cualquier irregularidad en esta cadena interrumpe la inmersión del jugador. Si al perder todas las vidas y pulsar 'Reintentar' el jugador reaparece en el segundo nivel en lugar de comenzar desde el inicio con su puntuación reseteada, existe una desconexión en la lógica de control del gestor global. Si al cambiar de sala la música del nivel 1 se solapa con la del nivel 2 creando una cacofonía, la función de gestión de audio está fallando al detener el flujo previo.

Diseño y aplicación de una lista de comprobación (QA Checklist)

Una sesión de prueba exhaustiva nunca debe abordarse al azar. Los equipos profesionales emplean listas de comprobación estandarizadas (*checklists*) organizadas por áreas funcionales. A continuación, desglosamos la matriz de prueba que debes aplicar de forma secuencial sobre tu prototipo completo.

1. Mecánicas del Jugador y Físicas Básicas

Comienza verificando la respuesta de los controles en un entorno estático y bajo movimiento continuo:

2. Combate, Riesgos y Puntos de Control

A continuación, somete al personaje a las amenazas del nivel para certificar que el ciclo de vida y daño funcione con solidez matemática:

3. Coleccionables, Interfaz y Audio

Finalmente, valida la sincronización sensorial y visual con los datos lógicos internos:

Casos límite (Edge Cases) y pruebas de esfuerzo

Un caso límite (*edge case*) es una situación que ocurre únicamente en extremos de los parámetros de operación, a menudo cuando dos o más eventos que raramente coinciden se ejecutan exactamente en el mismo fotograma de simulación (*step*). Estos errores son los más difíciles de detectar en pruebas superficiales, pero son los que con mayor frecuencia frustran a los jugadores que adquieren o prueban una versión pública.

Veamos los tres casos límite más críticos en juegos de plataformas 2D desarrollados en GameMaker y cómo ponerlos a prueba:

💡 Regla de oro de la desactivación de instancias: Si utilizas 'instance_deactivate_all(true)' para pausar tu juego, asegúrate siempre de que el objeto que contiene el evento que escucha la pulsación de despausa sea persistente y no sea desactivado. En caso contrario, el motor jamás volverá a evaluar el evento Step del gestor, requiriendo forzar el cierre del proceso.

Implementación de herramientas de asistencia para pruebas (Debug Suite)

Probar un juego completo una y otra vez de forma lineal es sumamente ineficiente si cada vez que modificas una variable en el nivel 2 debes completar el nivel 1 de forma manual. Para acelerar las pruebas integrales, los desarrolladores profesionales incorporan atajos de teclado para depuración (*debug hotkeys*). Estas funciones permiten saltar de sala, modificar recursos al instante o visualizar datos de telemetría.

Es indispensable estructurar estos atajos de manera que dependan de una única variable macro o condicional que pueda deshabilitarse de inmediato al momento de compilar la versión definitiva, evitando que los usuarios finales accedan a ellos de manera accidental.

A continuación, se presenta la implementación recomendada para integrar un sistema de control de pruebas dentro de nuestro gestor global de juego (denominado comúnmente obj_game_manager).

// ====================================================================
// OBJETO: obj_game_manager
// EVENTO: Create
// ====================================================================

// Bandera que activa o desactiva las herramientas de depuración.
// Antes de exportar el juego comercial, debe establecerse en false.
global.debug_mode = true;

// Bandera para visualización de máscaras de colisión e información técnica
global.show_debug_overlay_custom = false;

// ====================================================================
// OBJETO: obj_game_manager
// EVENTO: Step
// ====================================================================

// Evaluar únicamente si el modo de depuración está habilitado
if (global.debug_mode) {
    
    // F1: Reiniciar la sala actual de inmediato para probar escenarios repetitivos
    if (keyboard_check_pressed(vk_f1)) {
        room_restart();
    }
    
    // F2: Avanzar directamente a la siguiente sala en la jerarquía del Asset Browser
    if (keyboard_check_pressed(vk_f2)) {
        if (room_next(room) != -1) {
            room_goto_next();
        } else {
            // Si no hay más salas, regresar a la primera (bucle de prueba)
            room_goto(rm_menu);
        }
    }
    
    // F3: Restaurar salud al máximo y recuperar vidas en el objeto del jugador
    if (keyboard_check_pressed(vk_f3)) {
        if (instance_exists(obj_player)) {
            obj_player.hp = obj_player.max_hp;
            global.player_lives = 3;
        }
    }
    
    // F4: Otorgar coleccionables y puntuación inmediata para probar el HUD
    if (keyboard_check_pressed(vk_f4)) {
        global.coins += 10;
        global.game_score += 100;
    }
    
    // F5: Alternar el panel de telemetría e información interna en pantalla
    if (keyboard_check_pressed(vk_f5)) {
        global.show_debug_overlay_custom = !global.show_debug_overlay_custom;
    }
}

Además del manejo de atajos por teclado, disponer de información en tiempo real sobre el estado del motor resulta invaluable para diagnosticar caídas de rendimiento (*stuttering*), fugas de memoria o problemas en la frecuencia de actualización de fotogramas. Para ello, aprovechamos el evento Draw GUI del mismo gestor.

// ====================================================================
// OBJETO: obj_game_manager
// EVENTO: Draw GUI
// ====================================================================

// Solo dibujar el panel si las funciones de depuración están encendidas
if (global.debug_mode && global.show_debug_overlay_custom) {
    
    // Configuración estética del panel de depuración
    draw_set_color(c_black);
    draw_set_alpha(0.7);
    draw_rectangle(10, 10, 320, 190, false);
    draw_set_alpha(1.0);
    
    draw_set_color(c_lime);
    draw_set_font(-1); // Usar la tipografía predeterminada del sistema para máxima legibilidad
    
    // Métricas del motor y la sala actual
    draw_text(20, 20, "--- TELEMETRÍA DE DEPURACIÓN ---");
    draw_text(20, 40, "FPS reales: " + string(fps_real));
    draw_text(20, 60, "FPS objetivo: " + string(fps));
    draw_text(20, 80, "Instancias activas: " + string(instance_count));
    draw_text(20, 100, "Sala actual: " + room_get_name(room));
    
    // Telemetría específica del jugador si existe en la sala
    if (instance_exists(obj_player)) {
        draw_text(20, 125, "Jugador X: " + string(round(obj_player.x)) + " | Y: " + string(round(obj_player.y)));
        draw_text(20, 145, "Velocidad H: " + string(obj_player.hsp) + " | V: " + string(obj_player.vsp));
        draw_text(20, 165, "En el suelo (grounded): " + string(obj_player.grounded));
    } else {
        draw_set_color(c_red);
        draw_text(20, 125, "Jugador: [NO DETECTADO EN SALA]");
    }
    
    // Restaurar el color base de dibujado para no alterar otros elementos del GUI
    draw_set_color(c_white);
}

Con estas herramientas activas, verificar el balance de los niveles se vuelve una tarea ágil y metódica. Puedes saltar directamente al segundo nivel con la tecla F2, probar si una plataforma es alcanzable observando los valores exactos de hsp y vsp en pantalla con F5, y restaurar la salud de inmediato con F3 tras probar un salto riesgoso contra pinchos.