Las tres reglas que definen Akari
Una bombilla ilumina horizontal y verticalmente hasta encontrarse con una casilla negra o con el borde del tablero. Todas las casillas blancas deben recibir luz. A la vez, ninguna bombilla puede iluminar directamente a otra. Algunas casillas negras incluyen además un número entre 0 y 4 que exige exactamente esa cantidad de bombillas en sus cuatro posiciones ortogonalmente adyacentes.
Por qué el wrapper anterior no era suficiente
Akari estaba conectado a PuzzleHub mediante un motor externo compatible y una partida de muestra. Eso servía para demostrar que la mecánica podía abrirse en el navegador, pero no cumplía el contrato actual del proyecto: no había selección real de tamaño y dificultad, ni catálogo propio de bases verificadas, ni persistencia de la partida, ni historial completo, ni una experiencia visual específica.
La reconstrucción lo mueve a un motor nativo. No porque necesitemos reescribir por principio, sino porque en este caso queríamos controlar generación, validación, estado, estadísticas, accesibilidad y diseño desde una misma representación del puzzle.
El solver piensa en segmentos de visibilidad
Representar simplemente cada casilla como “bombilla o no bombilla” sería correcto, pero desperdiciaría estructura. En cada fila y columna los muros dividen el tablero en segmentos de visibilidad. Dentro de uno de esos segmentos puede existir como máximo una bombilla.
Para cada casilla blanca precalculamos los dos segmentos a los que pertenece y, por tanto, todas las posiciones capaces de iluminarla. El solver propaga entonces tres familias de restricciones: un segmento con una bombilla obliga al resto a estar vacío; una pista numérica satisfecha descarta sus posiciones restantes y una pista a la que sólo le quedan exactamente las bombillas necesarias las fuerza; finalmente, una casilla que sólo pueda recibir luz desde una posición obliga a colocar allí una bombilla.
La solución única se demuestra
El contador de soluciones ejecuta la misma propagación y sólo ramifica cuando ninguna regla puede avanzar. Se detiene al encontrar dos soluciones: para PuzzleHub, una base que admite dos respuestas ya ha fallado, aunque visualmente parezca razonable.
El selfTest() recorre cada combinación de tamaño y dificultad. Para cada una exige exactamente una solución y después reconstruye el tablero resuelto para comprobar de nuevo iluminación completa, ausencia de cruces entre bombillas y cumplimiento exacto de todas las pistas.
Cuatro tamaños sin convertir el tamaño en dificultad
Akari ofrece tableros 5×5, 6×6, 7×7 y 8×8. El tamaño controla duración y densidad visual; la dificultad es un eje distinto. Un 5×5 Experto puede ocultar más información útil que un 8×8 Fácil.
Qué significa Fácil, Normal, Difícil y Experto
Dentro de cada tamaño partimos de una base con solución única y retiramos únicamente pistas numéricas que el solver demuestra redundantes. Fácil conserva más información local. Normal y Difícil eliminan parte de esas anclas. Experto mantiene menos números y obliga a combinar con más frecuencia cobertura, segmentos de luz y posiciones imposibles.
El test también comprueba que el número de pistas desciende estrictamente al aumentar la dificultad. No es una medida perfecta de dificultad humana, pero sí una propiedad concreta de la construcción, no una etiqueta cosmética.
Ocho variantes seguras por cada base
Rotaciones, reflexiones y transposiciones conservan exactamente las relaciones ortogonales de Akari. El motor utiliza las ocho simetrías del cuadrado para producir variantes visuales sin alterar la lógica de la base. No asumimos que una transformación sea segura por intuición: el selfTest() vuelve a resolver también cada una de esas variantes y exige de nuevo unicidad.
Una interfaz que enseña la iluminación
Las casillas iluminadas cambian de tratamiento visual en cuanto aparece una bombilla. Los focos tienen un halo propio y los conflictos se resaltan inmediatamente. Las pistas negras distinguen estado satisfecho y exceso de bombillas, de modo que el tablero comunica el problema antes de que el jugador tenga que pulsar un botón de comprobación.
Una pulsación recorre vacío → bombilla → ×; el clic derecho sirve como acceso directo a la marca ×. Deshacer y Rehacer permiten experimentar, Reiniciar recupera la misma base y Nueva partida cambia a otra simetría. El diseño funciona en modo claro y oscuro, escala desde móvil y respeta prefers-reduced-motion.
Persistencia y estadísticas
El estado local conserva tamaño, dificultad, variante, marcas, historial, rehacer, movimientos y tiempo activo. Cerrar la pestaña no destruye una partida a medias. Al completarla se registra además el mejor número de movimientos de cada combinación de tamaño y dificultad utilizando el sistema compartido de estadísticas de PuzzleHub.
Akari nació en Nikoli
La fuente oficial de Nikoli indica que Akari fue desarrollado por Nikoli en 2001. La misma página documenta las cuatro ideas que seguimos en el motor: bombillas sobre casillas blancas, números que cuentan bombillas adyacentes, luz que avanza por fila y columna hasta un muro y obligación de iluminar todas las casillas sin que una bombilla alcance a otra.
Preferimos esta atribución directa a repetir historias secundarias sin una fuente clara. En esta ocasión sí existe una referencia primaria del propio creador/editor del puzzle.
Qué verifica CI ahora
- 16 combinaciones base: cuatro tamaños por cuatro dificultades.
- Solución única demostrada por un solver independiente del estado de la interfaz.
- Ocho simetrías verificadas para cada combinación.
- Descenso estricto de pistas numéricas al subir de dificultad dentro de cada tamaño.
- La solución certificada ilumina todas las casillas, respeta los números y no enfrenta bombillas.
- El motor nativo, las traducciones, el onboarding, el catálogo y el build completo pasan por
npm run verify.
Fuente
Nikoli — Akari: reglas oficiales y atribución del desarrollo del puzzle a Nikoli en 2001.