Un botón de «Nueva partida» parece una función sencilla. El usuario pulsa y aparece un tablero. Sin embargo, detrás de ese segundo hay una pequeña cadena de decisiones algorítmicas: crear una estructura candidata, comprobar sus reglas, demostrar que se puede resolver, estimar cuánto razonamiento exige y decidir si merece llegar a pantalla.
Esta parte del proyecto nos ha obligado a cambiar una idea inicial: el generador no es una fábrica que entrega cualquier instancia válida. Es un editor que debe saber rechazar.
De cientos de candidatos a una partida que merece ser jugada.
La trampa del tablero válido
Un generador puede cumplir todas las reglas y aun así producir partidas aburridas. Si la solución es obvia, si la dificultad solo cambia el tamaño, si los patrones se repiten o si existen varias soluciones, el motor funciona técnicamente pero falla como producto.
El problema adopta formas diferentes. En Nonogram importa demostrar que las pistas conducen a una solución determinada. En LITS intervienen regiones, tetrominós y conectividad. En Kakuro las combinaciones posibles de cada suma afectan al razonamiento. En juegos de caminos hay que evitar que el trazado quede prácticamente decidido desde el inicio.
La validez es el suelo de calidad de un puzzle, no el techo.
Solver y generador forman una pareja
Estamos usando solvers no solo como ayuda potencial para el jugador, sino como herramienta de fabricación. El generador propone y el solver intenta demostrar propiedades sobre la propuesta. Si el tablero no supera los criterios, se descarta y se prueba otro.
Esto tiene una consecuencia útil: el mismo conocimiento que permite resolver sirve para medir. Podemos observar cuántas decisiones aparecen, qué técnicas son necesarias, cuántas alternativas se abren o dónde se concentra la complejidad.
Solución única no siempre es trivial de demostrar
Encontrar una solución demuestra que el tablero es resoluble; no demuestra que esa solución sea la única. Para muchos puzzles necesitamos seguir buscando después del primer éxito o usar restricciones capaces de descartar alternativas.
Esa diferencia es crítica. Si un jugador llega a una respuesta distinta pero igualmente válida y la aplicación la rechaza porque esperaba otra, el fallo no es del jugador: el generador publicó una pregunta ambigua.
Norinori y el valor de rechazar
Norinori dejó una lección especialmente útil: preferimos descartar estrategias que producen puzzles ambiguos antes que llenar el juego de variedad falsa. Un sistema automático que bloquea una implementación incorrecta está haciendo producto, no burocracia.
Rechazar también forma parte del algoritmo en tiempo de ejecución. Un candidato puede ser correcto pero demasiado fácil para la dificultad pedida, demasiado parecido a los anteriores o excesivamente caro de validar. Ninguno debería ganar solo porque fue el primero que apareció.
Dificultad que signifique algo
Fácil, Normal, Difícil y Experto deben representar cambios reales en el razonamiento necesario. El tamaño puede influir, pero no basta. Un tablero grande con decisiones obvias sigue siendo fácil; uno pequeño con una deducción profunda puede ser difícil.
Según la familia podemos observar branching, pistas disponibles, técnicas lógicas, longitud de la solución, combinaciones candidatas, restricciones activas o estructura espacial. La métrica ideal no es necesariamente la más sofisticada, sino la que mejor correlaciona con la experiencia de una persona.
- si exige más pasos o técnicas que uno fácil;
- si la complejidad aparece durante la partida y no solo al inicio;
- si el aumento se mantiene entre tamaños diferentes;
- si el solver puede aportar señales reproducibles;
- si las partidas de la misma banda siguen teniendo variedad.
Numberlink: cuando el algoritmo delata la dificultad falsa
En Numberlink vimos un síntoma muy claro: incluso los niveles altos podían generar caminos demasiado evidentes. El tablero era jugable, pero el jugador apenas tenía que decidir. Eso nos llevó a revisar el algoritmo con otra pregunta: no «¿puede crear un Numberlink?», sino «¿qué propiedades hacen interesante un Numberlink?».
Ese cambio de pregunta es aplicable a todo el catálogo. La generación procedimental necesita una teoría mínima de la diversión específica de cada puzzle.
Tiempo también es una restricción de producto
La generación ocurre delante de una persona que quiere jugar. No podemos buscar indefinidamente la instancia perfecta. Los algoritmos necesitan un presupuesto, intentos acotados y una estrategia de fallback.
Esto crea una tensión interesante: cuanto más estrictos son los filtros de calidad, más candidatos podemos tener que rechazar. Mejorar el generador significa aumentar la probabilidad de producir buenos candidatos, no simplemente darle más segundos.
Semillas, reproducción y depuración
Cuando una partida problemática puede reproducirse con una semilla, depurar deja de ser perseguir un fallo aleatorio. Podemos guardar el caso, convertirlo en regresión y comparar cambios del algoritmo sobre la misma entrada.
Las semillas también ayudan a separar dos objetivos: variedad para el usuario y determinismo para ingeniería. Podemos tener ambos si la aleatoriedad está controlada.
El generador es parte del diseño del juego
Durante mucho tiempo es fácil pensar que las reglas son «el juego» y el generador una utilidad técnica. En un producto con partidas procedurales ocurre lo contrario: las reglas definen el espacio posible, pero el generador decide qué parte de ese espacio verá realmente el jugador.
Por eso estamos tratando solvers, validadores y métricas como infraestructura compartida, mientras dejamos que cada familia defina qué significa una buena partida. El objetivo no es fabricar tableros sin fin. Es conseguir que pulsar «Nueva partida» siga teniendo sentido después de la número cien.