Cómo construimos Blupoli
Decisiones técnicas y de producto, arquitectura, IA, diseño, experimentos, errores y aprendizajes del trabajo real.
Historias y decisiones
19Qué aprendimos al auditar y reconstruir Juego del 15, Akari, Ataxx, Hidato, Balance Loop, Battleship, Aquarium y Takuzu: generación, solución única, dificultad, persistencia, estadísticas, accesibilidad, responsive e i18n.
Leer en DevlogCómo evolucionamos PuzzleHub Journal con infografías semánticas, diagramas específicos de puzzles y un sistema editorial reutilizable que forma parte del build.
Leer en DevlogCómo construimos un onboarding compartido para 76 juegos con perfiles de interacción, asignación explícita por puzzle y controles de CI que evitan huecos de cobertura.
Leer en DevlogDesarrollo
4Qué aprendimos al auditar y reconstruir Juego del 15, Akari, Ataxx, Hidato, Balance Loop, Battleship, Aquarium y Takuzu: generación, solución única, dificultad, persistencia, estadísticas, accesibilidad, responsive e i18n.
Leer en DevlogQué hemos aprendido implementando motores verificados para Aquarium, Str8ts, Dominosa, Stitches, Slant y Kropki: exact cover, matching, ciclos, restricciones y solución única.
Leer en DevlogCómo convertimos el Zebra Puzzle en una familia rejugable de PuzzleHub con motor propio, relaciones espaciales, matriz de deducción, generación y validación de solución única.
Leer en DevlogCómo diseñamos generadores de puzzles con solver, solución única, dificultad real, variedad y presupuestos de tiempo para que un tablero no sea solo válido, sino interesante.
Leer en DevlogDiseño
3Cómo evolucionamos PuzzleHub Journal con infografías semánticas, diagramas específicos de puzzles y un sistema editorial reutilizable que forma parte del build.
Leer en DevlogCómo usamos Sudoku para diseñar la nueva experiencia común de PuzzleHub: jerarquía, controles, onboarding, feedback, temas y componentes reutilizables para decenas de juegos.
Leer en DevlogCómo construimos un sistema de UI compartido para PuzzleHub con game shell, temas, componentes, onboarding y estados comunes sin borrar la identidad de cada puzzle.
Leer en DevlogProducto
3Cómo construimos un onboarding compartido para 76 juegos con perfiles de interacción, asignación explícita por puzzle y controles de CI que evitan huecos de cobertura.
Leer en DevlogCómo superar los 70 juegos obligó a rediseñar PuzzleHub: catálogo, descubrimiento, modo claro, componentes compartidos, espacio de juego y separación de juegos contra CPU.
Leer en DevlogPor qué paramos de sumar juegos para auditar PuzzleHub como producto: UX, diseño, rendimiento, arquitectura, catálogo y un sistema de tareas para convertir hallazgos en mejoras reales.
Leer en DevlogIA y agentes
2Cómo usamos commits y cambios reales como materia prima para el Devlog de PuzzleHub sin convertir el Journal en un changelog ni automatizar la voz editorial.
Leer en DevlogCómo usamos agentes de IA, GitHub, documentación, delegación y revisión para construir PuzzleHub, qué está funcionando y dónde sigue siendo imprescindible el criterio humano.
Leer en DevlogCalidad e i18n
1Devlog: cómo PuzzleHub prepara español, inglés, italiano, portugués, francés y alemán con candidatos, gates de calidad y revisión antes de publicar.
Leer en DevlogArquitectura
4Cómo estamos preparando PuzzleHub para varios idiomas con una única fuente de verdad para juegos, rutas, categorías y lógica, además de SEO internacional y un flujo editorial sostenible.
Leer en DevlogPor qué hemos elegido Capacitor como primer camino de PuzzleHub hacia Android: reutilizar la web, evitar una reescritura prematura y reservar código nativo para donde aporte valor real.
Leer en DevlogQué aprendimos al pasar de unos pocos puzzles a un catálogo de decenas: arquitectura, descubrimiento, calidad, dificultad, UI compartida y el coste real de escalar PuzzleHub.
Leer en DevlogCómo diseñamos PuzzleHub para combinar motores de puzzles muy distintos, compartir producto y UI, automatizar el catálogo y crecer sin convertir cada juego en una aplicación independiente.
Leer en DevlogAprendizajes
2Arquitectura, motores, diseño, generación y proceso detrás de PuzzleHub: cómo una colección de decenas de juegos está evolucionando hacia una plataforma coherente.
Leer en DevlogCómo nació PuzzleHub: visión, arquitectura, decisiones de producto, IA y el reto de convertir decenas de puzzles en una plataforma coherente.
Leer en DevlogBitácora reciente
6La marca raíz se separa del producto y definimos una arquitectura por subdominios que permite a Puzzles crecer sin cargar con todo el ecosistema.
Mantenemos un único proyecto Firebase Blupoli, pero cada superficie obtiene su propio Hosting site, despliegue y dominio.
GitHub sigue coordinando el workflow, pero verificación, build y publicación pueden ejecutarse en infraestructura propia.
Configuramos gestión DNS libre, registros de verificación de Firebase y la separación entre dominio raíz y subdominio de Puzzles.
La portada deja de anticipar productos inexistentes, mantiene la identidad de marca y adopta el mismo comportamiento de tema persistente que Puzzles.
Separamos la navegación de juego de la publicación editorial como paso previo a mover Blog, Devlog y Devlog a una superficie propia.
Ahora y después
Los nuevos motores deben generar partidas fiables, reproducibles y con dificultad útil; los juegos antiguos pasan por la misma revisión progresivamente.
Estamos separando marca, producto, publicación, dominios y despliegues sin romper las rutas ni el trabajo existente.
La estructura es compartida y los perfiles pueden reutilizarse entre mecánicas compatibles, pero cada juego debe tener una asignación explícita. CI comprueba que ninguna incorporación se quede sin cobertura.
