Compartir experiencia sin borrar personalidad
La primera versión de una plataforma suele crecer por acumulación: cada pantalla resuelve su problema y el producto avanza. Esa libertad es útil al principio, pero con un catálogo grande empieza a sentirse como si cada juego perteneciera a una aplicación diferente.
Nuestro objetivo no es eliminar las diferencias. Es decidir cuáles son valiosas. Un Nonogram necesita pistas en sus bordes; Sudoku candidatos; Logic Grid matrices; LITS regiones y sombreado. Nada de eso debería homogeneizarse. En cambio, no hay una buena razón para que cada juego invente su propia jerarquía de página, ayuda o estado de victoria.
La consistencia no significa uniformidad
Una interfaz coherente reduce aprendizaje. Una interfaz uniforme puede borrar información. La diferencia está en compartir las expectativas de producto sin imponer la misma representación a mecánicas diferentes.
Queremos que una persona sepa dónde empezar otra partida, dónde encontrar ayuda y cómo interpretar un estado global. No necesitamos que todas las casillas tengan el mismo aspecto ni que todos los juegos usen los mismos controles.
La meta es aprender PuzzleHub una vez y aprender después solo aquello que hace especial a cada puzzle.
El game shell como contrato visual
Estamos consolidando una carcasa que organiza título, información, configuración, tablero, acciones y contenido explicativo. El shell establece la jerarquía y deja un espacio explícito para que el motor controle la interacción específica.
Esta frontera tiene una ventaja técnica importante: podemos evolucionar navegación o responsive sin entrar en la lógica del puzzle. Y un motor nuevo puede obtener una experiencia razonablemente completa antes de tener personalizaciones avanzadas.
Un sistema necesita estados, no solo componentes
Crear un botón reutilizable es la parte fácil. Lo importante es definir qué ocurre cuando está deshabilitado, cuándo una acción está activa, cómo se comunica un error, qué aspecto tiene una selección y qué feedback recibe el jugador al completar algo.
Los estados son donde las inconsistencias suelen esconderse. También son donde más se nota un sistema maduro: el usuario no tiene que interpretar de nuevo el lenguaje de la aplicación en cada página.
Colores por categoría
La taxonomía empieza a participar en la identidad visual. Un color de categoría puede conectar tarjeta, encabezado y experiencia de juego. No queremos colorear por decorar: queremos que el catálogo tenga memoria visual.
Ese sistema debe funcionar sin depender solo del color. Iconos, texto, jerarquía y contraste siguen siendo necesarios para accesibilidad y para que los estados del juego no compitan con el color de marca.
Modo claro como prueba de arquitectura
Añadir un segundo tema ha servido para detectar estilos acoplados y valores hardcodeados. Cuando un componente solo funciona sobre un fondo oscuro concreto, todavía no es un componente de sistema.
Variables de tema y estados comunes convierten decisiones implícitas en reglas explícitas. El resultado no es únicamente «también tenemos modo claro»; es una base más fácil de cambiar en el futuro.
- funcionar en tema claro y oscuro;
- adaptarse a móvil y escritorio;
- tener estados de foco, activo y deshabilitado;
- permitir variaciones legítimas sin duplicarse;
- no conocer detalles internos del motor del puzzle.
Onboarding sin escribir setenta interfaces
Algunos juegos merecen tutoriales específicos y visuales. Para el resto necesitamos una base capaz de presentar objetivo, reglas esenciales e interacción a partir de contenido estructurado.
Eso eleva el mínimo de calidad sin bloquear el desarrollo hasta crear una experiencia artesanal para cada título. Más adelante podemos enriquecer los juegos donde un tutorial interactivo aporte valor real.
Más espacio para jugar
También hemos ampliado el ancho general de la web, especialmente en pantallas de juego. El tablero no puede ser un elemento secundario atrapado dentro de un contenedor pensado para lectura. La interfaz común tiene que adaptarse al contenido principal, y aquí el contenido principal casi siempre es interactivo.
La anchura no significa llenar todo el monitor. Significa disponer de un marco flexible: contenido editorial legible y tableros con el espacio que necesitan.
Extraer después de aprender
Sudoku ha funcionado como laboratorio precisamente para evitar abstraer a ciegas. Primero resolvemos bien una experiencia. Después identificamos qué piezas aparecen también en otros juegos. Solo entonces las convertimos en componentes o patrones.
Este orden importa. Si diseñáramos un sistema completo antes de conocer las necesidades de LITS, Logic Grid o Numberlink, probablemente acabaríamos luchando contra nuestras propias abstracciones.
La deuda visual también se automatiza
Con decenas de páginas, cualquier estilo duplicado puede sobrevivir durante meses. Por eso el sistema de UI y el sistema de build están conectados: cuanto más pueda venir de componentes, plantillas y tokens compartidos, menos posibilidades hay de que una mejora se aplique a 68 juegos y deje tres atrás.
El sistema todavía está creciendo
Estados de victoria, errores, dificultad, estadísticas, diálogos, accesibilidad y nuevas necesidades móviles siguen siendo candidatos. No necesitamos decidir hoy la forma final de todos ellos.
La ventaja es acumulativa. Cada pieza común que madura eleva muchas experiencias a la vez; cada puzzle nuevo pone a prueba el sistema y revela dónde era demasiado rígido. Esa conversación entre plataforma y juegos es precisamente lo que queremos conservar.
Si al final todos los tableros parecen distintos pero todos se sienten inequívocamente parte de PuzzleHub, el sistema habrá hecho su trabajo.