De catálogo a sistema de descubrimiento
En septiembre de 2026 el proyecto que entonces todavía se llamaba Blupoli cruzó un umbral que parecía, a primera vista, puramente cuantitativo: el catálogo ya reunía más de setenta juegos. Hoy el producto se llama Blupoli Puzzles, y aquella cifra no debe leerse como un contador actual. Fue una fotografía de una fase concreta del proyecto. Lo importante de esa fotografía no es el número en sí, sino lo que obligó a admitir: una colección grande deja de comportarse como una colección de páginas y empieza a exigir decisiones propias de una plataforma.
Hasta ese momento, buena parte del crecimiento podía explicarse con una imagen sencilla: cada nuevo juego añadía una nueva posibilidad. El catálogo aumentaba, la portada ganaba otra tarjeta y el proyecto parecía más completo. Pero el mismo mecanismo que funcionaba con diez o veinte opciones empezó a romperse cuando la oferta dejó de caber mentalmente en una única mirada. Añadir más ya no mejoraba automáticamente la experiencia. En algunos casos la empeoraba, porque cada incorporación hacía más difícil encontrar, comparar y entender lo que ya existía.
El momento en que una lista deja de ser un catálogo
Una lista funciona bien cuando el usuario conoce casi todos sus elementos o cuando puede recorrerla sin esfuerzo. Un catálogo tiene un problema distinto: debe ayudar a tomar una decisión entre opciones que quizá no se conocen. Eso exige estructura. Nombres, categorías, señales de dificultad, descripciones, relaciones entre juegos y mecanismos de búsqueda dejan de ser metadatos secundarios y pasan a formar parte de la experiencia principal.
La diferencia puede parecer semántica, pero cambia el trabajo de producto. Si la portada solo ordena tarjetas, el diseño se concentra en hacerlas legibles. Si la portada debe orientar, entonces cada tarjeta necesita responder preguntas: ¿qué tipo de razonamiento propone?, ¿es un juego familiar o algo extraño?, ¿cuánto dura una partida?, ¿qué dificultad ofrece?, ¿qué relación tiene con otros puzzles que ya me gustan? El catálogo deja de ser inventario y empieza a actuar como guía.
Setenta y una experiencias significaban setenta y una oportunidades de inconsistencia
El crecimiento también amplificó una deuda menos visible. Cada juego había nacido en un momento distinto del proyecto. Algunos utilizaban motores propios, otros integraciones externas; algunos tenían controles muy pulidos, otros conservaban decisiones heredadas de prototipos. Había diferencias en espaciado, onboarding, feedback, estados, anchura y uso del color. Ninguna inconsistencia aislada era catastrófica. Juntas producían la sensación de que el usuario estaba cambiando de aplicación cada vez que cambiaba de puzzle.
Ese efecto es típico de productos que crecen por acumulación. La primera versión de cada pantalla resuelve una necesidad local y, si no existe una revisión posterior, las soluciones locales se convierten en dialectos. Cuando hay cinco páginas, el usuario puede tolerarlo. Cuando hay decenas, el coste cognitivo se vuelve parte del producto. La plataforma necesitaba un vocabulario común sin borrar la personalidad de cada mecánica.
La respuesta no era hacer que todos los tableros parecieran iguales
Una simplificación tentadora habría sido imponer una plantilla visual rígida: misma distribución, mismos controles, misma densidad y una apariencia casi idéntica en todos los juegos. Eso habría reducido algunas diferencias, pero a costa de ignorar lo más valioso del catálogo. Un Nonogram necesita pistas periféricas y estados de celda; Sudoku necesita candidatos y cajas; Logic Grid necesita matrices; Slitherlink vive en sus aristas; un juego contra CPU necesita turno, oponente y feedback competitivo.
La consistencia útil tenía que situarse alrededor de esas diferencias. El usuario debía reconocer cómo iniciar otra partida, cambiar dificultad, encontrar ayuda, deshacer, entender un estado global o volver al catálogo. El tablero, en cambio, debía conservar la representación que mejor expresa su lógica. Esa separación entre shell compartido y mecánica específica acabó siendo una de las ideas centrales de la arquitectura de Blupoli Puzzles, y la desarrollamos más tarde con detalle en el trabajo sobre el sistema de UI compartido.
Sudoku funcionó como un laboratorio, no como una plantilla universal
Para no diseñar el sistema común en abstracto, elegimos Sudoku como lugar de experimentación. Era un puzzle suficientemente conocido como para que cualquier fricción de interfaz resultara evidente: si una persona no entendía dónde estaban las notas, cómo cambiar de valor o qué significaba un estado, el problema probablemente estaba en nuestra UI y no en la rareza de la mecánica.
La intención nunca fue copiar Sudoku en setenta páginas. El objetivo era extraer decisiones que sobrevivieran al cambio de juego. El trabajo sobre jerarquía, acciones cercanas al tablero, feedback, onboarding y temas se fue probando después en otros motores. Esa metodología —resolver primero una experiencia concreta, extraer después el patrón— quedó documentada en Sudoku como laboratorio de producto.
El ancho de una página también puede ser una decisión de jugabilidad
Uno de los hallazgos más simples fue también uno de los más reveladores. El contenedor general de la web había nacido con proporciones cómodas para contenido y pantallas sencillas, pero algunos tableros grandes quedaban demasiado comprimidos. En un sitio editorial, limitar la anchura suele mejorar la lectura. En una pantalla de juego, la misma regla puede empeorar la interacción.
Ampliar el espacio útil no fue un cambio cosmético. Permitió que la interfaz reconociera que el tablero es el contenido principal. A partir de ahí fue más natural distinguir entre medidas de lectura y medidas de interacción, y diseñar layouts capaces de adaptarse a ambos contextos. Esta clase de decisión ilustra por qué una plataforma no puede depender de una única regla visual aplicada a todo.
El modo claro sirvió como detector de acoplamientos
La primera identidad visual había crecido alrededor de superficies oscuras. Cuando empezamos a extender un tema claro, aparecieron de inmediato colores hardcodeados, bordes que solo tenían sentido sobre un fondo concreto, estados de selección demasiado dependientes del contraste original y componentes que habían mezclado estructura con estética.
Por eso el modo claro terminó siendo más útil de lo que su nombre sugiere. No era solo una preferencia de apariencia: era una prueba de arquitectura visual. Un componente que puede cambiar de tema mediante tokens y estados definidos suele estar mejor aislado que uno que conoce directamente el color de su pantalla de origen. La segunda apariencia obligó a convertir supuestos implícitos en reglas explícitas.
Las categorías pasaron de ser etiquetas a ser herramientas de descubrimiento
Cuando hay pocos juegos, una categoría puede limitarse a agrupar. Cuando hay muchos, debe explicar. “Números”, “caminos”, “deducción” o “espacial” solo resultan útiles si ayudan a anticipar qué clase de reto encontrará una persona. Empezamos a enriquecer la taxonomía con tipos de mecánica, habilidades y relaciones entre familias para que el catálogo pudiera ser explorado incluso sin conocer nombres concretos.
Ese cambio también abrió una posibilidad más interesante: recomendar por afinidad de razonamiento, no únicamente por popularidad. Alguien que disfruta de restricciones locales puede descubrir Kropki; quien prefiere completar estructuras puede saltar a Nonogram; quien busca relaciones entre entidades puede encontrar Logic Grid o el Acertijo de Einstein. La taxonomía deja de ser una clasificación administrativa y se convierte en una interfaz de descubrimiento.
Separar puzzles de juegos contra CPU aclaró el contrato del producto
El catálogo incluía experiencias que, aunque podían jugarse de forma individual, no compartían el mismo contrato que un puzzle de solución. Ataxx, Hex o variantes de Morris plantean una oposición activa. Hay turnos, una respuesta del sistema y un resultado competitivo. Tratar esas experiencias como si fueran simplemente otro tablero lógico hacía más difícil diseñar estadísticas, dificultad y feedback adecuados.
La decisión fue mantener la experiencia centrada en una sola persona, pero distinguir claramente las mecánicas contra CPU. Eso permite compartir identidad, navegación y capa de producto sin fingir que todos los juegos miden lo mismo. Resolver, ganar, perder, empatar o superar un nivel de oponente son conceptos diferentes y deben modelarse como tales.
La dificultad dejó de poder esconderse detrás del tamaño
Otro efecto del catálogo grande fue revelar que “fácil, medio, difícil” significaba cosas diferentes según el motor. En algunos juegos se había aproximado la dificultad cambiando el tamaño; en otros, retirando pistas; en otros, aumentando profundidad de búsqueda. Esa heterogeneidad no era necesariamente un problema, porque cada puzzle tiene una estructura distinta, pero sí exigía que la etiqueta reflejara algo real dentro de cada mecánica.
Una plataforma madura no necesita un algoritmo universal de dificultad. Necesita un contrato honesto: cuando una opción se llama “difícil”, el jugador debe notar una diferencia razonable y el motor debe poder justificarla con señales propias. En algunos casos eso significa técnicas lógicas; en otros, branching, densidad, longitud de cadenas o fuerza del rival. La escala común es de producto; la medición interna sigue siendo específica.
Más juegos hicieron más importante terminar los que ya existían
En una fase temprana, la tentación es medir avance por cobertura: cuántas mecánicas nuevas podemos incorporar y qué parte del territorio de puzzles somos capaces de representar. Esa exploración fue útil porque reveló necesidades arquitectónicas. Pero el mismo criterio pierde valor cuando la base ya es amplia. A partir de cierto punto, mejorar generación, persistencia, accesibilidad o onboarding en veinte juegos aporta más que añadir el vigésimo primero sin cerrar esas capas.
Ese cambio de prioridad acabaría cristalizando en una auditoría más sistemática, descrita en la entrada sobre parar de añadir para auditar. El mensaje de fondo es el mismo: cantidad y calidad no son enemigos, pero pertenecen a ritmos distintos. Hay momentos para explorar y momentos para consolidar lo aprendido.
Un catálogo grande convierte el contenido en parte del producto
Con decenas de puzzles poco conocidos, la interfaz sola no puede cargar con toda la explicación. Reglas, descripciones, artículos y onboarding empiezan a cumplir una función de descubrimiento. Un nombre como “Norinori” o “LITS” no comunica por sí mismo cómo se juega. Si la ficha solo muestra un título y un botón, el usuario debe decidir a ciegas.
Por eso el contenido editorial y el catálogo se fueron acercando. Una buena descripción puede anticipar la mecánica; una categoría puede explicar qué tienen en común varios juegos; un artículo puede ofrecer contexto a quien quiere profundizar. En Blupoli esa relación sigue siendo importante: el Blog, el Devlog y las páginas de puzzles no son sistemas aislados, sino distintas maneras de ayudar a entender y recorrer el mismo producto.
La búsqueda no debía ser solo una caja de texto
Cuando alguien conoce el nombre de un juego, una búsqueda textual resuelve el problema. El reto interesante aparece cuando no sabe qué buscar. “Quiero algo corto”, “me apetece deducción sin números”, “quiero un puzzle parecido a Sudoku pero diferente” o “prefiero caminos y regiones” son intenciones que una lista alfabética no entiende.
La arquitectura de catálogo empezó a prepararse para filtros y señales que pudieran combinar nombre, categoría, mecánica y estado. No todas esas posibilidades tenían que construirse al mismo tiempo. Lo importante era que los datos de cada juego dejaran de estar dispersos en HTML y pasaran a formar una fuente de verdad capaz de alimentar distintas superficies.
Centralizar metadatos redujo también el coste de mantener la plataforma
El crecimiento hizo evidente una regla de ingeniería: cualquier dato que se copie manualmente en muchos lugares terminará divergiendo. Si el nombre, la disponibilidad o la categoría de un puzzle aparece escrito por separado en portada, ficha, navegación y artículos, cada cambio requiere memoria humana. A escala, esa memoria falla.
La solución fue mover identidad y estado hacia estructuras que el build pudiera reutilizar. Esa decisión no solo simplifica el catálogo. También ayuda a estadísticas, sitemaps, navegación, localización y contenido editorial. Un producto grande mejora cuando sus superficies derivadas dejan de inventar datos y empiezan a leerlos.
La plataforma tenía que aprender a decir “todavía no”
Una colección pequeña tiende a mostrar todo lo que existe. Una plataforma con ambición de calidad necesita distinguir entre prototipo, juego disponible, experimento y trabajo futuro. La etapa de expansión nos enseñó que presencia en el repositorio y disponibilidad pública no son sinónimos. Esa separación se volvió todavía más explícita después, cuando empezamos a marcar experiencias incompletas como próximas en lugar de presentarlas como terminadas.
La consecuencia es saludable: el catálogo deja de ser un espejo pasivo del árbol de archivos y se convierte en una selección editorial. Publicar significa recomendar. Si algo todavía no alcanza el estándar de generación, interfaz o accesibilidad, puede seguir existiendo como trabajo de desarrollo sin ocupar la misma categoría que una experiencia terminada.
La escala también cambia la forma de probar
Con pocos juegos, una revisión manual puede recorrer casi todo el producto. Con decenas, la combinatoria crece: tamaños, dificultades, idiomas, temas, estados de partida, breakpoints y tipos de motor. La única forma de mantener una base amplia sin convertir cada release en una expedición manual es automatizar invariantes repetibles.
Los quality gates empezaron a cubrir rutas, metadatos, assets, cobertura de motores y otras propiedades que pueden demostrarse. Eso no elimina la revisión humana; la hace más valiosa. Si el sistema comprueba que todas las páginas tienen lo básico, la atención humana puede concentrarse en preguntas más difíciles: si la dificultad se siente bien, si el onboarding enseña, si un tablero respira o si una categoría realmente ayuda a elegir.
La cantidad dejó de ser un argumento suficiente
Superar setenta juegos fue una señal de capacidad técnica y exploración, pero también una advertencia. Un catálogo amplio impresiona una vez. Lo que hace volver a una persona es encontrar algo que le interese, entenderlo rápido, jugar sin fricción y descubrir una segunda experiencia que también merezca tiempo. El número abre la puerta; la profundidad decide si alguien se queda.
Por eso aquella fase fue menos un hito de “tenemos muchos” que un cambio de pregunta. Dejamos de preguntarnos cuánto podíamos añadir y empezamos a preguntarnos qué sistema necesitábamos para que cada incorporación futura fuese más fácil de descubrir, más coherente y más fiable que la anterior.
Lo que aquel rediseño dejó como legado
Visto desde Blupoli Puzzles, varias decisiones actuales tienen raíces en ese momento: la separación entre shell y motor, una taxonomía más rica, metadatos centralizados, estados explícitos de disponibilidad, UI compartida, temas, mayor atención a onboarding y una disciplina de calidad que intenta demostrar propiedades antes de publicar.
No todas las decisiones nacieron completamente formadas y algunas han cambiado de implementación. Eso es normal. El valor de una fase de crecimiento no está en acertar para siempre, sino en hacer visibles los problemas que antes no existían. Un catálogo grande nos obligó a ver el producto como sistema.
El juego 72 debía ser más fácil de integrar y mejor de usar que el 12
Esa se convirtió en una medida de madurez mucho más interesante que cualquier contador. Si cada juego nuevo necesita más excepciones, más CSS especial y más conocimiento tribal, la plataforma se está degradando aunque el catálogo crezca. Si, por el contrario, una incorporación puede heredar navegación, estados, accesibilidad, persistencia y estructura editorial, entonces el sistema está acumulando capacidad.
El objetivo no es eliminar todo trabajo específico. Cada mecánica merece atención propia. La victoria está en reservar ese esfuerzo para aquello que hace especial al puzzle, no para reconstruir botones, rutas, temas o metadatos. Esa diferencia es la que convierte una colección de implementaciones en una plataforma.
Crecer bien es hacer que el siguiente paso cueste menos, no más
La lección de septiembre de 2026 no fue que exista un número mágico a partir del cual una colección se transforma. El umbral depende del producto. En nuestro caso, más de setenta juegos hicieron imposible ignorar fricciones que ya se estaban acumulando. La escala actuó como una lupa.
Desde entonces seguimos usando esa idea como criterio. Una buena mejora local debería intentar dejar una capacidad reutilizable. Un nuevo juego debería aprovechar el trabajo anterior. Una nueva categoría debería hacer el catálogo más comprensible. Una nueva traducción debería apoyarse en una arquitectura que no duplique la lógica. Y una nueva pieza editorial debería enlazar el conocimiento existente en lugar de empezar desde cero.
Descubrimiento significa reducir el coste de una decisión
Hay otra forma de observar el problema que nos ayudó a ordenar prioridades: cada elemento nuevo aumenta el coste de elegir. Cuando solo existen unas pocas opciones, ese coste es pequeño y puede asumirse con scroll. Cuando las opciones se multiplican, el producto debe devolver al usuario parte del tiempo que le está pidiendo. Filtros, categorías, señales visuales, historial y recomendaciones no son adornos de una biblioteca grande; son mecanismos para que la abundancia no se convierta en parálisis.
Esto también cambia qué significa una buena portada. Ya no tiene que demostrar exhaustividad enseñándolo todo. Puede mostrar caminos. Una sección puede sugerir juegos de una familia, otra recuperar partidas, otra destacar algo nuevo y otra permitir explorar el catálogo completo. El home deja de ser el lugar donde cabe el inventario y pasa a ser el lugar donde empiezan las decisiones.
La coherencia necesita límites explícitos
Durante aquella etapa aprendimos también que “hacerlo consistente” es una instrucción demasiado vaga. La coherencia solo se puede construir cuando sabemos qué debe ser común y qué debe seguir siendo local. La navegación, el lenguaje de acciones, el tratamiento de errores, los estados de disponibilidad, los patrones de foco y la organización alrededor del tablero son buenos candidatos a sistema. La geometría, las pistas, los gestos esenciales y la representación lógica pertenecen al juego.
Definir esa frontera evita dos clases de deuda. Por un lado reduce la duplicación, porque lo común tiene un hogar compartido. Por otro evita abstracciones forzadas, porque un motor no tiene que deformarse para encajar en una interfaz pensada para otro. La plataforma madura no es la que tiene menos diferencias, sino la que sabe por qué existen y dónde deben vivir.
Del contador al sistema
Si tuviéramos que resumir aquella etapa en una sola transición sería esta: dejamos de mirar el catálogo como un contador y empezamos a mirarlo como una red de decisiones. Cada juego tiene reglas, pero también una posición dentro de la navegación, una relación con categorías, una experiencia visual, una historia de calidad y un conjunto de caminos hacia otros juegos.
Eso es lo que una plataforma añade sobre una colección. No solo más elementos, sino contexto entre ellos. El crecimiento de Blupoli hizo visible el problema; Blupoli Puzzles heredó la solución como una responsabilidad permanente. Seguir creciendo solo tiene sentido si el producto se vuelve más fácil de entender a medida que se hace más amplio.