PuzzleHub no nació porque faltaran Sudokus en Internet. Tampoco porque fuese difícil encontrar un Nonogram, un Kakuro o un Slitherlink. De hecho, ocurre justo lo contrario: hay décadas de buenos puzzles, comunidades especializadas y catálogos enormes. Lo que echábamos de menos era una casa común en la que descubrirlos, entenderlos y jugarlos sin sentir que cada vez entrábamos en un producto distinto.
La idea inicial era pequeña. La consecuencia no. En cuanto intentas poner decenas de mecánicas bajo el mismo techo aparecen preguntas de producto, diseño y arquitectura que no existen cuando desarrollas un único juego. Ese cambio de escala es, en realidad, el origen de PuzzleHub.
Un puzzle puede ser una página. Setenta puzzles necesitan una plataforma.
De una colección de juegos a un producto
La primera tentación al imaginar una web de puzzles es pensar en una gran cuadrícula de tarjetas. Cada tarjeta abre un juego y el trabajo parece terminado. Esa solución escala en cantidad, pero no necesariamente en calidad. Si cada juego decide por su cuenta dónde está el botón de reinicio, cómo se elige dificultad o cómo se explica una regla, el usuario tiene que volver a aprender la interfaz una y otra vez.
Queremos lo contrario. Aprender un puzzle debe significar aprender su lógica, no descubrir de nuevo cómo funciona PuzzleHub. La navegación, los controles globales, el lenguaje visual, la forma de presentar la dificultad y la ayuda deberían resultar familiares. El tablero puede ser completamente distinto; el producto que lo rodea no.
La consistencia que buscamos no consiste en hacer que todos los puzzles se vean iguales, sino en que ninguno parezca haberse escapado de otra aplicación.
Esta distinción ha terminado siendo una de las ideas más importantes del proyecto. Sudoku necesita números y candidatos. Nonogram necesita pistas laterales. Logic Grid funciona con matrices de relaciones. Numberlink necesita caminos. La capa común no puede borrar esas diferencias: tiene que liberar a cada juego para que dedique su complejidad a la mecánica que lo hace interesante.
Una base deliberadamente sencilla
La arquitectura inicial se apoya en HTML, CSS y JavaScript, generación mediante scripts y despliegue estático. Es una elección menos llamativa que empezar con una pila de frameworks, servicios y abstracciones, pero encaja con una propiedad fundamental del producto: la mayor parte de PuzzleHub puede ejecutarse directamente en el navegador.
Eso nos da páginas rápidas, costes bajos, una superficie operativa pequeña y código fácil de inspeccionar. También obliga a ser disciplinados. Cuando no existe un framework que imponga una estructura, las convenciones, los componentes propios y la documentación dejan de ser opcionales.
- Los metadatos de los juegos viven separados de su presentación.
- Los motores pueden evolucionar sin obligar a rehacer catálogo y navegación.
- La interfaz común se extrae cuando encontramos patrones reales, no antes.
- La generación y las comprobaciones de calidad se automatizan siempre que sea posible.
- Las decisiones importantes quedan documentadas para humanos y agentes de IA.
El primer reto inesperado: el catálogo
Al principio, “tener muchos juegos” suena como un objetivo. Después se convierte en un problema de información. Diez juegos caben en una portada. Setenta ya necesitan búsqueda, filtros, categorías, jerarquía, recomendaciones y una explicación clara de por qué alguien debería elegir uno que nunca ha visto.
Por eso los metadatos no son un detalle técnico. Nombre, familia, dificultad, tamaños, motor, descripción y estado de implementación terminan alimentando muchas superficies. Cuanto menos dependa el catálogo de HTML escrito a mano, más fácil será cambiar la experiencia cuando el número de juegos vuelva a duplicarse.
No todos los motores tienen que ser iguales
Otra decisión temprana fue evitar una obsesión por tener un único motor universal. Hay familias de puzzles que pueden compartir tecnología, pero también juegos con interacciones y modelos de estado suficientemente particulares como para justificar código propio. Forzar todos los casos dentro de una abstracción gigantesca solo desplazaría la complejidad.
La arquitectura que queremos es más pragmática: reglas y motores especializados por debajo, contratos de producto comunes por encima. Si mañana sustituimos la implementación interna de un generador, el usuario no debería perder su forma habitual de iniciar partida, cambiar dificultad o consultar ayuda.
La IA cambia la velocidad, no el criterio
PuzzleHub también es un experimento sobre cómo construir software con agentes de IA trabajando de forma cada vez más integrada. Pueden investigar una mecánica, implementar una primera versión, revisar código, documentar decisiones o transformar una auditoría en tareas. La ganancia de velocidad es enorme, pero introduce una paradoja: cuanto más rápido puedes producir código, más importante es decidir qué código merece existir.
Por eso el repositorio empezó pronto a acumular documentación de objetivos, arquitectura y convenciones. Un agente sin contexto puede resolver perfectamente la tarea equivocada. Un sistema de agentes sin criterios compartidos puede producir veinte implementaciones razonables que, juntas, no forman un producto.
Generar un puzzle válido no basta
Esta idea todavía no era evidente el primer día, pero acabaría definiendo buena parte del trabajo posterior. En un puzzle generado, “el tablero tiene solución” es un mínimo técnico, no una garantía de calidad. Puede haber varias soluciones. Puede ser trivial. Puede parecer difícil solo porque está lleno de ruido. Puede tardar demasiado en generarse.
Conforme PuzzleHub crece estamos incorporando solvers, comprobaciones de unicidad, presupuestos de tiempo y criterios de dificultad. En algunos casos hemos preferido rechazar generadores antes que publicar variedad falsa. Es una lección que merece quedar escrita desde el comienzo: el catálogo no tiene valor si la confianza del jugador se rompe.
Construir en público significa contar también lo incómodo
Este Journal nació para evitar convertirse en un changelog maquillado. Habrá artículos sobre juegos nuevos, pero también sobre algoritmos que no funcionaron, decisiones que tuvimos que deshacer, deuda visual, automatización, SEO, internacionalización, herramientas de IA y cambios de arquitectura.
Hay una razón práctica. Documentar el proceso obliga a explicar las decisiones con suficiente claridad como para descubrir contradicciones. También convierte la historia del proyecto en conocimiento reutilizable: dentro de unos meses podremos volver a estas páginas y entender no solo qué existe, sino por qué acabó siendo así.
Qué significa que PuzzleHub funcione
La medida más fácil sería contar juegos. Es visible, crece rápido y queda bien en una portada. Pero no es la medida que queremos optimizar a largo plazo. Una plataforma de puzzles funciona cuando puedes entrar sin saber qué jugar, descubrir algo interesante, entenderlo, resolverlo y querer probar otro.
Eso implica profundidad, no solo cobertura. Implica buenos generadores, dificultad creíble, interfaces cuidadas, accesibilidad, móvil, estadísticas, descubrimiento y una identidad suficientemente fuerte como para que el usuario recuerde dónde estaba jugando.
El tablero sobre el que vamos a construir
La primera versión de PuzzleHub no pretende ser el destino final. Es la infraestructura mínima sobre la que podemos iterar. Algunas decisiones cambiarán. Habrá motores que reescribiremos, componentes que hoy parecen suficientes y dentro de cincuenta juegos dejarán de serlo, y funciones que ahora parecen importantes pero acabarán desapareciendo.
Eso forma parte del proyecto. Si algo queremos conservar desde este primer artículo es la intención: construir una casa para los puzzles de lógica donde la cantidad sea consecuencia de una buena plataforma y no un sustituto de ella.
El resto de este Journal contará si lo conseguimos.