Hay una clase de crecimiento que resulta muy satisfactoria mientras ocurre y bastante incómoda cuando se observa con distancia. Añadir juegos al catálogo produce una sensación inmediata de avance: aparece una tarjeta nueva, aumenta la variedad, se amplía una categoría y el proyecto parece multiplicar sus posibilidades. En Blupoli Puzzles atravesamos exactamente esa fase. Pasamos de una colección pequeña a decenas de experiencias distintas en muy poco tiempo. Algunas estaban muy trabajadas. Otras funcionaban como prototipos válidos para explorar una mecánica. Y otras se encontraban en un punto intermedio difícil de explicar: podían abrirse, permitían jugar una partida, pero todavía no reunían todo lo que ahora consideramos imprescindible para llamar a algo «terminado».
El problema no era que hubiéramos experimentado demasiado. Experimentar nos permitió descubrir qué componentes podían compartirse, qué puzzles necesitaban motores propios, cómo organizar categorías, cómo plantear onboarding, persistencia, accesibilidad e internacionalización. El problema era más sutil: estábamos mostrando como producto final cosas que internamente seguíamos tratando como trabajo en curso. Esa diferencia entre «funciona» y «está terminado» se convirtió en una deuda de producto. Y cuanto mayor se hacía el catálogo, más difícil resultaba ver con claridad qué juegos estaban realmente listos y cuáles necesitaban otra ronda de trabajo.
El momento en que el número dejó de ayudarnos
Durante la etapa de expansión era natural hablar del tamaño del catálogo. Cada nueva incorporación servía para medir el ritmo de construcción. Sin embargo, llegó un punto en el que esa cifra dejó de representar lo que queríamos comunicar. Un juego que existe en el repositorio no es necesariamente un juego que deba estar publicado. Un tablero que genera una partida no es necesariamente una experiencia completa. Una implementación que acepta movimientos válidos no es necesariamente una versión que podamos recomendar a alguien que entra por primera vez.
Esta distinción parece obvia después de formularla, pero tiene consecuencias importantes. Si el sitio presenta todos los experimentos como disponibles, el usuario no puede saber cuáles están en una fase madura. Si el número total se convierte en un objetivo, el equipo termina premiando accidentalmente la incorporación de una nueva tarjeta frente a la mejora profunda de una experiencia existente. Y si artículos, páginas de categoría y mensajes de marketing repiten una cifra estática, la propia arquitectura editorial empieza a empujar en la dirección equivocada.
Por eso el cambio reciente no consiste simplemente en ocultar algunos botones. Hemos cambiado la definición pública del catálogo. A partir de ahora, los juegos que todavía no superan el nivel de calidad necesario aparecen como próximamente. Se pueden descubrir, sirven para enseñar hacia dónde crece la colección y mantienen visible la amplitud de ideas que estamos explorando, pero no se presentan como experiencias jugables terminadas. Solo los juegos completados permiten entrar a jugar.
El catálogo ya no pregunta «¿existe este juego?», sino «¿está listo para representar a Blupoli?»
Qué significa realmente «terminado»
Una de las cosas más útiles de esta etapa ha sido convertir una sensación difusa de calidad en una lista de preguntas concretas. Un juego puede tener reglas correctas y seguir sin estar terminado. Puede tener un buen motor y fallar en móvil. Puede verse bien y no guardar una sesión. Puede generar tableros, pero no demostrar que esos tableros tienen una solución válida o una dificultad coherente. Puede estar perfecto en español y dejar cadenas sin traducir en inglés, italiano o francés. Puede ser cómodo con ratón y frustrante con teclado o lector de pantalla.
La auditoría individual intenta mirar el juego como un producto completo. Empezamos por la mecánica: reglas, condiciones de victoria, estados imposibles, reinicio, nueva partida y comportamiento de los controles. Después revisamos la generación: semillas, reproducibilidad cuando corresponde, validez de las partidas, solución única si la familia de puzzle la necesita y presupuestos razonables para no bloquear el navegador. Luego aparece toda la capa de experiencia compartida: persistencia, estadísticas, historial, dificultad, tamaños, onboarding, responsive, teclado, foco, contraste, feedback visual y textos.
El criterio exacto cambia según el juego. Ataxx no necesita las mismas estadísticas que Akari. El Juego del 15 no valida la dificultad de la misma forma que un Sudoku. Aquarium necesita razonar sobre regiones y niveles de agua, mientras que Battleship necesita restricciones de flota. La auditoría no pretende imponer un motor universal. Pretende imponer una expectativa universal: cualquiera que sea la mecánica, la experiencia publicada debe sentirse deliberada.
La oleada de auditorías nos dio una señal bastante clara
Los últimos días fueron una prueba práctica de este enfoque. Juegos como el Juego del 15, Akari, Ataxx, Hidato, Balance Loop, Battleship, Aquarium y Takuzu pasaron por revisiones mucho más exigentes que la comprobación de «abre y se puede jugar». En algunos casos la base era sólida y el trabajo consistió en completar la experiencia alrededor. En otros fue necesario sustituir fallbacks o tableros fijos por motores nativos, añadir generación verificable, ampliar tamaños y dificultades o reconstruir partes de la lógica.
El patrón se repetía. Cuanto más profundamente mirábamos un juego, más claro quedaba que terminarlo bien requería tiempo. No necesariamente semanas para cada uno, pero sí una atención que no podía convivir con la idea de seguir aumentando el catálogo al mismo ritmo. Cada auditoría descubría detalles pequeños que juntos marcan una diferencia enorme: un control que no era evidente, un estado que no persistía, un diseño que se rompía en una anchura concreta, una estadística demasiado genérica, un tutorial que explicaba la mecánica equivocada o una generación que funcionaba pero no ofrecía suficiente garantía.
La conclusión no fue «hemos creado demasiados juegos». La conclusión fue «hemos aprendido lo suficiente como para subir el listón». Esa diferencia importa. No estamos descartando el trabajo anterior. Lo estamos usando como inventario de prototipos, motores y decisiones sobre los que ahora podemos construir una colección mucho más consistente.
Congelar no significa abandonar
Cuando un juego pasa a «próximamente» podría parecer que retrocede. Para nosotros ocurre lo contrario. Antes un prototipo podía permanecer publicado durante meses sin una señal clara de que necesitaba otra revisión. Ahora su estado es explícito. El catálogo reconoce que existe, pero también reconoce que todavía no hemos terminado el trabajo. Eso reduce la presión por fingir madurez y nos permite concentrarnos en un juego cada vez.
También cambia la conversación interna. En lugar de preguntar qué juego podemos añadir después, preguntamos cuál es el siguiente juego incompleto que merece una auditoría. Eso obliga a cerrar ciclos. Si elegimos un puzzle, no basta con arreglar el primer error visible; revisamos el conjunto hasta que alcance el estándar o documentamos con precisión lo que falta. El objetivo no es que una rama se vea activa, sino que el juego pueda volver a la zona jugable con confianza.
Esta forma de trabajar encaja mejor con la experiencia que queremos ofrecer. Una persona que visita Blupoli Puzzles no debería necesitar conocer la historia del repositorio para saber qué está terminado. El estado público debe ser comprensible por sí mismo. «Jugar» significa que lo recomendamos. «Próximamente» significa que forma parte del catálogo planeado, pero todavía no hemos dado esa recomendación.
El contador también tenía que dejar de ser manual
El cambio de estado hizo visible otro problema: habíamos mencionado cifras concretas del catálogo en demasiados lugares. Cuando la plataforma llegó a una determinada cantidad de juegos, ese número apareció en textos de la home, artículos, piezas editoriales y otros puntos. Mientras el catálogo solo crecía, el error parecía pequeño. En cuanto diferenciamos entre juegos publicados y próximos, una cifra fija dejó de tener significado estable.
La solución es convertir esos números en información derivada del estado real. El catálogo ya conoce qué juegos están publicados y cuáles están en preparación. Las superficies que necesiten mostrar una cantidad deben leer esa fuente de verdad en lugar de copiar un literal. Así, publicar un juego nuevo cambia el valor automáticamente y retirar temporalmente otro no obliga a buscar frases antiguas por toda la web.
Esto parece una mejora técnica menor, pero tiene una consecuencia editorial importante: dejamos de construir el relato del proyecto alrededor de una cifra. Podemos hablar de variedad, de familias de puzzles, de nuevas mecánicas o de calidad sin quedar atados a un número que envejece en cuanto se hace el siguiente merge.
Una auditoría no es una checklist ciega
Hemos ido creando reglas comunes porque ayudan a detectar regresiones, pero hay un riesgo en convertir la calidad en una colección de casillas. Un juego puede pasar veinte comprobaciones automáticas y seguir resultando torpe. Puede tener todos los atributos ARIA y conservar un flujo confuso. Puede responder bien en tres breakpoints de prueba y sentirse extraño en una tablet concreta. Puede guardar estadísticas perfectamente y mostrar estadísticas que no aportan nada a esa mecánica.
Por eso distinguimos entre gates y criterio. Los gates evitan que se nos olvide lo básico: assets, rutas, traducciones, cobertura de onboarding, metadatos, contratos de datos y otras invariantes que el código puede comprobar. El criterio empieza después. ¿La primera partida se entiende? ¿La dificultad cambia de una forma perceptible? ¿La acción principal tiene el tamaño correcto? ¿Los estados de error enseñan algo? ¿Reiniciar o deshacer se comporta como espera una persona? ¿El tablero utiliza el espacio disponible sin perder legibilidad?
La auditoría buena combina ambos mundos. Automatizamos lo repetible para reservar atención humana a lo que no puede reducirse a un booleano.
Cada juego pasa por capas distintas; ninguna sustituye a las demás.
Lo que aprendimos de los motores nativos
Otra consecuencia de revisar juegos uno a uno ha sido abandonar la tentación de resolver familias muy distintas con una abstracción demasiado general. Compartimos shell, controles, persistencia y patrones de UI cuando tiene sentido, pero la lógica central suele necesitar conocimiento específico del puzzle. Un solver de matching sirve para Dominosa; exact cover puede ser excelente para ciertos rompecabezas de colocación; Akari necesita razonar sobre iluminación y restricciones; Slant tiene una regla global de ciclos que no desaparece por mucho que queramos reutilizar una API común.
Las auditorías recientes han reforzado una arquitectura donde compartir no significa uniformar. Cada motor puede expresar sus reglas con claridad y demostrar propiedades importantes de sus partidas. Al mismo tiempo, el jugador recibe convenciones coherentes alrededor: botones, estados, tamaños de interacción, persistencia y navegación.
Este equilibrio es uno de los motivos por los que ahora preferimos ir más despacio. Construir un motor específico lleva más trabajo que encajar una mecánica en un componente genérico, pero reduce sorpresas a largo plazo. Y cuando ese motor está bien hecho, se convierte en una base mucho más útil para generar dificultad, reproducir errores y ampliar variantes.
«Próximamente» también mejora el diseño del catálogo
El estado nuevo no solo protege la calidad. También hace el catálogo más honesto y más fácil de explorar. Antes una tarjeta visualmente idéntica podía llevar a un juego pulido o a una experiencia todavía provisional. Ahora la interfaz puede comunicar la diferencia antes del clic. Los juegos disponibles siguen siendo destinos claros; los próximos pueden mostrarse como parte de la hoja de ruta sin crear una falsa expectativa.
Esto abre oportunidades de diseño mejores que ocultarlos por completo. Podemos agrupar próximos lanzamientos, explicar qué familia representan, enlazar artículos que cuentan su desarrollo o utilizar la tarjeta para mostrar que el catálogo continúa creciendo. La clave es que el CTA no prometa jugar cuando todavía no corresponde.
También evita un problema que teníamos con los enlaces editoriales. Un artículo puede hablar de un puzzle que aún estamos terminando, pero ya no debería decir «juega ahora» si el juego está bloqueado. El contenido y el catálogo necesitan compartir el mismo estado. Esa coherencia es parte del trabajo que estamos consolidando.
La calidad incluye lo que pasa después de ganar
Durante los primeros prototipos era fácil concentrarse en el tablero: colocar piezas, marcar celdas, mover fichas, comprobar una solución. Las auditorías están ampliando la mirada a todo el ciclo. ¿Qué ocurre cuando terminas? ¿Se guarda correctamente la partida? ¿Las estadísticas distinguen tamaño y dificultad? ¿Puedes empezar otra sin recargar? ¿El historial tiene sentido? ¿El feedback celebra el resultado sin bloquear la navegación?
En juegos competitivos, el ciclo es distinto. Ataxx necesita representar una partida contra CPU y sus resultados no deberían mezclarse conceptualmente con los tiempos de un puzzle lógico. En juegos de movimientos, el contador importa de una manera distinta que en un puzzle de deducción. En otros casos, el dato relevante puede ser una racha, un porcentaje de acierto o simplemente la finalización.
La palabra «terminado» empieza a significar que hemos pensado también en esas capas. No todo juego necesita todas las funciones, pero cada función que aparece debe tener una razón.
Responsive dejó de ser una prueba al final
Otra lección repetida es que un tablero que se ve bien en escritorio no está casi terminado. Muchos puzzles viven mejor en pantallas pequeñas precisamente porque una partida breve encaja perfectamente en un teléfono o una tablet. Si el tablero, las pistas o los controles se vuelven minúsculos, hemos perdido uno de los contextos principales de uso.
Las auditorías obligan a comprobar el shell y la mecánica juntos. A veces el problema está en el tamaño del tablero; otras, en una barra de acciones que ocupa demasiado; otras, en controles diseñados para hover; otras, en una pista exterior que necesita redistribuirse. Hemos empezado a tratar los breakpoints como decisiones de producto y no como parches CSS al final de una implementación.
La misma lógica se aplica al footer, la navegación y los elementos compartidos de la web. La calidad de un juego no termina en el borde del tablero. Desde que una persona abre su ficha hasta que vuelve al catálogo, la experiencia debería conservar la misma intención.
Accesibilidad y onboarding son parte del motor de publicación
Uno de los cambios más importantes de estas semanas fue dejar de considerar el onboarding como un texto genérico. Setenta mecánicas diferentes no pueden explicarse con el mismo ejemplo. Creamos perfiles reutilizables donde varias familias comparten interacción, pero cada juego necesita una asignación explícita. La integración continua puede detectar si un nuevo juego queda sin cobertura.
La accesibilidad sigue un principio parecido. Hay patrones comunes —foco visible, nombres accesibles, tamaño táctil, contraste—, pero cada tablero necesita decisiones específicas. Un grid editable puede mapearse bien al teclado; una pieza arrastrable quizá necesite una alternativa; un juego de conexiones debe representar estados sin depender únicamente del color. No queremos marcar «accesible» por tener atributos correctos. Queremos que la interacción básica tenga una ruta real para distintas formas de uso.
Esta es otra razón para reducir la velocidad de publicación. Estas capas rara vez aparecen si el objetivo es sumar una mecánica lo antes posible. Sí aparecen cuando el objetivo es cerrar un producto.
Qué hacemos con lo que ya estaba publicado
No intentamos corregir todo el catálogo en una sola operación gigante. Sería difícil de revisar y convertiría cada regresión en un problema de búsqueda. Preferimos una migración incremental: identificar el siguiente juego incompleto, auditarlo, implementar lo necesario, verificarlo y avanzar. Los juegos que ya han pasado por ese proceso conservan su estado publicado. Los que todavía no, pueden quedar anunciados como próximos.
Esta estrategia también nos permite aprender y mejorar la propia auditoría. Lo que descubrimos en Aquarium puede convertirse en una regla que luego ayuda en otro puzzle regional. Lo aprendido con la CPU de Ataxx puede inspirar una plantilla de estadísticas competitivas. Los problemas responsive de un tablero pueden terminar resolviéndose en el shell compartido y beneficiar a decenas de juegos.
El proceso no es una cola rígida. Algunas auditorías revelarán que el trabajo es pequeño; otras exigirán rehacer el motor. La prioridad puede cambiar si encontramos una dependencia compartida. Lo importante es que el estado sea transparente y que no volvamos a confundir presencia en el repositorio con disponibilidad pública.
Menos velocidad visible, más progreso acumulativo
Desde fuera, esta fase puede parecer más lenta. Es probable que durante un tiempo publiquemos menos nombres nuevos. Pero cada juego que sale del proceso deja mejoras reutilizables: mejores componentes, mejores contratos, pruebas más precisas, traducciones organizadas, patrones de accesibilidad, decisiones de datos y herramientas de generación. El siguiente juego empieza desde una base más alta que el anterior.
Eso cambia la naturaleza del progreso. Antes era fácil verlo en la longitud del catálogo. Ahora se ve en la consistencia. Un botón se comporta igual en distintas mecánicas. Una sesión sobrevive a una recarga. Una dificultad tiene una razón algorítmica. Un tutorial enseña el gesto correcto. Un tablero no se rompe al pasar de escritorio a móvil. Una tarjeta no promete un juego que aún no recomendamos.
Este tipo de progreso es menos fotogénico, pero es el que convierte una colección de experimentos en un producto.
Cómo sabremos que un juego puede volver a abrirse
No existe una puntuación única que decida automáticamente la publicación. Sí existe un conjunto de señales. El motor debe respetar las reglas y no producir estados inválidos conocidos. La generación debe ser suficientemente fiable para el tipo de puzzle. Los tamaños y dificultades deben estar respaldados por la implementación real. La sesión debe poder iniciarse, continuar y terminar sin perder datos importantes. La interfaz debe responder correctamente en los tamaños de pantalla que soportamos. El onboarding y los textos deben corresponder a la mecánica. Las comprobaciones automáticas deben pasar.
Después queda una pregunta humana: ¿lo pondríamos delante de alguien sin explicar que «todavía está a medias»? Si la respuesta necesita una excusa, el juego sigue estando en proceso.
Nos gusta esa pregunta porque obliga a pensar en la experiencia completa. También evita que una checklist se convierta en una forma de negociar con problemas evidentes. La calidad no es perfección absoluta; siempre habrá mejoras posibles. Pero sí exige que la versión publicada sea coherente, fiable y defendible como producto actual.
Lo que cambia para quien visita Blupoli Puzzles
El cambio más visible será sencillo: menos juegos con botón de jugar, más tarjetas claramente marcadas como próximas y una colección publicada que crecerá de forma más deliberada. No queremos que esto se interprete como una reducción de ambición. La hoja de ruta sigue siendo amplia. La diferencia es que ahora la ambición incluye terminar bien.
Quien llegue buscando variedad seguirá pudiendo descubrir mecánicas futuras. Quien quiera jugar tendrá una señal mucho más fiable sobre qué experiencias recomendamos hoy. Y cuando un juego cambie de «próximamente» a disponible, ese cambio significará algo concreto: ha pasado por la revisión y consideramos que merece estar dentro de la colección activa.
También iremos contando parte de ese trabajo en este Devlog. No para convertir cada corrección en una noticia, sino para documentar las decisiones que cambian nuestra forma de construir: motores que tuvimos que sustituir, abstracciones que no funcionaron, pruebas que se volvieron contratos y patrones que acabaron beneficiando a muchos juegos.
El siguiente capítulo se escribe uno a uno
La etapa anterior de Blupoli Puzzles fue expansiva. Necesitábamos probar cuánto podíamos compartir, cuántas familias diferentes cabían bajo la misma experiencia y qué arquitectura aparecía al construir muchas mecánicas. Esa etapa cumplió su función. La actual es distinta: convertir esa amplitud en profundidad.
Por eso el nuevo ritmo es deliberadamente simple. Elegimos un juego. Lo auditamos de verdad. Corregimos motor y experiencia. Lo verificamos. Lo publicamos cuando estamos cómodos asociándolo con la marca. Después pasamos al siguiente. Mientras tanto, el catálogo puede enseñar el futuro sin confundirlo con el presente.
No sabemos todavía cuánto tiempo llevará revisar cada pieza, y no sería honesto fingir una cadencia exacta. Lo que sí sabemos es qué queremos optimizar. No el contador de tarjetas. No una cifra en una cabecera. Queremos optimizar la confianza de que, cuando en Blupoli Puzzles aparece el botón «Jugar», detrás hay un juego que hemos decidido terminar.
Si te interesa seguir la parte técnica de este proceso, puedes leer por qué terminar un puzzle es mucho más que hacerlo jugable, la experiencia de llevar Aquarium a un motor y una UX completos o el artículo sobre auditar antes de construir. Y si prefieres ver la colección actual, el catálogo de Blupoli Puzzles ya distingue entre lo que está disponible y lo que todavía estamos preparando.