La idea que sostiene todo el puzzle
Un bucle cerrado tiene una propiedad poderosa: divide el tablero en dos lados. Castle Wall explota esa propiedad sin convertirla en una clase de topología. El jugador dibuja un único recorrido ortogonal que pasa por los centros de algunas casillas vacías. El recorrido no puede cruzarse, ramificarse ni dividirse en varios bucles. Las casillas con pista son obstáculos: el muro debe rodearlas, nunca atravesarlas.
El color de una pista aporta la primera mitad de la información. Una pista blanca tiene que quedar en el interior del bucle. Una pista negra tiene que quedar en el exterior. Puede parecer una condición global difícil de usar, pero enseguida produce deducciones locales. Si una pista blanca y una negra están próximas, cualquier frontera válida tiene que separarlas de algún modo. Si varias pistas del mismo color forman un bloque, el muro suele verse empujado hacia el perímetro de ese bloque.
La segunda mitad son las flechas numéricas. Una flecha mira en una de las cuatro direcciones ortogonales y el número indica cuántas veces el rayo que parte de esa casilla cruza segmentos del muro. Otra forma de imaginarlo es contar fronteras del tablero atravesadas por el recorrido en esa dirección. Un cero es especialmente fuerte: descarta todos los cruces a lo largo del rayo. Un número mayor no dice dónde están esos cruces, pero obliga a repartirlos de forma compatible con un único bucle.
De dónde viene Castle Wall
La historia de Castle Wall está mejor documentada que la de muchos géneros de lápiz y papel. Palmer Mebane publicó una descripción del puzzle en su archivo Melon's Puzzles y lo presenta como una creación propia, «hasta donde sabe». Esa formulación prudente es importante: no necesitamos convertir una afirmación del autor en una historia más grandiosa de lo que las fuentes permiten. Su página explica las mismas ideas esenciales que usamos como referencia: un bucle cerrado, casillas de pista que no pueden ser visitadas, pistas blancas dentro, negras fuera y números con flecha que cuentan cruces en una dirección.
El género se extendió después por la comunidad internacional de puzzles. Grandmaster Puzzles ha publicado Castle Wall clásico y variantes, y pzprjs incorporó el tipo castle en su versión 0.12.0, acreditando la incorporación a Lennard Sprong. Esa implementación abierta es útil como referencia de reglas y comprobaciones, no como fuente para copiar tableros ni código. Blupoli genera sus propias instancias y utiliza su propio motor.
Esta distinción importa. Un puzzle puede tener reglas compartidas y, al mismo tiempo, cada implementación puede aportar una experiencia diferente: controles, accesibilidad, persistencia, generación, selección de dificultad y presentación visual. Nuestro objetivo no es reproducir una colección ajena. Es hacer que Castle Wall se sienta como un juego nativo de Blupoli Puzzles y que cada partida nueva pueda justificarse técnicamente.
Cómo leer una pista sin perderse
Conviene separar mentalmente color y número. El color habla del resultado global: dentro o fuera. La flecha habla de una línea de visión concreta. Cuando una pista combina ambas cosas, no son dos versiones de la misma información, sino dos restricciones que se cruzan. Una pista blanca con «0→» exige estar dentro del bucle y, además, no tener ningún cruce del muro hacia su derecha. Eso puede forzar al muro a rodearla por arriba, abajo o izquierda.
Las pistas sin número siguen siendo útiles. Una casilla blanca sin flecha continúa prohibiendo el paso y continúa exigiendo interior. Lo mismo ocurre con una negra. El generador de Blupoli aprovecha esta separación para graduar dificultad: los niveles sencillos conservan una proporción alta de pistas numéricas; los niveles avanzados dejan más trabajo a la relación entre color, geometría y continuidad del bucle.
También ayuda pensar en paridad. Si trazamos mentalmente un rayo desde una casilla hasta el borde del tablero, cada cruce del muro cambia de lado. Tras un número impar de cruces estamos en el lado opuesto; tras un número par, en el mismo. El jugador no necesita calcular una fórmula, pero esta intuición explica por qué una frontera cerrada puede determinar de forma consistente qué está dentro y qué está fuera.
El muro no recorre todas las casillas
Castle Wall no es un puzzle hamiltoniano. El bucle visita algunas casillas vacías y deja otras sin usar. Esta libertad es una fuente importante de dificultad. En un corredor estrecho entre pistas puede parecer evidente por dónde debe continuar el muro, pero en una zona abierta aparecen desvíos posibles, y sólo la combinación de flechas, colores y la regla de un único bucle permite decidir.
Hay dos errores típicos. El primero es cerrar un bucle pequeño demasiado pronto. Puede satisfacer varias pistas cercanas y aun así dejar obligaciones imposibles en otra zona. El segundo es crear una rama temporal pensando que luego se arreglará. No existe esa opción: cada casilla utilizada por el muro tiene exactamente dos conexiones en la solución final. Una tercera conexión ya contradice la estructura del género.
Por eso la interfaz de Blupoli permite marcar también un segmento como descartado. No es obligatorio llenar el tablero de cruces, pero registrar una imposibilidad evita volver a considerar el mismo camino. Deshacer y Rehacer trabajan como red de seguridad; Reiniciar conserva la base de la partida y Nueva partida cambia la semilla.
Generar primero una solución válida
El generador de Blupoli empieza por el final: construye un ciclo simple sobre la cuadrícula. Partimos de un anillo ortogonal y aplicamos desvíos controlados que añaden giros sin permitir que el recorrido se cruce ni repita una casilla. El número de desvíos crece con la dificultad y con el tamaño, de modo que la solución no se reduzca a un rectángulo obvio.
Con el ciclo conocido podemos clasificar cualquier casilla que no pertenece al recorrido como interior o exterior mediante un test de punto en polígono. Esa clasificación determina si una pista potencial será blanca o negra. Para cada pista numérica elegimos una dirección y contamos exactamente los segmentos de la solución que cruza el rayo correspondiente. Las pistas no se inventan y después se intenta resolver el tablero: se derivan de una solución geométricamente válida.
Este enfoque garantiza resolubilidad inicial, pero no unicidad. Ésa es una diferencia fundamental. Saber que existe una solución sólo demuestra que el puzzle no está roto. Para publicarlo necesitamos saber que no existe una segunda pared distinta que satisfaga las mismas pistas. Esa prueba la hace otro componente.
Un solver separado del generador
El solver trabaja sobre el grafo de casillas que el muro puede visitar. Las casillas de pista se eliminan del grafo porque el recorrido no puede entrar en ellas. Cada conexión ortogonal restante es una decisión binaria: forma parte del muro o no. Durante la búsqueda se mantienen grados por casilla y se descartan inmediatamente ramas que producirían más de dos conexiones o un extremo muerto imposible de completar.
Las flechas ofrecen otra poda barata. Para cada pista numérica conocemos qué conexiones podrían cruzar su rayo. Si ya hemos seleccionado más segmentos de los permitidos, la rama muere. Si incluso seleccionando todos los segmentos todavía indecisos no podemos alcanzar el número exigido, también muere. Estas dos comprobaciones reducen mucho el espacio antes de necesitar una validación global.
Cuando todas las decisiones están asignadas, el solver exige grados cero o dos, comprueba que todos los segmentos seleccionados pertenecen a una única componente y reconstruye el ciclo. Después verifica el color de cada pista con la geometría real del ciclo y comprueba de nuevo todos los números. Para generación contamos soluciones sólo hasta dos: una es aceptable; dos bastan para descartar el candidato.
La unicidad es un gate, no una esperanza
La frase «parece tener una sola solución» no sirve como criterio de publicación. Un generador puede producir cientos de ejemplos que a simple vista funcionan y aun así esconder una segunda ruta en una esquina poco obvia. Por eso el banco de regresión no compara sólo la solución prevista con las reglas. Ejecuta el solver y exige exactamente una solución.
También hay un presupuesto de búsqueda. Si un candidato es tan complejo que el solver no puede terminar dentro del límite, no interpretamos el agotamiento como unicidad. El resultado es inconcluso y el candidato se rechaza. Esta regla evita una trampa común: confundir «no encontré una segunda solución» con «he demostrado que no existe».
Las semillas hacen que cualquier fallo sea reproducible. Tamaño, dificultad y semilla identifican una base concreta. Si una combinación revela una ambigüedad, una generación demasiado lenta o una separación de dificultad pobre, puede convertirse en una regresión permanente en lugar de desaparecer al pulsar Nueva partida.
Cuatro tamaños que cambian el espacio, no las reglas
Castle Wall ofrece 6×6, 8×8, 10×10 y 12×12. El tamaño pequeño sirve para aprender a leer colores y flechas sin que la continuidad del bucle se vuelva abrumadora. 8×8 abre espacio para desvíos y corredores alternativos. 10×10 y 12×12 permiten que varias zonas del tablero interactúen sin que una deducción local resuelva inmediatamente el resto.
El tamaño no sustituye a la dificultad. Un 12×12 Fácil puede tener más casillas que un 6×6 Experto, pero conserva más información explícita y menos casillas libres ajenas al recorrido solución. El 6×6 Experto, en cambio, puede ofrecer un espacio pequeño con varias alternativas plausibles y menos flechas numéricas. Son experiencias distintas y ambas tienen sentido.
Separar ambos controles también mejora las pruebas. Podemos comparar Fácil, Normal, Difícil y Experto manteniendo fijo el tamaño. Si la dificultad fuese sólo otro nombre para 6×6, 8×8, 10×10 y 12×12, no podríamos saber si el algoritmo realmente calibra nada.
Qué significa dificultad en esta implementación
El generador utiliza dos palancas visibles y una métrica independiente. La primera palanca es el número de casillas libres adicionales que no forman parte del ciclo solución. Esas casillas crean rutas alternativas que el solver debe considerar. La segunda es la proporción de pistas que conservan número y flecha. Al reducirla, aumenta el peso de la lógica interior/exterior y de la continuidad.
La métrica independiente son los nodos explorados por el solver. No pretendemos que ese número sea una medida psicológica perfecta del esfuerzo humano. Un solver y una persona no razonan igual. Sí es una señal reproducible de que, bajo el mismo algoritmo de búsqueda, el espacio que debe descartarse aumenta. La validación masiva exige que la media de nodos suba de Fácil a Normal, de Normal a Difícil y de Difícil a Experto para cada tamaño.
Esto es mejor que una etiqueta cosmética, pero tampoco lo consideramos una verdad definitiva. Si observaciones de juego muestran que dos bandas se sienten demasiado parecidas, la calibración puede evolucionar. Lo importante es conservar métricas, semillas y tests para que un ajuste no vuelva a convertir Experto en Fácil por accidente.
Ocho mil puzzles antes de publicar
La validación dedicada del generador ejecuta 500 semillas para cada combinación de cuatro tamaños y cuatro dificultades: 8.000 puzzles. Cada instancia debe generarse dentro del presupuesto, la solución conocida debe satisfacer todas las reglas y el solver debe encontrar exactamente una solución. Además se agregan los nodos de búsqueda para comprobar la separación de dificultad.
El test permanente que forma parte de la suite normal usa 100 semillas por combinación, 1.600 puzzles. Es deliberadamente más pequeño para que la comprobación cotidiana no convierta cada cambio menor en una espera excesiva. El workflow específico del juego hace la pasada grande en el runner self-hosted cuando Castle Wall cambia.
La combinación de ambos niveles importa. Un test diminuto es rápido pero puede no encontrar casos raros. Una campaña enorme en cada commit puede volver el desarrollo innecesariamente lento. El banco permanente detecta regresiones conocidas y una muestra amplia; el gate masivo aumenta la confianza antes de integrar el juego.
Controles pensados para explorar
En el tablero, cada conexión posible entre dos casillas libres tiene tres estados: sin decidir, segmento del muro y descarte. Ratón, toque y teclado comparten el mismo modelo. Con Tab se puede alcanzar una conexión y con Enter o Espacio cambiar su estado. El área interactiva es más gruesa que la línea visible para que acertar con un dedo no requiera precisión de píxel.
La pista no resuelve una región completa. Primero corrige un segmento seleccionado que contradice la solución; si no hay uno, revela una conexión correcta todavía pendiente. Así sigue siendo una ayuda concreta y registrable, no un botón que sustituye el razonamiento. Limpiar borra las decisiones, Reiniciar vuelve al comienzo de la misma base y Nueva partida crea otra semilla.
La finalización no depende de que el dibujo «se parezca» a la solución interna. El motor valida el estado como un Castle Wall completo: un único ciclo, colores correctos y números correctos. Eso permite que la comprobación responda a las reglas y no a una comparación visual frágil.
Responsive: el tablero vive dentro de la aplicación
Blupoli Puzzles usa un shell de aplicación de altura completa. Castle Wall no crea su propio encabezado, pie ni marco de página; recibe el rectángulo de #game-root.game-stage y encaja dentro. En escritorio el SVG conserva relación cuadrada y utiliza la altura disponible sin empujar el dock de acciones. En móvil y portrait puede crecer según el ancho dentro del área scrollable interna del juego.
El SVG ayuda a mantener nítidas las líneas en distintos tamaños. Las pistas negras y blancas conservan contraste, los números se centran y los puntos de paso siguen visibles sin competir con el muro. Los targets interactivos son transparentes y más anchos que el trazo, de modo que accesibilidad táctil y limpieza visual no se excluyen.
Playwright comprueba 360×640, tablet portrait y escritorio. No basta con que la página cargue: el tablero debe permanecer dentro del viewport útil, los controles de tamaño y dificultad deben existir como ejes separados, una conexión debe poder activarse por teclado y no deben aparecer errores de JavaScript.
Cómo empezar a resolver
Busca primero los ceros. Una flecha 0 elimina de golpe todos los cruces de su rayo. Después observa pares de pistas de colores opuestos: el muro debe separar sus regiones. Si están muy cerca, esa obligación suele restringir con fuerza por dónde puede pasar. Las pistas del mismo color, en cambio, invitan a buscar una ruta que las deje juntas en el mismo lado.
Cuando dibujes un segmento, mira las casillas de paso vecinas. Una casilla del muro necesita exactamente dos conexiones. Si ya tiene dos, las demás quedan descartadas. Si sólo queda una salida posible para una casilla que ya tiene un segmento, esa salida es forzada. Este razonamiento de grado es común a muchos puzzles de bucles y resulta especialmente útil aquí porque las casillas de pista crean corredores.
No ignores las flechas con números mayores. A veces parecen débiles porque permiten varios repartos, pero dos flechas que miran a la misma zona pueden compartir segmentos candidatos y forzar una combinación. En niveles altos esa interacción reemplaza parte de la información explícita que los niveles fáciles ofrecen de forma más directa.
Qué comparte con otros puzzles de bucles
Si disfrutas Castle Wall, Masyu comparte la disciplina de construir un único bucle, pero sus pistas hablan de giros y tramos rectos. Slitherlink usa números locales alrededor de celdas y dibuja sobre una retícula distinta. Yajilin mezcla bucle con sombreado y pistas direccionales. Country Road añade regiones y restricciones de recorrido.
Castle Wall se distingue porque interior y exterior no son una consecuencia secundaria del bucle: son parte central de las pistas. Resolverlo obliga a alternar dos escalas de pensamiento. En una escala miramos grados, corredores y segmentos. En la otra pensamos en una frontera cerrada que separa conjuntos completos de pistas.
Esa combinación es la razón por la que queríamos una implementación propia en Blupoli. No se trata sólo de añadir otro icono al catálogo. Aporta una forma de razonamiento que complementa los bucles ya disponibles y permite que el sistema de dificultad mida un espacio de búsqueda diferente.
Qué verifica la integración de Blupoli
El juego no vive aislado. El catálogo se genera desde games/castle-wall/game.json; al pasar a disponible entra automáticamente en el smoke test dinámico de todos los juegos publicados. Ese smoke exige que la ruta monte sin errores de consola, que no aparezca un error de motor, que existan controles interactivos y que la guía esté disponible.
La finalización utiliza la capa compartida de progreso y produce un resultado común con tamaño, dificultad y semilla. Así Progreso puede registrar una sesión de Castle Wall sin que el juego invente un sistema paralelo. El onboarding, las pistas rápidas y los juegos relacionados también proceden del manifiesto canónico.
Finalmente, npm run verify ejecuta tests, checks y build, y la suite Playwright recorre tanto contratos globales como pruebas específicas. El objetivo es que publicar Castle Wall no sólo demuestre que Castle Wall funciona, sino que no rompe el resto de Blupoli Puzzles.
Lo que no hemos copiado
Las reglas de un género son conocimiento compartido; los tableros concretos, el texto editorial, el código y el arte de otros proyectos no lo son. Blupoli no incorpora puzzles publicados por Melon's Puzzles, Grandmaster Puzzles, puzz.link ni otras colecciones. Tampoco reutiliza su interfaz. El generador crea nuevas instancias a partir de semillas propias y el solver verifica esas instancias.
pzprjs es software abierto y su implementación de Castle Wall resulta una referencia valiosa para contrastar detalles de las reglas. En esta versión, sin embargo, elegimos un motor nativo porque queríamos controlar generación, métricas de dificultad, persistencia de decisiones y la integración con el shell actual. La referencia sirve para verificar conceptos, no para sustituir el diseño de Blupoli.
Esta separación también hace más fácil auditar el producto. Podemos explicar de dónde sale cada pista, qué demuestra la unicidad y qué métrica mueve la dificultad sin depender de un dataset opaco.
Una frontera sencilla, muchas decisiones
Castle Wall funciona porque transforma una propiedad geométrica elemental en una conversación entre pistas. Una pista blanca pregunta «¿cómo me dejas dentro?». Una negra pregunta «¿cómo me dejas fuera?». Una flecha añade «¿y cuántas veces cruzas por aquí?». El bucle tiene que responder a todas a la vez y seguir siendo uno solo.
Para Blupoli, completar el juego significaba respetar esa conversación también en el código. El generador conoce una solución pero no se fía de ella. El solver busca alternativas. Las semillas permiten repetir errores. La dificultad se observa con métricas en lugar de cambiar sólo una etiqueta. Y CI prueba miles de tableros antes de permitir que una modificación llegue a main.
La mejor forma de entenderlo sigue siendo jugar. Empieza por 6×6 Fácil para interiorizar color y flechas. Después conserva el tamaño y sube a Normal: notarás que desaparece parte de la información explícita y aparecen rutas extra. Cuando ese salto resulte natural, Difícil y Experto convierten el mismo vocabulario en un problema mucho más global.
Fuentes y referencias
- Melon's Puzzles — descripción de Castle Wall por Palmer Mebane.
- pzprjs — implementación abierta y changelog del tipo castle.
- Grandmaster Puzzles — archivo de Castle Wall.
- Masyu en Blupoli, Slitherlink y Yajilin como juegos relacionados.