Cómo verificamos 2000 tableros deslizantes antes de publicar

Un solucionador solo es fiable si su idea de movimiento coincide con la del juego. En un puzle deslizante, una pieza puede avanzar hasta una pared, otra pieza o una puerta que no admita su color. OutBrick añade detalles con estado: las llaves pueden cambiar puertas, el hielo puede necesitar varios deslizamientos y los generadores pueden introducir piezas en cola. Reimplementar una versión simplificada para el verificador dejaría un hueco justo donde puede ocultarse un error.

Por ello, la búsqueda pregunta al propio motor del juego por los movimientos legales y los aplica mediante el mismo código de transición de estado que se utiliza al jugar. La clave del estado también incluye el estado de las puertas y un contador de movimientos reducido cuando las puertas cíclicas o temporizadas hacen relevante ese recuento. Dos tableros que parezcan iguales pero tengan distintos estados activos de puertas deben seguir siendo estados de búsqueda diferentes.

El solucionador usa A* ponderado. Su heurística ExitTable pregunta cuántos deslizamientos necesitaría cada pieza para alcanzar una salida adecuada si se retiraran los demás ladrillos. Ese tablero simplificado cuesta menos de analizar que el real y da una estimación útil de lo que queda. Dar más peso a la heurística favorece encontrar rápidamente una solución.

La elección tiene un límite: la ruta es útil, pero no se garantiza que sea la más corta. Una búsqueda también puede detenerse al agotar su presupuesto de nodos. En ese caso la respuesta es desconocida; no etiqueta el tablero como imposible. Solo agotar por completo el espacio de estados alcanzables puede respaldar un veredicto de ausencia de solución. Distinguir los resultados evita convertir un límite de tiempo o una cancelación en una afirmación falsa sobre el puzle.

Encontrar una ruta no es la comprobación final. Para cada tablero diseñado guardamos un testigo: la secuencia de movimientos desde su estado inicial hasta despejarlo. La reproducción empieza en un estado de juego nuevo, verifica que sea válido y aplica el testigo movimiento a movimiento mediante las reglas reales. Un movimiento ilegal hace fallar la reproducción inmediatamente.

El comprobador también repite cada movimiento desde el mismo estado previo y compara el estado resultante, los eventos y el desenlace. Detecta transiciones que se comportarían de otra forma al repetirse. Después de cada movimiento comprueba que todas las piezas permanezcan en casillas válidas y que no ocupen la misma casilla. Al final, el tablero debe estar realmente despejado. No cuenta una ruta que solo parezca plausible o termine con un ladrillo dentro.

Un testigo legal demuestra que existe una ruta. No demuestra que una persona la encuentre, que se sienta justa ni que el tablero sea difícil de la manera adecuada. La ruta del solucionador tampoco establece un número óptimo de movimientos. Son preguntas de diseño separadas, por lo que tratamos la reproducción del paquete completo como requisito de corrección y evaluamos aparte ritmo y dificultad.

El límite de movimientos también debe dejar espacio para la ruta verificada. Puedes pensar tanto como necesites: el límite cuenta movimientos y OutBrick no tiene reloj. Así el puzle ejerce presión sin convertir la validación en un temporizador.

El resultado útil de publicación no es «el solucionador se ejecutó una vez». Es que cada tablero del paquete tuvo un testigo reproducido correctamente con las reglas que se publican. Al cambiar una regla o un tablero, el paquete puede comprobarse otra vez y el primer movimiento fallido apunta a la parte del contrato rota: legalidad, determinismo, geometría del tablero o resultado final despejado.

Así comprobamos los 2000 tableros de OutBrick antes de publicar. Puedes probar el mismo tipo de puzle en el tablero gratuito del navegador o descargar OutBrick para iPhone y iPad.