Construir, medir, documentar, repetir
La primera etapa estuvo dominada por una pregunta de cobertura: ¿podemos construir una base suficientemente flexible para alojar familias muy diferentes? La respuesta fue creciendo juego a juego. Después apareció una pregunta más difícil: ¿podemos conseguir que todo eso se sienta como una plataforma?
Ese cambio de pregunta explica buena parte del trabajo actual. Seguimos añadiendo y terminando juegos, pero dedicamos cada vez más esfuerzo a las capas que multiplican calidad: generación, componentes comunes, catálogo, temas, documentación y pruebas.
El objetivo nunca fue tener una lista enorme
Sudoku, Kakuro, Nonogram, Numberlink, Slitherlink, Hex, Ataxx o Nine Men's Morris tienen necesidades distintas. Tener una ruta para cada uno era un primer problema técnico, pero no el objetivo final.
La meta es que compartan una capa de producto: navegación, progreso, estadísticas, controles, responsive, accesibilidad e identidad. Eso obliga a separar el motor que conoce las reglas de la experiencia PuzzleHub que lo envuelve.
Cada juego debería aportar su mecánica; la plataforma debería evitar que tenga que reinventar todo lo demás.
Una arquitectura deliberadamente sencilla
La base se genera como HTML, CSS y JavaScript estático. Es barata de servir, rápida y fácil de distribuir. Que el frontend sea estático no impide añadir servicios cuando exista una razón: cuentas, sincronización, rankings o funciones competitivas pueden necesitar otra frontera.
La regla es no introducir infraestructura antes de que exista el problema. El navegador puede resolver y representar puzzles; aquello que tenga valor compartido o competitivo puede requerir garantías del servidor.
Muchos motores, un contrato común
No intentamos esconder todas las mecánicas detrás de un único motor universal. Algunos juegos se benefician de implementaciones propias; otros pueden apoyarse en motores externos compatibles y correctamente atribuidos.
Lo importante es la frontera. La plataforma necesita saber cómo iniciar, reiniciar, presentar dificultad, guardar estado o comunicar victoria sin conocer cada detalle interno.
El reto real: generar buenos puzzles
Un tablero válido no es necesariamente un buen puzzle. Un generador tiene que producir variedad, controlar dificultad y evitar configuraciones triviales. Para algunos juegos eso significa técnicas lógicas; para otros, reducir caminos obvios, controlar branching o demostrar solución única.
Norinori nos obligó incluso a rechazar generadores que parecían funcionar porque el solver encontraba varias soluciones. Numberlink nos ha enseñado el problema complementario: corrección sin dificultad sigue siendo una experiencia pobre.
Solver y self-test como parte del producto
Cada vez más motores incluyen una comprobación independiente. El generador propone; el solver verifica. Y cuando exponemos una matriz de tamaños y dificultades, intentamos recorrerla automáticamente para detectar combinaciones olvidadas.
CI empieza así a proteger propiedades que van más allá de «el código compila». Puede impedir que publiquemos una variante ambigua o una configuración que nunca fue probada.
- generación reproducible y acotada;
- solución única cuando el género la requiere;
- dificultad separada del tamaño;
- self-tests sobre variantes públicas;
- fallbacks antes que bloqueos largos del navegador.
Estadísticas antes de las cuentas
También introdujimos progreso local: qué juegos se abren, cuáles se resuelven y mejores resultados. Esto permite diseñar estadísticas sin bloquear el producto esperando un sistema completo de cuentas.
Más adelante esos conceptos pueden sincronizarse. Nos interesan preguntas que ayuden a descubrir y mejorar: qué categorías juegas más, qué dificultad prefieres o qué puzzle podrías probar después.
Una identidad común sin borrar cada juego
El diseño nació alrededor de un tema oscuro, pero ya estamos añadiendo modo claro y un sistema más explícito de componentes. Sudoku funcionó como laboratorio para controles, onboarding y jerarquía; después empezamos a extraer piezas reutilizables.
La consistencia vive alrededor del tablero. Dentro, cada puzzle conserva regiones, líneas, pistas, colores o geometrías que necesita.
Más de setenta opciones cambian el Home
El catálogo ya no puede comportarse como una lista. Categorías, búsqueda, filtros y contexto cognitivo empiezan a formar parte del producto. Queremos que alguien encuentre un juego por el tipo de reto que busca, aunque no conozca su nombre.
También hemos separado los juegos competitivos que se jugarán contra el sistema, porque su contrato es diferente al de un puzzle de solución individual.
La IA como parte del proceso
PuzzleHub es además un experimento de desarrollo asistido por agentes. Estamos utilizando IA para investigación, implementación y revisión, pero con una conclusión cada vez más clara: cuanto más rápido podemos producir cambios, más importante es disponer de contexto, tareas acotadas y validación independiente.
Git, documentación y CI son lo que convierte velocidad de generación en un flujo de ingeniería revisable.
Qué viene ahora
Las siguientes capas son claras: terminar generadores y dificultad, continuar el sistema visual, mejorar descubrimiento, completar internacionalización, reforzar accesibilidad y preparar el camino móvil con Capacitor sin duplicar prematuramente la plataforma.
La parte más valiosa ya no es que exista una base sobre la que añadir juegos. Es que cada semana entendemos mejor qué debería hacer esa base por ellos.
Devlog nos permite dejar registro de ese cambio: PuzzleHub no está creciendo solo en número de páginas. Está aprendiendo a crecer.