Hay una fase muy agradecida al empezar una plataforma de juegos: cada nuevo puzzle aumenta el catálogo de forma visible. Cinco pasan a diez, diez a veinte y el producto parece crecer a la misma velocidad que el contador.
Después ocurre algo menos espectacular y mucho más importante. El número deja de ser el problema. Empiezan a pesar las diferencias de calidad, los controles inconsistentes, los juegos difíciles de descubrir, las páginas incompletas y los motores que técnicamente funcionan pero todavía no producen partidas interesantes.
La cobertura inicial era necesaria
El catálogo creció hasta cubrir muchas familias: clásicos como Sudoku, Nonogram, Kakuro y Minesweeper; caminos como Numberlink y Slitherlink; sombreado como LITS o Norinori; variantes de Sudoku; lógica deductiva y otros formatos con necesidades propias.
No queríamos elegir la arquitectura perfecta antes de conocer el problema. Construir muchos juegos nos dio datos mucho mejores: qué controles se repiten, qué excepciones son legítimas, qué generadores requieren solver y qué páginas necesitan más espacio que otras.
Setenta juegos hacen visibles los pequeños errores
Con cinco páginas, mover un botón a mano cuesta minutos. Con decenas, la misma decisión puede convertirse en horas y, peor aún, dejar versiones distintas conviviendo. Lo mismo ocurre con textos de ayuda, selectores de dificultad, estilos de victoria o comportamiento responsive.
La escala amplifica tanto lo bueno como lo malo. Un componente reutilizable excelente mejora el catálogo entero. Una mala convención repetida setenta veces se convierte en deuda técnica instantánea.
Cuando el catálogo crece, la consistencia deja de ser una cuestión estética y pasa a ser una herramienta de mantenimiento.
El catálogo también es una interfaz
Otro aprendizaje fue que una colección grande no se puede presentar como una lista infinita de tarjetas. Cuantas más opciones ofrecemos, más trabajo necesita el usuario para entender qué le apetece jugar.
Las categorías empiezan a tener una función real: no solo ordenar por nombres, sino explicar qué tipo de pensamiento propone cada familia, qué mecánicas aparecen y qué juego puede encajar con el momento del usuario. El rediseño del Home nace de esa necesidad.
Paridad no significa copiar
También empezamos a trasladar ideas y juegos ya explorados en Android. Math Crossword y Waypoint son ejemplos de esa convergencia. La web no pretende reproducir la implementación técnica de otra aplicación; sí puede reutilizar reglas, aprendizajes de producto y decisiones que ya han demostrado ser útiles.
Ese principio será aún más importante si PuzzleHub vuelve a Android mediante una capa como Capacitor: cuanto más sólido sea el producto web, más valor podremos reutilizar sin mantener dos plataformas divergentes desde el primer día.
Tamaños y dificultades necesitan un lenguaje común
Con Colors introdujimos una referencia más sistemática: varios tamaños y varios niveles de dificultad cuando la naturaleza del puzzle lo permite. No todos los juegos pueden encajar exactamente en la misma matriz, y fingir lo contrario sería perjudicial.
Lo que sí necesitamos es una expectativa común. «Difícil» debería significar que existe una diferencia medible y perceptible respecto a «fácil», no que hemos cambiado una etiqueta o aumentado arbitrariamente el tablero.
El caso que más nos preocupa: válido pero aburrido
La cantidad deja de impresionar en cuanto las partidas son triviales. Numberlink nos lo recordó con claridad: un generador puede producir tableros válidos y aun así ofrecer caminos obvios incluso en las dificultades altas.
Eso cambia la definición de «terminado». No basta con poder empezar y acabar una partida. Hay que evaluar solución única cuando corresponda, complejidad, variedad, tiempos de generación, comportamiento en tamaños distintos y sensación real de progreso entre niveles.
- Corrección: reglas, solución y estados funcionan.
- Calidad: las partidas son variadas y la dificultad tiene sentido.
- Experiencia: controles, ayuda, feedback y responsive están cuidados.
- Producto: se descubre, se explica y encaja con el resto de PuzzleHub.
Más ancho también era una decisión de juego
La escala nos obligó a revisar incluso la anchura global de la web. Algunos tableros necesitan más superficie útil; limitar todos los juegos a una columna pensada para contenido editorial hacía que ciertas experiencias fueran innecesariamente pequeñas o directamente incómodas.
Ampliar el layout, especialmente en las pantallas de juego, parece un cambio visual. En realidad expresa algo más profundo: la plataforma debe adaptarse a las necesidades de sus puzzles, no obligarlos a vivir dentro de un molde que nació para otra cosa.
Componentes comunes sin uniformidad artificial
Estamos extrayendo piezas reutilizables porque ya tenemos suficiente evidencia para saber cuáles son realmente comunes. Menús, acciones, explicaciones, onboarding, estados de victoria y estructura de página pueden compartir lenguaje. Los tableros y sus interacciones específicas siguen necesitando libertad.
Sudoku está funcionando como uno de los laboratorios para ese sistema. Mejorar primero una experiencia completa nos permite descubrir qué merece convertirse en patrón antes de propagarlo.
El siguiente cuello de botella es la profundidad
La lista grande fue necesaria para entender el alcance. Ahora la prioridad cambia: terminar mejor, auditar, revisar diseño, mejorar rendimiento, fortalecer generación y dar contexto al catálogo. Es menos vistoso que sumar diez nombres en una tarde, pero aumenta mucho más el valor real del producto.
Paradójicamente, llegar a decenas de juegos nos ha hecho pensar menos en el número de juegos. Ahora miramos cuántos están realmente a la altura, cuántas decisiones podemos mejorar una sola vez y cuántos usuarios pueden encontrar el puzzle adecuado sin conocer su nombre de antemano.
Ese es el siguiente PuzzleHub que queremos construir: no una estantería cada vez más larga, sino una plataforma en la que cada nueva incorporación haga más fuerte al conjunto.