Cuando PuzzleHub tenía pocos juegos era tentador pensar en cada uno como una página independiente: un tablero, unas reglas, algunos botones y listo. Esa idea funciona sorprendentemente bien hasta que el catálogo empieza a crecer. Entonces cada pequeña diferencia se convierte en una decisión que hay que mantener durante años.
El problema interesante dejó de ser «¿cómo implementamos otro puzzle?» y pasó a ser «¿qué parte pertenece realmente al puzzle y qué parte debería resolver PuzzleHub una sola vez?».
Muchos cerebros especializados. Una sola experiencia de producto.
Separar reglas y experiencia
Un Sudoku entiende candidatos, filas, columnas y regiones. LITS necesita reconocer tetrominós y restricciones de sombreado. Kakuro trabaja con sumas y combinaciones. Numberlink piensa en caminos y conectividad. Intentar esconder todas esas diferencias detrás de un «motor universal» produciría una abstracción enorme y poco natural.
Preferimos que cada familia pueda tener un motor especializado y que la capa común se concentre en lo que sí es producto compartido. El motor sabe si un movimiento es válido, cómo generar un tablero o cuándo se ha resuelto. PuzzleHub sabe cómo presentar controles, progreso, mensajes, estadísticas, navegación y contexto.
Compartir plataforma no significa obligar a todos los puzzles a pensar igual.
El contrato importa más que la implementación
La separación solo funciona si existe una frontera clara. A la plataforma no debería importarle si un puzzle se genera con código propio, con un algoritmo especializado o con un motor externo compatible con el proyecto. Sí necesita saber qué puede hacer ese juego: iniciar una partida, reiniciarla, validar, exponer dificultad, guardar estado o comunicar una victoria.
Esto hace posible sustituir una implementación sin reconstruir la página completa. También permite mejorar una pieza transversal —por ejemplo el panel de acciones— y que el beneficio llegue a muchos juegos sin tocar sus reglas.
Metadatos como contrato de catálogo
Nombre, slug, categoría, descripción, estado, capacidades y otras propiedades no deberían vivir duplicados en navegación, tarjetas y páginas. Los metadatos son una pequeña capa, pero cambian la manera de escalar: el catálogo puede construirse a partir de datos y no de docenas de fragmentos copiados.
- qué puzzle es y a qué familia pertenece;
- qué tamaños y dificultades ofrece;
- qué funciones del producto soporta;
- qué motor o implementación utiliza;
- si está listo, en desarrollo o necesita revisión.
Componentes comunes, personalidad propia
La arquitectura visual sigue la misma filosofía. Queremos reutilizar encabezados, selectores, paneles de acciones, modales, ayuda, estados de victoria y patrones responsive. Pero el tablero no debe quedar atrapado en un componente genérico incapaz de expresar las necesidades del juego.
La coherencia correcta está alrededor de la experiencia: sabes dónde cambiar dificultad, dónde pedir ayuda y qué ocurre al terminar. Dentro del tablero, cada puzzle conserva las señales visuales que necesita para ser legible.
El build también es parte del producto
Con unos pocos juegos, editar HTML a mano parece barato. Con decenas, cualquier cambio transversal se convierte en una migración. Los scripts que generan o enriquecen páginas, verifican estructura y aplican convenciones dejan de ser herramientas auxiliares: son parte de la arquitectura.
CI como barrera de calidad
La automatización no sirve únicamente para producir páginas. También debe impedir que la velocidad degrade el conjunto. Un juego puede funcionar aislado y aun así romper enlaces, estilos, estructura o expectativas del catálogo.
Queremos que las comprobaciones automáticas detecten al menos los fallos baratos de detectar automáticamente. Eso deja la revisión humana para lo que realmente requiere criterio: si el tablero se entiende, si una dificultad es divertida, si el onboarding explica lo suficiente o si una animación ayuda en lugar de distraer.
Generadores y solvers son infraestructura
En una plataforma de puzzles la arquitectura no termina en el navegador. Un generador que crea tableros válidos pero triviales es un problema de producto; uno que ocasionalmente produce varias soluciones es además un problema de corrección. Por eso solver, validador, medición de dificultad y presupuesto de generación deben considerarse piezas de primera clase.
Algunas familias pueden compartir técnicas, pero tampoco aquí queremos forzar uniformidad. Lo común es el estándar de calidad: una partida debe poder justificarse, validarse y producirse en un tiempo razonable.
Lo que deliberadamente no estamos abstrayendo
Hay una tentación recurrente en proyectos grandes: diseñar primero un framework perfecto y después intentar encajar el producto. Estamos intentando hacer lo contrario. Una abstracción entra cuando al menos dos o tres problemas reales demuestran que merece existir.
Eso significa aceptar algo de duplicación temporal. Es más fácil extraer un patrón después de verlo repetirse que deshacer una abstracción prematura que condiciona todos los juegos.
Arquitectura para iterar, no para presumir
No buscamos diseñar hoy la arquitectura definitiva. Retos diarios, cuentas, rankings, sincronización o nuevas familias pueden cambiar lo que necesitamos mañana. La meta es que esas capas puedan añadirse sin rehacer las anteriores.
La prueba de una buena arquitectura para PuzzleHub no será cuántos diagramas tenga. Será algo mucho más práctico: que podamos añadir un puzzle extraño sin romper la plataforma y mejorar la plataforma sin reescribir cada puzzle.
Esa es la arquitectura que queremos construir: suficientemente común para multiplicar el trabajo bueno y suficientemente flexible para que cada juego siga siendo un juego de verdad.