Hay un punto en el crecimiento de una aplicación de puzzles en el que añadir más juegos deja de ser la prioridad inmediata. El catálogo puede seguir creciendo, pero el problema principal cambia: ¿qué ocurre entre un juego y el siguiente?, ¿qué pasa cuando cierras la página a mitad de una partida?, ¿cuánto espacio ocupa la aplicación cuando juegas en un teléfono?, ¿cómo aprende alguien una mecánica nueva?, ¿se mantiene el contexto al entrar desde una PWA instalada?
En Blupoli Puzzles llevamos varias iteraciones trabajando precisamente en esas preguntas. Algunas mejoras son muy visibles, como la nueva navegación compacta o la desaparición de la barra global mientras juegas en móvil. Otras casi no deberían llamar la atención, como restaurar un tablero exactamente donde lo dejaste o evitar que una partida terminada vuelva a contar estadísticas al abrirla. Juntas producen un cambio más importante que cualquiera de ellas por separado: Puzzles empieza a comportarse como una aplicación continua y no como una colección de páginas que casualmente comparten diseño.
Esta actualización reúne trabajo publicado durante los días 24 y 25 de septiembre de 2026, incluida la segunda pasada de jerarquía móvil que ya prioriza Continuar, Hoy, Favoritos, recomendaciones y descubrimiento. No mezclamos aquí el rediseño más profundo de Estadísticas y Récords que sigue una línea de trabajo separada; nos centramos en cambios que ya han sido integrados en la experiencia actual.
El móvil ya no es una versión encogida del escritorio
Una de las diferencias más visibles aparece nada más abrir Blupoli Puzzles en una pantalla compacta. Antes, la interfaz mantenía demasiadas decisiones propias de escritorio: una cabecera global ocupando la parte superior, navegación que competía con el contenido y juegos que debían encajar alrededor de elementos que no eran necesarios durante una partida.
La nueva estructura parte de otra idea: en móvil, el espacio vertical es una parte del producto. No basta con que todo «quepa». Cada franja permanente que añadimos reduce el tablero, obliga a comprimir controles o fuerza desplazamientos que interrumpen la mecánica. Por eso la aplicación compacta elimina la barra global superior y reserva el borde inferior para cinco destinos estables: Inicio, Hoy, Explorar, Progreso y Más.
Ese último acceso no es un cajón arbitrario. Aloja destinos que siguen siendo importantes —Logros, Rachas, accesos al ecosistema Blupoli, tema e idioma— pero que no necesitan consumir permanentemente una quinta parte adicional de la navegación. El objetivo no es esconder funciones, sino distinguir entre lo que se usa constantemente y lo que debe estar disponible sin robar espacio durante cada sesión.
Cuando empieza el juego, la aplicación se aparta
La diferencia es todavía más clara al entrar en un puzzle. En pantallas compactas desaparece también la navegación inferior global. El juego obtiene una pequeña cabecera local con volver, identidad del juego y acciones contextuales como ayuda o favorito. El resto del espacio pertenece al tablero y a los controles que realmente intervienen en la partida.
Esto resuelve un conflicto que se repetía en muchos motores: el tablero debía compartir viewport con navegación general, título grande, ayudas permanentes y barras de acciones. Cada elemento tenía una justificación individual, pero juntos convertían un teléfono en una sucesión de franjas antes de llegar al contenido jugable. La nueva jerarquía da prioridad a la actividad que el jugador ha elegido hacer en ese momento.
No significa que todos los puzzles deban caber sin ningún desplazamiento. Hay mecánicas y tamaños cuya altura real supera la pantalla. En esos casos, el contenido del juego puede desplazarse dentro del shell. La regla es más útil: no recortar el tablero ni fabricar una altura artificial para fingir que cabe. Primero se compactan los elementos periféricos; después se deja que el puzzle conserve un tamaño jugable.
Los controles secundarios dejan de competir con los principales
Una pantalla pequeña también obliga a decidir qué acciones merecen estar siempre delante. En algunos juegos, la barra de acciones había crecido hasta depender de desplazamiento horizontal. Técnicamente funcionaba, pero una acción importante podía quedar fuera de vista y un gesto lateral accidental podía mover la barra en lugar de interactuar con el puzzle.
La nueva convención mantiene las acciones prioritarias visibles y agrupa las secundarias bajo un control Más cuando el espacio lo exige. El DOM de las acciones sigue siendo estable para accesibilidad, lógica y pruebas; lo que cambia es la presentación. De esta forma, la adaptación responsive no necesita duplicar componentes ni crear una versión paralela de cada juego.
También hemos normalizado objetivos táctiles clave hasta un mínimo práctico de 44 píxeles. Esto afecta a navegación, calendario de rachas y controles comunes. Es una mejora poco espectacular en una captura, pero muy fácil de notar con el pulgar: reduce pulsaciones fallidas y evita que una interfaz densa obligue a jugar con precisión de ratón.
Salir de una partida ya no debería significar perderla
La otra gran mejora no ocupa espacio en la pantalla, pero cambia la relación con el producto. Blupoli Puzzles cuenta ahora con un contrato común de snapshots reanudables. Los motores disponibles guardan y restauran su estado de juego mediante una misma capacidad de plataforma en lugar de inventar cada uno su propia clave y su propia interpretación de «guardar».
Para una persona que juega, el efecto es sencillo: puedes dejar una partida a medias y volver más tarde sin esperar que el tablero vuelva a empezar. Para la plataforma, el cambio es mucho más profundo. Guardar no consiste únicamente en almacenar una matriz de celdas. Hay que conservar la configuración correcta, el intento al que pertenece el tablero, el tiempo acumulado, la dificultad, la semilla o variante cuando el juego es determinista y el estado concreto que el usuario ha modificado.
El host común se encarga de la identidad de sesión y del tiempo. Los motores reciben una capacidad limitada para cargar, guardar y limpiar su estado. Así se evita que cada puzzle conozca detalles del almacenamiento del navegador o invente una segunda fuente de verdad para la duración.
Guardar menos puede ser más fiable
En los juegos deterministas no tiene sentido duplicar datos que pueden reconstruirse. Si un tablero se genera a partir de una semilla y una configuración estables, el snapshot puede guardar esos identificadores junto al estado del jugador, en vez de serializar toda la estructura generada. Esto mantiene los snapshots más pequeños y reduce el riesgo de que dos representaciones de la misma partida se desincronicen.
Otros motores sí necesitan persistir una geometría más rica. El contrato común no obliga a todos a almacenar exactamente el mismo payload; obliga a que ese payload viva dentro de un sobre versionado y que el acceso al almacenamiento pase por la plataforma. La diferencia es importante. Estandarizar no significa borrar las necesidades de cada mecánica, sino decidir qué parte debe ser común para poder confiar en el sistema.
Durante la ampliación de esta cobertura se migraron los motores que todavía no exponían carga y guardado compartidos. La regla actual es que un juego publicado no debería quedar fuera de esta capacidad simplemente porque su implementación histórica fuese distinta.
Una partida terminada también merece ser restaurada correctamente
La persistencia planteó un caso menos obvio: ¿qué hacemos con una partida ya completada? Limpiarla inmediatamente parece razonable, porque ya no hay nada que continuar. Sin embargo, también elimina el resultado visible en cuanto se navega o recarga. Conservarla sin distinguir su estado crea un problema peor: al restaurarla, el sistema podría interpretar que existe una sesión activa o volver a registrar estadísticas.
La solución ha sido conservar snapshots completados con una marca explícita. Cuando vuelves a ellos, se restauran en modo de solo lectura y no reabren una sesión estadística. La acción Jugar de nuevo es la que crea un intento nuevo y limpia el contexto anterior. Esto permite ver el tablero resuelto sin convertir una simple visita en una segunda victoria.
Este comportamiento corrigió además regresiones concretas en el Juego del 15 y ayudó a detectar una colisión de nombres que hacía que el primer movimiento pudiera confundirse con una resolución. Son ejemplos de por qué una función transversal necesita probarse contra motores reales: los contratos comunes son útiles cuando descubren diferencias, no cuando las esconden.
El cronómetro pasa a ser una responsabilidad de la plataforma
La continuidad de una partida sería incoherente si cada motor midiera el tiempo de manera independiente. Por eso el cronómetro visible y la duración que se guarda comparten el mismo origen temporal en el host. La sesión empieza con la primera interacción significativa, se reanuda con el snapshot y se congela cuando termina.
Esta decisión también permite eliminar relojes locales duplicados. El jugador no debería ver dos tiempos distintos para la misma partida, y el código no debería tener que decidir cuál de ellos es el «real». La plataforma posee el lifecycle; el motor informa de movimientos, acciones y finalización.
Es una de esas decisiones que reducen interfaz y complejidad al mismo tiempo. Cuanto más trabajo puede resolver el shell común, menos excepciones necesita mantener cada juego y más fácil resulta que una mejora futura llegue a todo el catálogo de forma consistente.
Aprender un puzzle ahora ocurre dentro del puzzle real
La tercera pieza importante de esta etapa es el onboarding. Hasta ahora, una ayuda podía explicar una mecánica con un tablero simulado. El problema de las simulaciones es que envejecen por separado: una interacción enseñada puede dejar de coincidir con el juego real, una animación puede comportarse de otra forma o un control puede terminar teniendo reglas diferentes.
El nuevo onboarding reutiliza motores reales. La práctica se ejecuta en una instancia aislada del juego, separada de la sesión normal. Eso significa que el usuario aprende haciendo una interacción auténtica, con las mismas reglas que encontrará al empezar una partida, pero sin contaminar progreso, logros, rachas ni estadísticas.
El sistema agrupa mecánicas compatibles en familias reutilizables para no escribir un tutorial completamente distinto cuando varios juegos comparten patrón. Aun así, cada juego publicado debe tener una asignación explícita. Esa combinación nos interesa especialmente: reutilización donde de verdad existe una relación y cobertura verificable para impedir que una incorporación futura se quede accidentalmente sin ayuda.
Cerrar, saltar y completar ya no significan lo mismo
También se ha afinado la semántica del propio aprendizaje. Cerrar una guía puede permitir retomarla; saltarla expresa otra intención; completar la práctica significa que el jugador ha recorrido la interacción propuesta. Estas diferencias parecen pequeñas hasta que el onboarding deja de ser una ventana puntual y pasa a ser un sistema que debe acompañar a muchas mecánicas.
Cuando el motor soporta snapshots comunes, incluso el estado exacto de la práctica puede conservarse durante el intento. Y como esa práctica está aislada mediante almacenamiento de sesión específico, no aparece de repente como una partida pendiente en la experiencia normal.
El resultado es una ayuda menos teatral y más útil. No intentamos enseñar todos los detalles antes de jugar. El objetivo es reducir la primera barrera: que el jugador entienda qué tipo de acción produce una respuesta válida y pueda trasladar inmediatamente ese conocimiento al juego real.
Puzzles ya tiene una identidad PWA propia
La arquitectura de dominios planteaba una decisión importante. Blupoli vive en blupoli.com y el producto de puzzles en puzzles.blupoli.com. Primero exploramos mantener Puzzles dentro del alcance de la PWA principal mediante asociación entre orígenes. Esa solución podía recuperar espacio en flujos compatibles, pero seguía haciendo que la identidad instalada dependiese de una aplicación cuyo origen principal era otro.
La decisión final ha sido más simple de explicar y más robusta como producto: Blupoli Puzzles tiene ahora su propia identidad PWA estable. Se instala directamente desde https://puzzles.blupoli.com, aparece como “Blupoli Puzzles” —con nombre corto “Puzzles”— y define su propio id, start_url, scope raíz y modo standalone.
Cuando se lanza desde esa instalación, la navegación normal de Puzzles permanece dentro de su propio origen y alcance. Eso evita que la separación técnica entre la web principal y el producto se traduzca en una barra de sitio externo encima de la aplicación. También encaja mejor con el futuro empaquetado Android: Puzzles puede tener una identidad instalable clara sin fingir que todo Blupoli es una única app.
La misma aplicación, seis idiomas, un solo runtime
Mientras reorganizábamos shell, onboarding y superficies compartidas, centralizamos también el texto dinámico de ejecución. Home, catálogo, progreso, logros, rachas, finalización, onboarding y el host de juegos consumen ahora recursos canónicos de idioma en lugar de mantener traductores paralelos o sustituir texto a posteriori en el DOM.
Esto importa especialmente cuando una función transversal se expande. Un nuevo botón del shell no debería obligar a buscar seis implementaciones distintas ni depender del orden en que otro script transforme la página. La traducción debe formar parte del estado de la interfaz desde el principio.
Para el jugador la mejora puede pasar inadvertida, que es exactamente lo deseable. Cambiar de idioma debería modificar el producto de forma coherente, no revelar qué pantalla pertenece a una generación antigua del código y cuál usa la arquitectura nueva.
Las barras de juego también se están convirtiendo en componentes, no decoraciones
Otra pieza del mismo trabajo ha sido consolidar indicadores y acciones comunes alrededor de los tableros. En algunos motores, información como dificultad, tamaño, movimientos, mejor marca o tiempo aparecía en HUD propios, mientras la plataforma mostraba parte de esos datos otra vez. El caso de Akari dejó claro el coste: dos estructuras para explicar una sola partida.
La solución no consiste en imponer el mismo HUD a todas las mecánicas. Se han creado controles e indicadores reutilizables para los datos que sí son de plataforma, y el motor conserva la libertad de representar aquello que pertenece a sus reglas. De esta forma, un puzzle no necesita volver a resolver responsive, estados de foco, tema o tipografía para mostrar una métrica común.
También se mantiene una separación física más clara: los indicadores viven por encima del tablero y la barra de acciones por debajo. Evitar superposiciones no es sólo una cuestión estética; reduce la posibilidad de que un control tape una celda o una zona interactiva en tamaños ajustados.
La coherencia visual ya no depende de colores escritos a mano
En paralelo, el sistema de color de los juegos se ha movido hacia tokens semánticos. La categoría puede aportar identidad, el tema claro u oscuro puede ajustar contraste y cada componente consume variables que describen su función en lugar de asumir un hexadecimal concreto.
Esto ha permitido eliminar paletas locales en juegos que habían crecido con sus propios fallbacks. Cuando un tablero usa un color de superficie, selección o control, debería estar expresando una intención que el sistema puede adaptar. Si cada motor decide por su cuenta qué significa «fondo oscuro», el modo claro se convierte inevitablemente en una colección de excepciones.
La ventaja para quien juega es una interfaz más coherente sin que todos los puzzles pierdan personalidad. Compartir semántica no significa compartir exactamente el mismo aspecto. Numberlink, Sudoku o Ataxx pueden seguir teniendo identidades distintas; lo común es que el contraste, los estados y la relación con la categoría estén gobernados por reglas compatibles.
«Continuar» ya ocupa el primer lugar en la jerarquía de Home
El sistema de snapshots dejó de ser únicamente una capacidad técnica en cuanto Home pudo apoyarse en él. La jerarquía móvil actual prioriza Continuar → Hoy → Favoritos → Recomendaciones → Descubrir. La secuencia responde a una pregunta de producto sencilla: antes de ofrecer algo nuevo, conviene recordar si la persona ya estaba haciendo algo.
El catálogo también separa con más claridad lo que se puede jugar ahora de lo que está en desarrollo o próximamente. Los resultados jugables conservan la prioridad y el contenido futuro queda colapsado como información secundaria. La escala del catálogo ya no debería convertir una lista de posibilidades futuras en ruido por encima de los juegos disponibles.
Progreso y Rachas han adoptado además una divulgación progresiva compacta: las métricas y visualizaciones principales permanecen visibles y el detalle secundario puede expandirse cuando hace falta. El mismo criterio aparece en los estados de carga de los juegos, que ahora comparten un contrato canónico de loading, ready, completed y error junto a un skeleton común. No son adornos independientes; reducen saltos visuales y hacen que la plataforma se comporte de forma más predecible mientras un motor entra en escena.
El resultado es que «Continuar» ya no es una tarjeta decorativa que intenta adivinar si existe una partida. Se apoya en un estado de plataforma real, y Home puede colocar esa continuidad por delante del descubrimiento sin introducir excepciones por motor.
Una aplicación local-first puede sentirse continua sin exigir una cuenta
Blupoli Puzzles sigue siendo local-first. No hace falta iniciar sesión para que estas mejoras funcionen. Los snapshots viven en el navegador, igual que el progreso actual. La preparación para sincronización remota existe en la arquitectura, pero no estamos presentando Firebase como una función que ya sincroniza cuentas porque todavía no es así.
Esto permite entregar valor antes. Reanudar una partida en el mismo dispositivo no necesita esperar a que exista autenticación. Aprender una mecánica no necesita una base de datos remota. El shell móvil tampoco. Cada capa puede mejorar ahora y, al mismo tiempo, evitar decisiones que hagan más difícil una futura sincronización.
En términos de producto, local-first no debería sentirse como «provisional». Debería significar que el juego funciona de inmediato, incluso sin red, y que una cuenta futura amplía esa experiencia en lugar de desbloquear lo básico.
La frontera entre plataforma y motor es cada vez más visible para nosotros y menos visible para quien juega
Detrás de estas mejoras hay una idea repetida: el motor debe saber jugar; la plataforma debe saber presentar, recordar y conectar. Un motor de Sudoku entiende candidatos, errores y solución. Un motor de Numberlink entiende caminos. El shell entiende navegación, temporización y espacio. El host entiende lifecycle y snapshots. El onboarding entiende cómo aislar una práctica. Progreso y logros entienden resultados.
Cuando esas responsabilidades se mezclan, cada nuevo juego necesita recrear funciones que no tienen nada que ver con sus reglas. Cuando están separadas, una mejora en persistencia, controles o i18n puede beneficiar a todos sin convertir los motores en dependencias gigantes.
El jugador no debería tener que pensar en esta arquitectura. La señal de que funciona es precisamente la contraria: volver atrás, cambiar de juego, reanudar, abrir ayuda o rotar el teléfono se siente predecible aunque por debajo haya motores con tecnologías y estructuras muy distintas.
El objetivo táctil es una medida pequeña con impacto grande
Las auditorías móviles nos han recordado que profesionalizar una aplicación rara vez depende sólo de grandes rediseños. Un icono de 32 píxeles puede ser visualmente elegante y seguir siendo una mala superficie táctil. Una barra puede estar perfectamente alineada y obligar a desplazarla para descubrir una acción. Un header puede tener poca altura y aun así robar la franja decisiva que necesita un tablero cuadrado.
Por eso esta etapa combina decisiones estructurales con ajustes muy concretos. Los objetivos de 44 píxeles, el uso de iconos SVG deterministas en navegación y el respeto de safe areas son detalles que evitan que la experiencia cambie según fuente, navegador o dispositivo.
También son decisiones que preparan el camino para empaquetado nativo con Capacitor. No queremos construir una UI web que sólo sea cómoda con cursor y después descubrir, al envolverla como aplicación Android, que necesita una segunda interfaz. La superficie táctil debe ser buena antes.
La navegación compacta intenta reducir decisiones, no funciones
Cinco destinos persistentes pueden parecer una reducción, pero el objetivo real es jerarquía. Inicio y Hoy responden a «¿qué hago ahora?». Explorar responde a «¿qué puedo jugar?». Progreso responde a «¿cómo voy?». Más contiene herramientas y destinos importantes que no necesitan competir en cada instante.
En espacio amplio, el rail lateral sigue mostrando más destinos directamente porque existe anchura suficiente. La semántica no cambia: no mantenemos dos aplicaciones distintas, una para móvil y otra para escritorio. La misma navegación adapta la presentación según el espacio disponible.
Este principio evita uno de los problemas típicos del responsive complejo: que la versión móvil se convierta en una rama funcional separada. Cuanto más divergen las estructuras, más fácil es que una función llegue a escritorio y se olvide en móvil, o que una corrección de accesibilidad sólo se aplique a una de las dos.
La nueva experiencia no intenta ocultar que cada puzzle es distinto
Un sistema compartido puede caer en la tentación de convertir todos los juegos en la misma plantilla. No es nuestro objetivo. Las diferencias mecánicas siguen mandando en el tablero. Un juego de colocación, uno de caminos y uno competitivo no necesitan la misma densidad ni las mismas acciones específicas.
La estandarización ocurre alrededor de lo que sí se repite: volver, abrir ayuda, marcar favorito, medir tiempo, guardar estado, restaurar, registrar resultado, traducir controles, respetar tema y ofrecer una superficie táctil coherente. Cuanto mejor resolvamos ese perímetro, más espacio tiene el centro para ser distinto.
Es una relación importante. La personalidad de un puzzle debería venir de sus reglas y representación, no de que el botón «Nueva partida» esté en un sitio impredecible o de que sus colores ignoren el modo claro.
Qué puede notar ya una persona que vuelve hoy
Quien haya usado Blupoli Puzzles recientemente puede encontrar varios cambios a la vez. En móvil hay más espacio para jugar y menos chrome permanente. Las acciones principales son más fáciles de tocar. Una partida interrumpida tiene más posibilidades de continuar exactamente donde estaba. El resultado final puede permanecer visible sin volver a registrar estadísticas. La ayuda practica sobre la mecánica real. Una PWA instalada mantiene mejor la sensación de aplicación al saltar al subdominio de Puzzles.
Además, la mejora es transversal. No estamos presentando una función que sólo afecta a un juego concreto. El trabajo se ha hecho precisamente para que los contratos compartidos se conviertan en un requisito del catálogo disponible. Eso significa que una corrección en el host o el shell puede mejorar muchas experiencias a la vez.
Algunos detalles seguirán cambiando. La jerarquía principal de Home ya ha recibido su segunda pasada móvil, pero el rediseño más profundo de Estadísticas y la separación de Récords siguen siendo trabajo distinto. Preferimos no presentar esas líneas abiertas como terminadas. La continuidad descrita aquí es la base sobre la que podrán construirse sin volver a resolver persistencia, navegación o estado de carga.
La mejora más importante es que el producto recuerda el contexto
Una aplicación no se siente coherente sólo porque tenga un sistema de diseño. Se siente coherente cuando recuerda qué estabas haciendo y adapta su interfaz al contexto actual. Navegar necesita una cosa; jugar necesita otra; aprender una mecánica necesita aislamiento; terminar una partida necesita preservar el resultado sin duplicarlo.
Este conjunto de cambios acerca Blupoli Puzzles a esa idea. El shell sabe cuándo apartarse. El host sabe qué sesión pertenece al tablero. El snapshot sabe qué debe restaurar. El onboarding sabe que una práctica no es una partida normal. La PWA sabe que Puzzles forma parte del mismo producto instalado.
Son capas distintas resolviendo un mismo problema: continuidad. Y esa continuidad es especialmente importante en un catálogo de lógica, donde una sesión puede durar dos minutos o quedarse abierta durante mucho tiempo mientras piensas una deducción.
Lo siguiente podrá centrarse más en jerarquía y menos en reparar fundamentos
La ventaja de cerrar estas bases no es sólo lo que ya cambia. Home ya puede priorizar Continuar sobre el descubrimiento porque existe un estado común que la alimenta. Si Estadísticas necesita distinguir una sesión activa de una completada, el lifecycle ya lo hace. Y si Android usa Capacitor, la UI compacta y la PWA independiente de Puzzles ya han sido tratadas como superficies táctiles e instalables reales.
Esto no significa que la plataforma esté terminada. Al contrario: quedan revisiones importantes de estadísticas, récords, jerarquía de producto y profundidad de algunos motores. Pero el tipo de trabajo empieza a cambiar. Podemos dedicar más esfuerzo a cómo se entiende y disfruta cada superficie porque la infraestructura común absorbe tareas que antes estaban repartidas por decenas de implementaciones.
Ese es el sentido de esta actualización. No queremos que Blupoli Puzzles parezca una app porque oculte el navegador. Queremos que se comporte como una aplicación porque conserva estado, respeta contexto, reduce fricción y permite moverse entre sus partes sin perder el hilo.
Explorar la nueva base
Puedes abrir Blupoli Puzzles y probar la experiencia directamente desde móvil o escritorio. Si te interesa cómo habíamos llegado a la primera gran revisión responsive, el artículo De un catálogo enorme a una plataforma usable explica el punto de partida. Para entender por qué una partida sólo debe contar cuando empieza de verdad, el Devlog El progreso empieza cuando juegas entra en la semántica de sesiones y estadísticas.
Y si quieres la parte más técnica de esta etapa —cómo pasamos de almacenamiento repartido entre motores a ports, eventos versionados, snapshots y una salida preparada para sincronización futura— la acompañamos con un nuevo Devlog: De almacenamiento disperso a una arquitectura local-first preparada para sincronizar.
El objetivo de ambos textos es el mismo visto desde dos lados. Para quien juega, la plataforma debería desaparecer detrás de una experiencia más natural. Para quien la construye, esa naturalidad sólo es posible cuando las responsabilidades dejan de depender de excepciones y se convierten en contratos que todos los juegos pueden compartir.