Puntos de control (Checkpoints)

El rol de los puntos de control en el diseño de videojuegos

En el desarrollo de plataformas 2D, el ritmo del juego y la curva de frustración del usuario están estrechamente ligados a la distancia entre los fallos y la reanudación de la partida. Si obligamos a un jugador a reiniciar un nivel entero de diez minutos tras cometer un pequeño error de cálculo en un salto, la experiencia se vuelve punitiva y desgastante. Los puntos de control (o checkpoints) son mecanismos de guardado temporal dentro de la memoria activa del juego que capturan el progreso alcanzado, permitiendo que el personaje reaparezca en una posición segura cercana a su último logro.

Desde una perspectiva de arquitectura en GameMaker, un punto de control no requiere necesariamente guardar archivos en el disco duro (un tema que suele reservarse para sistemas de partidas guardadas permanentes). En su forma más pura y eficiente para niveles individuales, consiste en recordar las coordenadas espaciales `(x, y)` de una zona validada dentro de la room actual, junto con el restablecimiento de ciertos valores vitales del jugador, como su velocidad residual o sus puntos de impacto. En esta lección aprenderás a construir este sistema desde cero utilizando GML Code, integrándolo de forma limpia con los sistemas de salud y colisiones desarrollados en las lecciones previas.

Estrategia técnica: ¿Dónde y cómo guardar las coordenadas?

Para que la posición de reaparición persista aun cuando la instancia de `obj_player` sea destruida, reiniciada o trasladada súbitamente, las coordenadas de guardado no deben depender exclusivamente del ciclo de vida del propio jugador. Si un jugador muere y su instancia se destruye (`instance_destroy()`), todas sus variables locales y de instancia desaparecen de la memoria de GameMaker. Existen dos vías principales para resolver esto de manera profesional en proyectos de nivel principiante e intermedio: utilizar variables globales accesibles desde cualquier entidad, o emplear un objeto controlador persistente (`obj_game_controller`).

En nuestro proyecto utilizaremos variables globales (`global.checkpoint_x` y `global.checkpoint_y`). Esta solución es directa, requiere pocas líneas de código, es muy legible para principiantes y permite que tanto los objetos de punto de control (`obj_checkpoint`) como las trampas o el propio jugador consulten y modifiquen estos valores en cualquier momento del ciclo de ejecución.

💡 Recuerda: las variables con el prefijo 'global.' pertenecen al contexto global de la máquina virtual de GameMaker. A diferencia de las variables declaradas con 'var' (temporales al bloque de código) o las variables sin prefijo (pertenecientes a la instancia actual), las globales conservan su valor entre cambios de eventos y destrucción de instancias.

Diseño del recurso visual: Creación de spr_checkpoint

Para que el jugador comprenda de manera intuitiva que ha alcanzado un lugar seguro, el punto de control debe ofrecer una respuesta visual inmediata. Crearemos un sprite representativo, como un tótem místico, una bandera o una lámpara tecnológica, que conste de al menos dos estados gráficos: inactivo y activado.

Dirígete al panel Asset Browser de GameMaker, haz clic derecho sobre la carpeta de sprites y selecciona Create -> Sprite. Asigna el nombre `spr_checkpoint`. Define un tamaño de 32x32 o 32x64 píxeles según la escala de tu personaje. Dibuja o importa dos subimágenes (fotogramas): el fotograma 0 representará el checkpoint apagado o la bandera recogida (color gris o rojo), mientras que el fotograma 1 representará el checkpoint encendido o la bandera desplegada (color verde o azul brillante). Asegúrate de establecer el punto de origen (Origin) en 'Bottom Center' (Centro Inferior), facilitando que la base del objeto encaje perfectamente con las baldosas del suelo del nivel.

Programación del objeto obj_checkpoint

Ahora crearemos el objeto interactivo en el Asset Browser: Create -> Object, nombrándolo `obj_checkpoint` y asignándole el sprite `spr_checkpoint`. Este objeto debe monitorear cuándo entra en contacto con el jugador, activar su apariencia visual, asegurarse de que no se reactive innecesariamente si ya fue activado, y opcionalmente apagar otros checkpoints anteriores si se desea un comportamiento de guardado secuencial.

Comenzaremos configurando su evento Create para inicializar su estado interno. En este evento determinaremos que la animación se congele en el fotograma inactivo mediante la variable integrada `image_speed`.

// Objeto: obj_checkpoint
// Evento: Create

// El checkpoint inicia apagado y sin reproducir animación en bucle
is_active = false;
image_speed = 0;
image_index = 0;

A continuación, gestionaremos la interacción con el jugador. Esto puede realizarse mediante un evento Collision formal con `obj_player` o comprobándolo dentro del evento Step del checkpoint mediante `place_meeting()`. El evento de colisión dedicado es sumamente limpio y eficiente para principiantes. Añade el evento Collision -> Objects -> `obj_player` dentro de `obj_checkpoint` e inserta el siguiente bloque de código:

// Objeto: obj_checkpoint
// Evento: Collision con obj_player

// Solo actuar si este checkpoint aún no ha sido activado
if (!is_active)
{
    // Desactivar visualmente cualquier otro checkpoint de la sala para mantener coherencia
    with (obj_checkpoint)
    {
        is_active = false;
        image_index = 0;
    }
    
    // Activar este checkpoint en particular
    is_active = true;
    image_index = 1;
    
    // Guardar la posición de este checkpoint como la última posición segura global
    // Usamos las coordenadas (x, y) del checkpoint, alineadas con su base
    global.checkpoint_x = x;
    global.checkpoint_y = y;
    
    // Mensaje de comprobación en consola para depuración
    show_debug_message("Punto de control activado en X: " + string(global.checkpoint_x) + ", Y: " + string(global.checkpoint_y));
}

Analicemos la instrucción `with (obj_checkpoint)`. La sentencia `with` en GML itera sobre todas las instancias existentes de ese tipo de objeto en la sala. Al ejecutarla, obligamos a que todas las banderas regresen a su fotograma inactivo (`image_index = 0`), antes de que la instancia con la que el jugador acaba de chocar marque su propia variable `is_active = true` y fije su `image_index = 1`. De esta manera, solo habrá un punto de control encendido a la vez, eliminando ambigüedades en el mundo de juego.

Inicialización global y posición segura por defecto

Un error común al implementar puntos de control es asumir que el jugador siempre alcanzará uno antes de morir. Si el jugador cae en un pozo o choca contra un enemigo en los primeros metros del nivel antes de tocar el primer `obj_checkpoint`, el motor intentará leer `global.checkpoint_x` y `global.checkpoint_y`. Si estas variables no han sido inicializadas previamente, GameMaker detendrá la ejecución del juego con un error fatal de 'variable no definida'.

Para evitar este fallo crítico, debemos inicializar las variables globales con la posición de inicio del nivel. El lugar ideal para hacerlo es en el evento Create del objeto inicializador o controlador del juego (`obj_game_controller`), o de forma transitoria en el evento Create de `obj_player` al cargar la sala:

// Objeto: obj_player
// Evento: Create (añadir al final de tus variables de movimiento existentes)

// Si las variables de checkpoint global no existen aún en la sesión, definirlas
if (!variable_global_exists("checkpoint_x"))
{
    global.checkpoint_x = x;
    global.checkpoint_y = y;
}

La función `variable_global_exists()` evalúa si una variable global con ese nombre ya fue registrada en la memoria. Si es la primera vez que arranca el nivel, GameMaker detectará que no existe y guardará la posición inicial del jugador (`x` e `y` donde colocaste la instancia en la room) como punto de retorno por defecto. Si el jugador muere tras tocar una bandera, las variables globales ya existirán con los datos actualizados y esta condición no sobreescribirá el progreso.