Las reglas de Norinori
El tablero está dividido en regiones. Cada región debe contener exactamente dos casillas negras. Además, las negras aparecen formando parejas ortogonales: cada casilla negra debe tocar por un lado a exactamente otra negra. La pareja puede atravesar la frontera entre regiones.
La combinación es engañosa. Las restricciones locales parecen sencillas, pero la regla de emparejamiento conecta decisiones que pueden estar a varios pasos de distancia.
Un puzzle original de Nikoli
Nikoli incluye Norinori entre sus puzzles de sombreado y resume sus dos reglas esenciales: colocar bloques negros de dos en dos y conseguir que cada área delimitada contenga dos casillas negras. Es un ejemplo de cómo pocas reglas pueden producir profundidad cuando interactúan entre fronteras distintas.
El primer generador parecía correcto
Nuestra primera aproximación partía de una disposición válida de casillas negras y generaba regiones alrededor. A simple vista, los tableros cumplían las reglas y se podían resolver.
Después añadimos un selfTest() que pedía al solver contar soluciones. Aparecieron alternativas. El tablero tenía una solución conocida, pero no una solución única.
Conocer una respuesta no demuestra que hayas construido una pregunta bien definida.
Bloquear la PR era la decisión de producto
Podíamos haber relajado la prueba, aceptar la implementación y declarar el generador terminado. Habríamos conseguido más variedad a costa de algo que el jugador no puede verificar hasta muy tarde: la confianza de que existe una deducción única.
Preferimos bloquearla. CI no estaba frenando el desarrollo; estaba defendiendo una propiedad del producto.
El segundo intento también falló
Cambiamos la estrategia: primero crear regiones y después buscar una solución. Seguía pareciendo razonable, pero las particiones aleatorias producían demasiadas configuraciones equivalentes. De nuevo no podíamos demostrar unicidad de forma consistente.
Una retirada deliberada
En lugar de rebajar el estándar, cambiamos el alcance. Localizamos una instancia abierta y conocida del ecosistema pzprjs, reconstruimos nuestra representación nativa y usamos el solver para verificar variantes por rotación y reflexión.
El resultado tiene menos variedad que el generador que queríamos, pero es correcto y reproducible. Eso nos parece un estado intermedio mucho más honesto.
Por qué la unicidad es difícil aquí
Las regiones imponen conteos, pero una pareja puede cruzar sus fronteras. Eso crea simetrías y alternativas que no son evidentes mirando cada zona de forma aislada. Un cambio local puede conservar todos los conteos y reorganizar parejas en otra parte.
Un futuro generador necesita diseñar las regiones precisamente para romper esas simetrías, no esperar que desaparezcan por azar.
- partir de estructuras de parejas controladas;
- crear regiones que añadan información útil;
- contar soluciones después de cada transformación;
- rechazar candidatos ambiguos pronto;
- medir dificultad además de corrección.
Cómo empezar a resolver
Busca regiones pequeñas o estrechas: al tener que contener exactamente dos negras, suelen limitar rápido las posibilidades. Después vigila la regla de pareja. Una negra no puede terminar conectada con tres negras ni quedarse aislada.
Es útil pensar en dominós. No colocas «negras sueltas»: intentas decidir qué parejas pueden existir y cómo cada una consume casillas de las regiones que toca.
La lección se ha extendido a otros motores
Norinori reforzó una práctica que ahora aplicamos de forma más general: el generador propone y un solver independiente verifica. También nos enseñó que un fallo de self-test puede revelar un defecto conceptual, no solo una implementación rota.
Eso ha influido en cómo pensamos Nonogram, LITS, Logic Grid y otros juegos procedurales.
Juegos relacionados
Si te gusta Norinori, prueba LITS, donde cada región aloja un tetrominó; Heyawake, que combina regiones y sombreado; Nurikabe, con componentes blancos y una pared negra conectada; o Star Battle, donde las regiones se cruzan con restricciones de filas y columnas.