Las pistas se cruzan hasta revelar la imagen
Cómo funciona un Nonogram
Un Nonogram describe una imagen binaria mediante números situados junto a filas y columnas. Cada número indica la longitud de un bloque consecutivo de casillas rellenas; cuando aparecen varios, los bloques mantienen el orden y están separados por al menos una casilla vacía.
Resolverlo consiste en cruzar información. Una fila puede admitir varias configuraciones, pero las columnas eliminan algunas; lo descubierto en una columna vuelve a restringir las filas. El puzzle progresa como una conversación entre ambos ejes.
El origen del puzzle
La historia más citada sitúa el nacimiento moderno del género en Japón a finales de los años ochenta. Non Ishida desarrolló puzzles basados en imágenes de cuadrícula; Tetsuya Nishio llegó de forma independiente a una idea similar. Los puzzles circularon con distintos nombres antes de que «Nonogram» se popularizara internacionalmente.
La familia también es conocida como Picross, Griddlers o Paint by Numbers según país, editor o plataforma. Esa diversidad explica por qué dos jugadores pueden conocer exactamente la misma mecánica con etiquetas distintas.
Qué construimos en Blupoli
El salto de calidad fue construir un motor nativo capaz de generar tableros 5×5, 10×10 y 15×15, derivar automáticamente las pistas de filas y columnas y permitir marcar tanto casillas rellenas como descartadas.
Generar una imagen aleatoria y calcular sus pistas es sencillo. Demostrar que esas pistas identifican exactamente una imagen ya no lo es.
En Nonogram, la imagen es la solución; el puzzle real es la información que queda después de ocultarla.
El solver trabaja línea por línea
Cada fila o columna puede verse como un pequeño problema: dada una longitud, unas pistas y algunas celdas conocidas, ¿qué colocaciones siguen siendo posibles? Si una celda aparece rellena en todas ellas, es segura; si aparece vacía en todas, también.
Propagar estas conclusiones entre líneas resuelve muchos tableros. Cuando no basta, la búsqueda explora alternativas manteniendo las restricciones.
Por qué pusimos un límite de tiempo
Un caso patológico puede obligar al solver a explorar demasiadas combinaciones. En una aplicación web, perseguir la demostración perfecta durante demasiado tiempo empeora directamente la experiencia.
Por eso el motor trabaja con un presupuesto interno: preferimos descartar un candidato costoso de verificar y generar otro antes que congelar la interfaz. Este patrón se está convirtiendo en una regla general de Blupoli.
La densidad de una imagen no equivale a dificultad
Un dibujo con muchas casillas negras puede resultar muy fácil si genera líneas casi completas. Otro más disperso puede requerir muchos cruces. Igual que en Sudoku, una propiedad superficial del tablero no captura por sí sola la dificultad humana.
Podemos observar cuántas rondas de propagación hacen falta, dónde aparece búsqueda, cuánto solapamiento existe y qué líneas desbloquean el resto.
- cuánto progreso aparece por solapamiento inmediato;
- cuántas líneas quedan determinadas pronto;
- cuántas rondas de propagación son necesarias;
- si aparecen decisiones profundas o bifurcaciones;
- cómo cambia el comportamiento entre 5×5, 10×10 y 15×15.
Consejos: empezar por las líneas más informativas
Busca líneas donde la suma de bloques más sus separadores se acerque a la longitud total. Por ejemplo, en diez casillas con pistas 4 y 5, casi toda la estructura queda determinada.
Otro recurso es el solapamiento: si un bloque largo solo puede desplazarse unas pocas posiciones, las celdas presentes en todas las colocaciones son seguras.
Marcar vacíos es resolver
Una cruz no es una ausencia de información; es una restricción. Marcar explícitamente casillas vacías reduce inmediatamente las configuraciones posibles de las líneas que se cruzan y evita volver a considerar opciones ya descartadas.
La interfaz debe dar a rellenos y descartes un peso suficiente sin convertir la cuadrícula en ruido visual.
El tamaño cambia también la UI
Un 5×5 tolera celdas grandes. Un 15×15 necesita administrar mucho mejor espacio, pistas y objetivos táctiles. Esto conecta el motor con el rediseño general de Blupoli: ampliar el área útil de juego era funcional, no únicamente estético.
Juegos parecidos
Si te gusta la deducción visual de Nonogram, prueba Mosaic, donde las pistas describen vecindades; Minesweeper, que usa números locales para deducir celdas; Kurotto o Nurikabe, que convierten el sombreado en una estructura lógica global.
Fuentes
Para el resumen histórico hemos contrastado la cronología de Non Ishida y Tetsuya Nishio y la aparición del nombre Nonogram en referencias públicas.
Nonogram — historia y referencias
Estado actual: engine implementado, juego todavía coming-soon
Nonogram tiene motor nativo, generación procedural y un contador de soluciones, pero el manifiesto actual continúa en coming-soon. Esta entrada describe el estado técnico real sin confundirlo con publicación.
Una pista resume una línea completa
Cada secuencia numérica representa bloques consecutivos de casillas rellenas separados por al menos un vacío. El reto no es interpretar una pista aislada, sino cruzar restricciones de filas y columnas hasta que cada celda quede forzada.
El solver trabaja con patrones compatibles por línea
Para cada fila y columna puede enumerar configuraciones que satisfacen sus pistas. A medida que algunas celdas se fijan como rellenas o vacías, elimina patrones incompatibles. Si todos los patrones restantes coinciden en una posición, esa celda se vuelve una deducción segura.
La propagación alterna filas y columnas
Una deducción en una fila restringe los patrones de su columna; esa columna puede fijar otra celda que vuelve a reducir una fila distinta. El puzzle progresa mediante este intercambio. Es una forma muy directa de constraint propagation.
Contar soluciones requiere detenerse pronto
Para verificar unicidad no necesitamos enumerar todas las respuestas. El contador usa un límite de dos: cero significa imposible, uno única y dos basta para saber que existe ambigüedad. Ese corte reduce trabajo y se alinea exactamente con la decisión de publicación.
La generación normal busca candidatos únicos
generateUnique() crea un patrón visual, descarta densidades extremas, deriva pistas y acepta el candidato cuando countSolutions(..., 2, deadline) devuelve uno. El solver no es un extra posterior; forma parte del filtro de contenido.
Existe un presupuesto de 1,8 segundos
La función establece un deadline de 1.800 ms y como máximo sesenta intentos. Esa decisión reconoce que un generador interactivo necesita una cota. Una propiedad teórica excelente no sirve si la interfaz queda congelada esperando una búsqueda sin límite.
El fallback actual merece una nota de precisión
Si se agotan tiempo o intentos, el engine construye un patrón de borde y deriva sus pistas. En ese camino no vuelve a llamar al contador de soluciones dentro de generateUnique(). Por eso el artículo no debe afirmar que cada salida posible ha pasado el mismo gate de unicidad.
El nombre de una función no es una garantía suficiente
Que la función se llame generateUnique no sustituye leer sus caminos de retorno. Las garantías de producto dependen del comportamiento completo, incluido fallback y manejo de errores. Esta auditoría editorial sirve también como revisión de arquitectura.
El siguiente cierre técnico es verificar el fallback
Una mejora sencilla sería contar soluciones del patrón de borde en tests o sustituirlo por un fixture cuya unicidad esté demostrada. Así la propiedad “toda partida publicada es única” podría expresarse sin excepciones ni matices.
Los tres tamaños actuales son 5×5, 10×10 y 15×15
El selector de dificultad vincula Fácil con 5×5, Medio con 10×10 y Difícil con 15×15. A diferencia de Colors, aquí tamaño y dificultad todavía están acoplados en la implementación actual.
Acoplar tamaño y dificultad simplifica, pero limita
Un tablero 15×15 suele ser más largo, pero no todo 15×15 es necesariamente más difícil que un 10×10. En el futuro podríamos separar escala de complejidad si contamos mejores señales del solver.
La densidad también cambia por nivel
Los perfiles usan densidades aproximadamente 0,42, 0,46 y 0,50. Esa cifra influye en la forma visual y en las pistas, pero no define por sí sola dificultad. Distribución de bloques y solapamiento entre patrones importan tanto como el porcentaje de relleno.
Los patrones visuales necesitan filtros
El generador suaviza ruido y descarta resultados demasiado vacíos o demasiado llenos. Un Nonogram técnicamente válido puede ser un dibujo pobre o una experiencia trivial. La calidad de contenido tiene una dimensión visual además de lógica.
La unicidad no garantiza una buena ruta humana
Un tablero puede tener una única solución y aun requerir búsqueda que el producto no desea. Si queremos clasificar dificultad por lógica humana, necesitamos instrumentar qué deducciones de línea resuelven el puzzle y dónde aparecen bloqueos.
El solver actual ofrece señales útiles
Podemos registrar cuántos patrones sobreviven por línea, cuántas celdas se fuerzan en cada pasada y cuántas iteraciones necesita la propagación antes de recurrir a búsqueda. Esas métricas describen estructura mejor que tamaño solo.
Una línea tiene una combinatoria concreta
Una pista 3,1 en longitud 10 no puede colocarse arbitrariamente: los bloques necesitan separación y espacio. Generar todos los patrones legales convierte la pista en un dominio explícito. Después, cada celda conocida filtra ese dominio.
La intersección es el motor de la deducción
Una fila puede conservar varios patrones y aun así compartir una casilla rellena en todos ellos. Esa celda forzada cambia una columna. El valor del solver está en encontrar consensos parciales, no en esperar a conocer una línea completa.
Las cruces del jugador también son información
La UI actual permite tres estados: desconocida, rellena y cruzada. Marcar vacío explícitamente ayuda a representar deducciones negativas y reduce errores de memoria. El engine debe distinguir una cruz deliberada de una celda todavía no resuelta.
Click y botón derecho tienen semánticas distintas
El click cicla estados y el menú contextual puede alternar cruz. En móvil no existe clic derecho, así que la experiencia publicada necesita una alternativa táctil clara que no dependa de un gesto propio de escritorio.
El teclado también puede acelerar tableros grandes
Con 15×15, recorrer cientos de celdas únicamente con pointer puede resultar lento. Foco visible, navegación con flechas y teclas para rellenar o cruzar serían una extensión natural del contrato de accesibilidad.
El botón Comprobar usa la solución materializada
La implementación compara marcas del jugador con la solución generada. Es un chequeo fiable para esa instancia, pero la UI debería decidir cuánto revelar cuando hay error. “Todavía no coincide” mantiene la deducción; señalar todas las celdas incorrectas cambia radicalmente la experiencia.
Los hints pueden apoyarse en consenso de patrones
Una pista pedagógica puede seleccionar una fila donde todos los patrones coinciden en cierta celda y explicar por qué. Eso usa la misma evidencia que el solver sin entregar una respuesta arbitraria.
Un hint debería enseñar una técnica de línea
Solapamiento, bloques completos, espacios imposibles y separaciones son conceptos comprensibles. Traducir el dominio de patrones a esos términos puede convertir un solver interno en ayuda útil.
El onboarding debería empezar con una línea corta
Una escena 5×5 puede mostrar una pista 3 y varias celdas ya vacías para que el jugador vea dónde el bloque debe solaparse. Después puede enseñar que esa nueva marca afecta a una columna.
Responsive afecta a pistas y tablero a la vez
En Nonogram no basta con escalar celdas; las pistas externas también ocupan espacio. En móvil, una columna con varios números puede empujar la cuadrícula o reducir demasiado los targets. La composición debe reservar sitio para ambos ejes.
Las pistas largas necesitan jerarquía legible
Separación, alineación y contraste ayudan a distinguir 1 1 3 de 11 3. La tipografía no puede convertir números consecutivos en una cadena ambigua. La claridad visual forma parte de la regla.
Persistencia necesita conservar marcas y puzzle
Un save debe incluir tamaño, dificultad, pistas o solución materializada, marcas del jugador y suficiente provenance para reconstruir la instancia. Confiar solo en regenerar por azar sería frágil.
La seed por sí sola puede no ser suficiente a largo plazo
Si cambia el generador, una seed histórica puede producir otra imagen. Para saves duraderos conviene versionar generación o guardar la solución/pistas materializadas. La reproducibilidad necesita contexto.
Los resultados deberían incluir tamaño y ayudas
Tiempo, errores, hints y finalización tienen significado distinto entre 5×5 y 15×15. El sistema común debe conservar contexto y evitar rankings que mezclen dificultades incomparables sin explicarlo.
La generación debería exponer métricas internas
Intentos utilizados, milisegundos consumidos y si se activó fallback son señales importantes. Si un cambio incrementa fallbacks, podemos detectarlo antes de que el usuario note repetición o degradación de calidad.
El fallback no debería ser invisible para QA
Aunque el jugador no necesite saberlo, las herramientas internas sí. Un contador de cuántas partidas vienen del camino de reserva permite comprobar si el generador normal está perdiendo eficacia.
Las pruebas deberían cubrir el deadline
No basta con tests que siempre terminan rápido. Conviene simular o forzar el camino de timeout para verificar que el fallback carga correctamente, que la UI no queda inconsistente y que la propiedad de solución prometida sigue siendo cierta.
La historia de Nonogram merece formulación prudente
La familia se popularizó internacionalmente bajo nombres como Nonogram y Picross. Para este artículo, la historia sirve de contexto; el valor principal está en explicar la mecánica y nuestro engine, evitando atribuciones demasiado específicas si no son necesarias para jugar.
La taxonomía puede hablar de sombreado y deducción por líneas
El juego exige combinar pistas numéricas, patrones y cruces. Podemos describir esas acciones sin prometer entrenamiento cognitivo, siguiendo la taxonomía responsable del catálogo.
Los visuales deben enseñar cruce de restricciones
La nueva infografía representa dominios de fila y columna que convergen en una celda. Es una imagen del algoritmo y de la estrategia, no una captura decorativa de una imagen terminada.
Qué significa terminar Nonogram
Antes de publication necesitamos cerrar la garantía del fallback, revisar mobile input, teclado, onboarding, accesibilidad, persistencia y resultados. El engine ya ofrece una base fuerte, pero coming-soon sigue describiendo una experiencia que aún tiene capas por cerrar.
La lección principal es hacer visible la evidencia
Un candidato procedural no se convierte en buen puzzle porque produzca una imagen bonita. Necesitamos saber cuántas soluciones tiene, cuánto cuesta verificarlo, qué camino de generación siguió y cómo se comporta la experiencia completa alrededor de esas pistas.
El timeout debe ser un estado de primera clase
Si el contador alcanza el deadline, eso no significa “múltiples soluciones” ni “puzzle inválido”. Significa que no tenemos evidencia suficiente dentro del presupuesto. Diferenciar timeout, ambigüedad y contradicción permite ajustar generación con datos en lugar de mezclar causas distintas bajo un mismo rechazo.
Las métricas del solver pueden guiar dificultad sin adivinar
Podemos registrar dominios medios por línea, deducciones forzadas por pasada, profundidad de búsqueda y momento del primer branching. Ninguna métrica modela por sí sola el esfuerzo humano, pero juntas ofrecen una base mejor que ligar dificultad únicamente a 5×5, 10×10 o 15×15.
Un Nonogram grande también exige decisiones de viewport
En móvil, 15×15 más pistas exteriores puede superar el espacio disponible. El producto puede escalar, permitir pan controlado o adaptar targets, pero debe conservar legibilidad de números y precisión táctil. “Cabe técnicamente” no equivale a “se puede jugar cómodamente”.
Las líneas guía pueden mejorar orientación
En tableros grandes es habitual agrupar visualmente cada cinco celdas. Ese recurso no cambia las reglas, pero reduce errores de posición al comparar pistas y columnas. Cualquier énfasis visual debe funcionar en tema claro, oscuro y estados de foco.
El botón Reiniciar debe preservar la misma instancia
Reiniciar significa borrar marcas del jugador y conservar pistas. Nueva partida significa crear otro puzzle. Separar ambas acciones es esencial para que la persona pueda volver a intentar el mismo caso y para que las estadísticas sepan si una sesión continuó o empezó de cero.
Undo puede ser más natural que ciclar estados
Cuando un click pasa por desconocida, rellena y cruzada, un toque accidental puede alejarse dos pasos del estado deseado. Un historial semántico de cambios permite deshacer exactamente la última decisión sin reconstruir toda la partida.
Las pistas deberían tener etiquetas accesibles completas
Una fila puede anunciar “fila 4, pistas 3 y 1” y una celda “fila 4, columna 7, cruzada”. Esa información traduce la estructura visual a una forma navegable sin alterar el motor. Accesibilidad no es solo poder enfocar botones, sino comprender el problema.
Compartir un puzzle requiere compartir pistas, no solución
Un código o enlace puede representar seed, versión y configuración para que otra persona reciba las mismas pistas. La imagen resuelta puede permanecer oculta. La reproducibilidad abre una vía social sin convertir el share en spoiler.
Los enlaces compartidos necesitan versionado
Si la generación cambia, un enlace antiguo debe seguir reconstruyendo la instancia que se compartió. Podemos incluir versión o materializar las pistas en el payload. Los artefactos duraderos necesitan más provenance que una partida efímera.
El historial de generación puede revelar degradación
Si una release aumenta el porcentaje de fallback o el tiempo de contador, comparar series de métricas por versión ayuda a detectar el problema. No necesitamos telemetría individual del jugador para observar salud del algoritmo; bastan benchmarks y señales agregadas del sistema.
Los fixtures deberían incluir puzzles ambiguos a propósito
Para probar el contador necesitamos casos con cero, una y al menos dos soluciones, además de timeouts simulados. Una suite formada solo por puzzles buenos no demuestra que el gate sepa rechazar los malos.
La refactorización del solver debe preservar equivalencia
Si optimizamos patrones de línea, caché o representación de celdas, los fixtures conocidos deben devolver el mismo conteo. Las optimizaciones son más seguras cuando la semántica está defendida por casos pequeños y comprensibles.
La caché de patrones puede ahorrar mucho trabajo
Longitud de línea y secuencia de pistas definen un conjunto reutilizable de patrones. Cachearlo puede reducir asignaciones durante generación masiva. La clave debe incluir todos los datos relevantes; una caché incorrecta sería peor que ninguna.
El fallback debería ser explícito en diagnostics
Una partida de reserva puede ser perfectamente válida, pero QA necesita saber que apareció. Si la tasa sube después de un cambio, es señal de que generación normal está encontrando menos candidatos dentro del presupuesto.
La publicación puede exigir “fallback verificado” como gate
Una prueba sencilla que cuente soluciones del patrón canónico cerraría la principal reserva detectada en esta auditoría. Es un buen ejemplo de cómo reescribir documentación puede descubrir una mejora concreta del código.
Nonogram resume la diferencia entre producir y demostrar
Crear una imagen binaria y derivar pistas es fácil comparado con demostrar que esas pistas describen exactamente el tipo de puzzle que queremos publicar. Conteo, deadline, fallback y UX forman parte de la misma cadena de confianza.