Durante la primera etapa de Blupoli Puzzles dedicamos mucha energía a ampliar el catálogo, probar familias distintas y descubrir qué debía ser común entre juegos que no se parecen entre sí. Ese trabajo nos dio motores, componentes, onboarding, localización y una arquitectura capaz de sostener muchas mecánicas. Pero una plataforma no se reconoce solo por la cantidad de cosas que contiene. Se reconoce por lo que ocurre entre una partida y la siguiente.
Esta semana hemos trabajado precisamente en esa capa intermedia. La Home ya no se limita a enseñar tarjetas. El área de progreso ya no se limita a contar partidas. Y, por debajo, los juegos han empezado a producir un resultado normalizado que la plataforma puede entender sin conocer los detalles internos de cada motor.
La Home deja de ser una portada y se convierte en un lobby
La nueva Home de Blupoli Puzzles está diseñada alrededor de una pregunta más útil que “¿qué juegos tenemos?”: “¿qué quieres resolver hoy?”. El cambio parece de interfaz, pero en realidad modifica el papel de la página de entrada.
Ahora puede recuperar juegos recientes, favoritos, recomendaciones locales y pequeñas selecciones que cambian con el día. También muestra continuidad mediante rachas, actividad y accesos directos al progreso. Todo esto funciona localmente en el navegador y no exige crear una cuenta.
La decisión de mantenerlo local-first es deliberada. Queremos que la plataforma sea útil desde la primera partida, antes de introducir registro, perfiles o sincronización. Una cuenta podrá añadir valor más adelante; no debería ser el requisito para que la experiencia básica recuerde lo que acabas de hacer.
“Mi progreso” ya es un dashboard, no un contador
La segunda pieza es el nuevo dashboard de progreso. Hasta ahora podíamos conservar agregados sencillos: partidas, victorias, tiempos o actividad. La nueva capa añade historial detallado, evolución, récords, actividad por días y exportación de datos, manteniendo el navegador como fuente primaria.
Esto cambia la relación entre los juegos y el resto del producto. Una partida deja de desaparecer cuando se cierra el tablero. Puede convertirse en parte de una historia: qué jugaste, cuándo, cuánto duró, si la terminaste y qué métricas tenía sentido conservar.
El sistema está preparado para crecer sin inventar datos del pasado. Los agregados anteriores se mantienen, pero no fabricamos sesiones históricas con fechas o duraciones que nunca medimos. El detalle empieza a existir desde el momento en que realmente puede registrarse.
El cambio invisible: todos los juegos empiezan a hablar el mismo idioma
La novedad técnica más importante de esta tanda probablemente sea la menos visible. Hemos introducido un contrato común llamado GameResult. Su función es sencilla de explicar: cada juego puede tener reglas completamente diferentes, pero cuando una partida termina debe poder describir el resultado con una estructura que la plataforma entienda.
Ese resultado puede indicar que un puzzle fue resuelto, que una partida competitiva terminó en victoria, derrota o empate, o que una sesión quedó abandonada. Puede incluir duración, movimientos, pistas, reinicios, tamaño, dificultad, identificador de puzzle y puntuación cuando esas métricas existen.
Los datos específicos de una mecánica no se fuerzan dentro de un esquema gigante. Cada juego puede añadir metadata serializable para aquello que solo tiene sentido en su dominio. Así mantenemos un núcleo estable sin fingir que PolyPivot, Sudoku y Ataxx necesitan exactamente las mismas estadísticas.
Registrar también los intentos abandonados importa
Una plataforma de progreso no debería confundir “abrí el juego” con “lo completé”. El host compartido abre una sesión cuando se monta un juego y puede cerrar un intento sin terminar como abandonado cuando la persona navega fuera.
Esta diferencia permite que las futuras estadísticas sean más honestas. También será útil para analizar fricción: un puzzle que se abre muchas veces y se abandona inmediatamente cuenta una historia distinta de uno que se completa con frecuencia.
La persistencia usa una cola duradera antes de escribir el historial detallado en IndexedDB. El objetivo es reducir el riesgo de perder el último resultado cuando se cierra una pestaña o se cambia de página justo al terminar una partida.
Por qué hacemos esto antes de añadir cuentas
Hace unos días nos planteamos si tenía sentido desarrollar retos diarios y rachas antes de introducir registro y perfiles. La respuesta fue separar dos problemas que parecían uno.
No necesitamos una cuenta para empezar a medir bien una partida. Sí necesitaremos una identidad cuando queramos sincronizar progreso entre dispositivos, recuperar historial desde otro navegador o mantener sistemas competitivos asociados a una persona.
Por eso la arquitectura actual prepara el terreno sin adelantarse al producto. El historial detallado es local. Los resultados tienen IDs estables y un esquema versionado. La documentación ya contempla una futura sincronización con Firebase Auth y Firestore, pero esa sincronización no forma parte de esta entrega.
El beneficio es importante: cuando llegue el momento de introducir cuentas, no tendremos que volver a enseñar a decenas de motores cómo guardar sus resultados. La capa de sincronización podrá trabajar con el mismo contrato que ya alimenta el dashboard local.
Un punto de integración para lo que viene después
Cuando un resultado normalizado entra de forma segura en la persistencia local, la plataforma emite un evento común. Esta pieza puede parecer pequeña, pero evita uno de los problemas más caros al crecer: acoplar cada nueva funcionalidad a cada juego.
Un futuro sistema de logros podrá escuchar resultados. Un reto diario oficial podrá marcar una sesión concreta. Un sistema de rachas podrá consumir actividad. Y una futura sincronización remota podrá subir resultados sin conocer cómo dibuja el tablero cada motor.
La regla que queremos conservar es simple: los juegos describen lo que ocurrió; la plataforma decide qué hacer con esa información.
Y sí: PolyPivot ya forma parte de Blupoli
Entre todos estos cambios de plataforma también ha llegado un juego nuevo. PolyPivot es un puzzle espacial original de Blupoli basado en poliominós que solo pueden moverse rotando alrededor de uno o dos ejes.
Algunas piezas tienen doble pivote, lo que permite “caminar” por el tablero alternando giros. Los solapamientos están permitidos mientras resuelves y se muestran mezclando visualmente los colores de las piezas implicadas. El objetivo final es encajarlo todo dentro del marco sin huecos ni superposiciones.
PolyPivot merece su propia historia, así que no vamos a repetirla aquí. Ya hemos publicado el artículo específico de PolyPivot, con la mecánica, la generación reversible, los dobles ejes y las decisiones de diseño detrás del juego.
Un juego nuevo también sirve para probar la plataforma nueva
La llegada de PolyPivot tiene otro valor: obliga a comprobar que un título nuevo entra en Blupoli a través de los contratos actuales, no de excepciones heredadas. Tiene onboarding, localización, integración con el host y la misma obligación que el resto de juegos disponibles de producir resultados compatibles con la capa común.
Eso es exactamente lo que buscamos cuando hablamos de convertir Blupoli en plataforma. Añadir un juego debería implicar construir su mecánica y sus particularidades, no volver a resolver desde cero navegación, progreso, persistencia, traducciones o estadísticas.
La Home, el dashboard y GameResult forman una misma historia
Vistos por separado, estos cambios podrían parecer tres features. Juntos forman algo más interesante.
La Home ayuda a decidir qué jugar y recuerda contexto. El motor ejecuta la partida. GameResult transforma el final de esa partida en información común. El repositorio la conserva. El dashboard la convierte en una historia comprensible. Y las futuras capas —retos, logros, cuentas o sincronización— pueden construirse encima sin perforar cada juego individual.
Ese recorrido es la diferencia entre tener muchas experiencias dentro de una web y empezar a tener un producto que las conecta.
Seguimos evitando adelantar sistemas que todavía no necesitamos
Que la arquitectura esté preparada no significa que vayamos a activar inmediatamente registro, perfiles públicos, rankings o sincronización. Todavía estamos completando y revisando juegos, definiendo diseños y cerrando piezas fundamentales de la experiencia.
Preferimos usar esta etapa para asegurar que los datos nacen bien desde el origen. Cuando añadamos una capa de identidad, queremos que resuelva problemas reales —continuidad entre dispositivos, recuperación, personalización o comunidad— y no que exista simplemente porque una plataforma “debería tener cuentas”.
Qué cambia hoy para quien juega
La mejora más visible es que Blupoli Puzzles tiene una entrada mucho más orientada a jugar: recientes, favoritos, recomendaciones, selecciones del día y accesos a progreso. La segunda es que el área de estadísticas empieza a ofrecer una lectura más rica de la actividad.
La tercera tardará más en notarse, pero probablemente sea la que más posibilidades abre: a partir de ahora tenemos una forma común de entender qué pasó en una partida.
Ese contrato no es una feature vistosa. Es una pieza de infraestructura. Y precisamente por eso puede convertirse en la base de muchas features visibles sin obligarnos a construir una integración distinta para cada puzzle.
La nueva etapa de Blupoli se parece menos a sumar tarjetas
Hace poco explicábamos que queríamos pasar de “más juegos” a “más juegos terminados”. Esta actualización continúa esa idea. La madurez de la plataforma no depende solo de cuántos títulos estén disponibles, sino de cuánto comparten cuando tiene sentido compartir y cuánto pueden conservar su identidad cuando no.
PolyPivot añade una mecánica nueva. El lobby mejora descubrimiento y retorno. El dashboard convierte actividad en continuidad. GameResult crea un lenguaje común. Son trabajos distintos, pero apuntan en la misma dirección: que Blupoli Puzzles sea una colección amplia sin sentirse como una suma de proyectos aislados.
Si quieres seguir la parte más técnica del proceso, continuaremos documentándola en Building in public. Y si te interesa el nuevo juego, la mejor siguiente lectura es PolyPivot: encajar piezas sin arrastrarlas.