Escalar sin multiplicar mantenimiento
Hay una fase especialmente satisfactoria al construir una plataforma de juegos: cada nueva incorporación cambia el catálogo de manera evidente. Un Sudoku deja de estar solo, después aparece un Nonogram, luego Kakuro, Slitherlink y otras familias. El contador crece y parece que el producto mejora al mismo ritmo. Durante la primera etapa de lo que entonces llamábamos Blupoli, esa expansión fue deliberada. Necesitábamos variedad suficiente para descubrir qué problemas eran realmente comunes y cuáles pertenecían a un solo puzzle.
Pero el crecimiento cambia de naturaleza. Cuando existen decenas de experiencias, la pregunta ya no es «¿podemos añadir otro juego?». La pregunta es «¿podemos mantener todos estos juegos, mejorarlos de forma consistente y ayudar a una persona a elegir entre ellos?». En ese momento el catálogo deja de ser el resultado de la arquitectura y empieza a presionarla. Blupoli Puzzles existe hoy sobre varias decisiones que aparecieron precisamente cuando la cantidad dejó de ser una meta y se convirtió en una prueba de estrés.
La cobertura inicial era una forma de aprender, no el objetivo final
Si hubiéramos intentado diseñar una arquitectura universal antes de construir variedad, habríamos tenido que imaginar problemas que todavía no conocíamos. Crear puzzles de familias distintas nos dio evidencia mucho mejor. Los clásicos de cuadrícula, los juegos de sombreado, los de caminos, las variantes de Sudoku o la lógica deductiva no piden exactamente las mismas interacciones. Cada incorporación enseñaba qué parte del marco podía compartirse y qué parte necesitaba libertad.
Esa etapa tenía valor aunque algunas implementaciones fueran más sencillas que las que querríamos conservar a largo plazo. El catálogo funcionó como un conjunto de experimentos. Nos permitió descubrir patrones de navegación, controles repetidos, necesidades de accesibilidad, diferencias de generación y límites de diseño. La lección fue que ampliar cobertura tiene sentido si se utiliza para aprender qué sistema necesita el producto. Deja de tener sentido cuando el número se convierte en una excusa para no profundizar.
Los pequeños defectos se multiplican más rápido que los juegos
Con tres páginas, mover un control a mano parece barato. Con treinta, la misma decisión empieza a costar. Con más, el problema no es solo el tiempo: aparecen versiones ligeramente distintas de lo mismo. Un botón cambia de posición, una ayuda usa otra palabra, una victoria se comunica de manera diferente o una pantalla móvil conserva un patrón antiguo que las nuevas ya abandonaron. La escala convierte las inconsistencias pequeñas en un problema de producto y mantenimiento.
La consecuencia positiva es simétrica. Una buena abstracción también se multiplica. Si el sistema de controles comunes mejora, varios juegos pueden beneficiarse. Si corregimos un problema de foco en una pieza compartida, la accesibilidad sube en más de una experiencia. Esa capacidad de propagar calidad es una de las razones por las que separar motores y plataforma se volvió tan importante. A cierta escala, la arquitectura decide cuánto cuesta elevar el estándar.
El catálogo se convierte en una interfaz propia
Una colección pequeña puede presentarse como una lista. Cuando las opciones crecen, esa lista empieza a exigir trabajo cognitivo. El visitante necesita entender qué diferencia un puzzle de otro, cuál puede gustarle si disfruta de determinado tipo de razonamiento y dónde encontrar algo familiar sin conocer todos los nombres. El problema ya no es mostrar tarjetas; es diseñar descubrimiento.
Las categorías adquieren entonces una función real. No deberían ser cajones administrativos, sino señales que reduzcan la carga de elección. Agrupar por mecánica, tipo de razonamiento o familia puede permitir que una persona navegue desde lo conocido hacia algo nuevo. La guía sobre categorías cognitivas de puzzles nace de esa misma necesidad: explicar relaciones que un listado alfabético no revela.
Más variedad obliga a separar reglas de producto
Cuando todos los juegos se parecen, es fácil introducir accidentalmente reglas de un puzzle en componentes que deberían ser genéricos. La variedad rompe esa ilusión. Un tablero con pistas exteriores, otro basado en conexiones y otro que ni siquiera usa una cuadrícula tradicional hacen evidente que la capa común no puede dictar la semántica interna de todos. Debe ofrecer un hogar, no una camisa de fuerza.
Ese aprendizaje fue clave para definir motores con responsabilidades propias y una plataforma que resuelve navegación, integración, temas, controles globales y otros comportamientos repetidos. La arquitectura no pretende que cada puzzle tenga la misma forma; pretende que cada puzzle pueda expresar su forma sin reconstruir toda la aplicación. Cuantos más casos aparecen, más importante es que las fronteras se basen en responsabilidades y no en la geometría del primer juego.
La definición de «terminado» se vuelve mucho más exigente
En una prueba inicial, un juego puede parecer acabado cuando acepta acciones y detecta una solución. En un catálogo grande eso ya no basta. Tiene que arrancar desde su ficha correcta, explicar sus reglas, responder bien a teclado y tacto, adaptarse al espacio disponible, gestionar reinicio y estados, presentar feedback comprensible y convivir con las expectativas creadas por los demás juegos. El producto completo se convierte en parte de la definición de terminado.
La escala hace visibles también las ausencias. Si diez juegos ofrecen una interacción y el undécimo no, la excepción se nota más. Eso no significa que todos deban tener exactamente las mismas funciones, pero sí que las diferencias necesitan una razón. La consistencia útil no es uniformidad. Es la garantía de que aquello que pertenece a Blupoli Puzzles se comporta de forma predecible mientras cada puzzle conserva las peculiaridades que hacen interesante su lógica.
Paridad no significa copiar implementaciones
Durante el crecimiento aparecieron también aprendizajes procedentes de otras superficies, especialmente de trabajo previo en Android. Reutilizar ese conocimiento no significa trasladar cada detalle técnico. Un producto web y una aplicación nativa tienen restricciones diferentes. Lo que sí puede viajar son reglas de juego, decisiones de UX que han demostrado ser útiles, modelos mentales y errores que ya no necesitamos repetir.
Esta distinción es importante porque una estrategia de paridad literal crea dos plataformas que intentan imitarse a nivel de implementación. Preferimos paridad de experiencia y comportamiento cuando tiene sentido, con arquitectura apropiada para cada entorno. Esa filosofía es compatible con una posible envoltura móvil de la web, pero no depende de ella. El activo principal no es una base de código idéntica; es un conocimiento de producto suficientemente explícito para aplicarse en más de una superficie.
Los tamaños y dificultades necesitan una gramática común
A medida que aparecen más juegos, palabras como «fácil», «difícil» o «grande» empiezan a significar cosas distintas. En algunos puzzles el tamaño altera de manera directa el espacio de búsqueda. En otros, un tablero pequeño puede contener una deducción mucho más compleja que uno grande. Si la plataforma usa las mismas etiquetas sin criterio, crea una falsa sensación de comparabilidad.
Necesitamos una gramática común, no una fórmula universal. Cada familia puede medir señales distintas, pero la etiqueta debería corresponder a una diferencia real y perceptible. La dificultad puede depender de técnicas necesarias, número de decisiones, branching, densidad de pistas, longitud del razonamiento o estructura espacial. Lo importante es que «difícil» no sea una decoración. Debe representar una experiencia distinta de «fácil» y hacerlo de forma suficientemente estable para que el jugador aprenda qué esperar.
El caso peligroso no es inválido: es válido pero aburrido
Los errores obvios suelen ser fáciles de priorizar. Un puzzle que no carga, una regla rota o una solución imposible se detectan. Más difícil es el caso que técnicamente funciona y, sin embargo, no merece el tiempo de quien juega. Un generador puede crear partidas resolubles pero triviales, repetir patrones o subir el tamaño sin aumentar el razonamiento. La escala del catálogo hace que estos problemas de profundidad pesen más que la ausencia de un nombre adicional.
Numberlink fue uno de los ejemplos tempranos que nos hizo mirar este problema de frente: una partida puede ser correcta y ofrecer caminos demasiado evidentes. El resultado cambia nuestra definición de calidad. Para considerar madura una experiencia necesitamos pensar en corrección, variedad, unicidad cuando corresponda, dificultad, tiempos de generación y sensación de progreso. La entrada sobre generación y resolución profundiza precisamente en esa separación.
Un catálogo grande necesita una política de calidad, no solo tests
Los tests verifican propiedades concretas; una política de calidad conecta varias capas. Podemos imaginar cuatro preguntas. Primera: ¿las reglas funcionan? Segunda: ¿las partidas que producimos tienen suficiente calidad? Tercera: ¿la experiencia de uso es coherente y accesible? Cuarta: ¿el juego está bien situado dentro del producto, con descripción, categoría, ayuda y enlaces correctos? Un juego puede superar una capa y fallar la siguiente.
Este modelo evita que una implementación «verde» en CI se confunda con un producto acabado. Las comprobaciones automáticas son esenciales, pero no pueden decidir por sí solas si un puzzle es aburrido o si una explicación es confusa. La política de calidad combina evidencia técnica con revisión de experiencia. En una biblioteca pequeña se puede hacer de manera informal; en una grande conviene convertirla en una lista explícita que cada nueva incorporación debe atravesar.
El espacio de pantalla deja de ser una decisión editorial
Una web que empieza como contenido puede adoptar una anchura cómoda para lectura y reutilizarla en todas partes. Los puzzles ponen a prueba esa decisión. Algunos tableros necesitan superficie. Otros combinan pistas laterales, controles o información contextual que no caben bien en una columna estrecha. Forzar todas las experiencias dentro del mismo ancho no crea coherencia; puede deteriorar la jugabilidad.
Revisar el layout para dar más espacio a las pantallas de juego parece una modificación visual, pero expresa una regla de arquitectura: la plataforma debe adaptarse a las necesidades del contenido interactivo que aloja. El marco común marca límites y comportamiento responsive, pero no puede asumir que una página de juego es un artículo con una cuadrícula insertada. La escala nos obligó a reconocer esa diferencia y a tratar el tablero como superficie principal.
Compartir componentes solo después de encontrar el patrón real
Cuando se construye el segundo juego aparece una tentación: abstraer enseguida todo lo que se repitió dos veces. Cuando se construyen decenas descubrimos que algunas de esas repeticiones eran casuales. Dos puzzles pueden compartir un botón pero necesitar estados completamente distintos. Tres pueden usar cuadrícula y el cuarto romper todas las suposiciones. Generalizar demasiado pronto crea componentes que parecen reutilizables hasta que empiezan a llenarse de excepciones.
La escala nos dio la evidencia necesaria para extraer piezas con más confianza. Acciones comunes, estructura de página, ayudas, estados generales o patrones de onboarding pueden compartir lenguaje cuando la responsabilidad es realmente la misma. Los tableros y las interacciones específicas conservan libertad. El resultado no es una librería de componentes gigantesca, sino un conjunto de piezas con contratos más pequeños y menos conocimiento de los juegos concretos.
La consistencia se convierte en una herramienta de mantenimiento
Cuando un jugador aprende dónde reiniciar, cómo volver al catálogo o qué significa un estado seleccionado, no debería reaprenderlo arbitrariamente en cada puzzle. Esa coherencia reduce fricción. Pero también reduce coste interno. Si el mismo patrón tiene una implementación compartida, cambiarlo requiere menos trabajo y produce menos divergencia. La UX y la ingeniería se benefician de la misma decisión.
Esto es importante porque las plataformas envejecen. No queremos que los primeros juegos queden congelados en la calidad de la semana en la que se crearon. Una mejora descubierta más tarde debería poder propagarse hacia atrás cuando pertenece a una capa común. Cuanto más grande es el catálogo, más valiosa resulta esa capacidad. Mantener decenas de experiencias no es solo evitar que se rompan; es poder subir su estándar sin rehacerlas una por una.
Descubrir importa tanto como construir
Un juego excelente que nadie encuentra aporta poco al catálogo. Con pocas opciones, el visitante puede recorrerlas todas. Con decenas, la arquitectura de información determina qué existe para cada persona. Familias, filtros, recomendaciones editoriales, búsquedas y rutas relacionadas convierten una colección estática en un sistema de descubrimiento. Esa capa no vive dentro de los motores, pero afecta directamente al valor que pueden aportar.
El Blog forma parte de esta solución porque puede explicar conexiones que no caben en una tarjeta. Una persona que disfruta de Sudoku puede descubrir otros puzzles de deducción; alguien que prefiere patrones visuales puede encontrar Nonogram o juegos de sombreado. El contenido editorial no sustituye una buena navegación, pero añade una segunda forma de recorrer el catálogo: por curiosidad, habilidad o tipo de razonamiento, no solo por nombre.
El rendimiento cambia de perfil cuando se multiplican las experiencias
Una página pesada es un problema local. Un patrón pesado repetido en muchas páginas se convierte en una característica de la plataforma. A escala, importan los costes compartidos: bundles, assets, inicialización, lógica de generación, listeners, fuentes y cualquier dependencia cargada por defecto. La arquitectura debe evitar que cada juego arrastre todo lo que los demás podrían necesitar.
Esto favorece cargar capacidades cuando hacen falta, mantener motores relativamente aislados y revisar qué componentes globales merecen estar presentes siempre. También afecta a la generación. Un algoritmo más exigente puede ser perfectamente válido si corre fuera del camino crítico o tiene un presupuesto claro; puede ser inaceptable si bloquea la interacción en cada nueva partida. Rendimiento y diseño de producto vuelven a encontrarse.
La localización multiplica otra dimensión del catálogo
Decenas de juegos en un idioma ya crean superficie de mantenimiento. Añadir idiomas multiplica títulos, descripciones, instrucciones y rutas que deben permanecer coherentes. Una frase que en un prototipo estaba escrita directamente junto a un botón deja de ser un detalle cuando el mismo patrón aparece en muchas experiencias y varios locales. El crecimiento fuerza a separar también contenido de lógica.
La internacionalización posterior confirmó una lección aprendida con los motores: las fuentes de verdad importan. Si un nombre vive en tres archivos y una descripción en dos plantillas, las traducciones divergen. Cuando catálogo, interfaz y editorial tienen contratos claros, es posible validar cobertura y detectar ausencias. La escala no se resuelve recordando mejor; se resuelve reduciendo los lugares donde una misma decisión puede contradecirse.
La IA acelera la expansión, pero también la deuda
Los agentes de IA hacen posible producir implementaciones, variantes y contenido con mucha más rapidez. Eso aumenta la importancia de la estructura. Una mala convención puede replicarse en decenas de archivos antes de que alguien note el patrón. Del mismo modo, una buena fuente de verdad y un buen gate permiten que muchas tareas sigan la misma norma sin depender de recordatorios manuales.
En cómo usamos IA como parte del flujo de desarrollo explicamos por qué la evidencia y el contexto son esenciales. El catálogo es un ejemplo perfecto: velocidad sin criterios de aceptación produce más superficie, no necesariamente más producto. La capacidad de generar debe ir acompañada de la capacidad de revisar, consolidar y, cuando sea necesario, eliminar trabajo que no alcanza el estándar.
Llegar a decenas cambia la prioridad: de cobertura a profundidad
La versión original de esta historia se escribió cuando el proyecto celebraba haber alcanzado una cobertura amplia y ya hablaba de más de setenta opciones. Esa cifra tenía valor porque mostraba que el experimento de arquitectura había atravesado muchas familias. Pero también marcaba un cambio de fase. Seguir sumando nombres ya no producía el mismo aprendizaje ni el mismo valor que dedicar tiempo a mejorar lo existente.
La prioridad empezó a moverse hacia profundidad: revisar generadores, aclarar ayudas, mejorar responsive, consolidar controles, ordenar categorías, medir dificultades y auditar experiencias completas. Es un trabajo menos visible que publicar diez tarjetas nuevas, pero afecta a muchas más sesiones de juego. El crecimiento del catálogo nos enseñó que la escala real no se mide solo por cuántas cosas soporta el sistema, sino por cuántas puede mantener bien.
La arquitectura madura cuando permite corregir el pasado
Una plataforma no debería obligarnos a aceptar para siempre las decisiones de sus primeras semanas. Si la arquitectura es demasiado rígida, cada mejora global exige una migración enorme. Si es demasiado difusa, no existe un lugar común donde aplicar la mejora. El punto útil está en contratos suficientemente estables para compartir capacidades y suficientemente pequeños para poder evolucionarlos.
Esta propiedad es una de las razones por las que seguimos refactorizando. No buscamos una estructura definitiva; buscamos una que haga posible revisar una suposición sin derribar todo el catálogo. Los juegos nuevos ponen a prueba los límites y los antiguos verifican si una mejora puede propagarse. La plataforma madura cuando ambos movimientos —añadir y corregir— son razonablemente baratos.
Una biblioteca fuerte hace que cada nueva incorporación tenga más valor
Al principio, el valor marginal de un juego viene casi por completo de ese juego. En una plataforma madura, también depende del entorno. Una nueva incorporación puede beneficiarse de navegación, controles, accesibilidad, categorías, documentación, localización y contenido editorial que ya existen. Y, a su vez, puede enriquecer una familia o abrir una ruta de descubrimiento hacia otros puzzles. El conjunto empieza a producir efectos que una lista de páginas independientes no tiene.
Ese es el cambio más importante entre «muchos juegos» y «una plataforma de juegos». No se trata de una cifra concreta. Se trata de que el sistema haga mejores a las piezas y de que las piezas aporten información para mejorar el sistema. Blupoli Puzzles sigue trabajando en ese equilibrio. El catálogo es más grande que el primer Sudoku, pero la pregunta sigue siendo la misma: ¿qué debemos aprender de este juego para que el siguiente y los anteriores funcionen mejor?
Escalar significa mantener la capacidad de elegir bien
La paradoja de crecer es que aparecen más posibilidades y, al mismo tiempo, se vuelve más importante saber decir que no. No toda abstracción merece convertirse en compartida, no todo puzzle merece publicarse en cuanto funciona y no toda variante aporta suficiente diferencia. El sistema necesita criterios para rechazar complejidad igual que un generador necesita criterios para rechazar candidatos.
Por eso el siguiente capítulo de Blupoli Puzzles no consiste en llenar indefinidamente una estantería. Consiste en hacer que cada parte tenga contexto, calidad y una razón para estar ahí. La etapa de expansión nos dio el mapa del problema. La etapa de plataforma consiste en usar ese mapa para reducir fricción, elevar profundidad y conseguir que una colección diversa se sienta como un producto coherente sin borrar aquello que hace especial a cada puzzle.