Durante mucho tiempo, una de las métricas más visibles de PuzzleHub fue el número de juegos. Cada incorporación ampliaba el catálogo y hacía tangible el crecimiento. Pero en cuanto superamos las setenta experiencias, esa misma métrica empezó a engañarnos. Tener un juego en la lista no significa tener un juego terminado.
La diferencia se hizo evidente cuando empezamos a auditar los títulos que todavía conservaban prototipos, integraciones superficiales o versiones demasiado simples. Algunos eran técnicamente jugables, pero no cumplían el estándar que ya estábamos exigiendo a los motores más recientes: generación fiable, solución única cuando corresponde, dificultad útil, persistencia, estadísticas, responsive, teclado, onboarding, accesibilidad e internacionalización.
La respuesta no fue borrar esos juegos ni ocultarlos indefinidamente. Decidimos tratarlos como deuda de producto y completarlos uno a uno. En apenas unos días pasaron por esa revisión el Juego del 15, Akari, Ataxx, Hidato, Balance Loop, Battleship, Aquarium y Takuzu. No todos comparten algoritmo ni interfaz. Lo que sí comparten es una definición de «terminado» mucho más exigente que la que utilizábamos al principio.
La auditoría cambió la pregunta
Antes, al revisar un juego, preguntábamos principalmente si funcionaba. Ahora empezamos por otra pregunta: ¿qué tendría que cumplir para sentirse tan cuidado como los mejores títulos del catálogo?
Eso obliga a mirar más allá del algoritmo. Un puzzle puede resolver correctamente y seguir siendo una mala experiencia si la dificultad es arbitraria, si el tablero se desborda en móvil, si no se puede continuar una partida al volver, si el usuario no entiende la primera jugada o si las estadísticas mezclan variantes incompatibles.
La auditoría completa incluye reglas, generación, interacción, feedback, estados de victoria, accesibilidad, traducciones, integración con el shell común y comportamiento en distintos tamaños. La intención no es convertir todos los juegos en clones visuales. Es asegurar que cada uno respete un contrato de producto compartido.
Un juego no está terminado cuando deja de fallar. Está terminado cuando deja de necesitar excusas.
Juego del 15: un clásico sencillo que castiga la superficialidad
El Juego del 15 parece uno de los títulos más fáciles de implementar. Un tablero 4×4, quince fichas, un hueco y movimientos ortogonales. Precisamente por eso es fácil conformarse con una demo que baraja piezas y cuenta movimientos.
La reconstrucción buscó algo más sólido. Las dificultades tenían que producir estados realmente distintos y, al mismo tiempo, conservar resolubilidad. La interfaz debía responder bien al toque y al teclado. La partida tenía que poder persistirse. El historial debía permitir deshacer sin corromper el estado. Y las estadísticas tenían que medir algo útil: movimientos, resolución y variantes, no simplemente «partidas abiertas».
Este juego nos recordó que la profundidad de un motor no se mide solo por la complejidad matemática. A veces la dificultad está en cerrar todos los bordes de una mecánica conocida.
Akari: cuando la solución única pasa a ser parte del producto
Akari obliga a colocar bombillas en una cuadrícula de forma que todas las celdas queden iluminadas, las bombillas no se vean entre sí y las pistas numéricas alrededor de los muros se respeten. Un generador ingenuo puede producir tableros válidos con múltiples soluciones o dificultades completamente impredecibles.
Por eso la reconstrucción incorporó un solver capaz de contar soluciones, cuatro tamaños, cuatro dificultades y simetrías verificadas. No basta con encontrar una respuesta; necesitamos demostrar que la partida publicada tiene exactamente la estructura que esperamos.
También añadimos persistencia, historial, estadísticas e internacionalización. Akari representa bien una idea que se repite en todo el catálogo: el solver no es una herramienta de desarrollo escondida, sino parte del sistema de control de calidad del producto.
Ataxx: completar un juego competitivo significa construir al rival
Ataxx planteaba un problema distinto. No queríamos mantener juegos de dos jugadores humanos mezclados con los puzzles individuales. La dirección de producto es que esas experiencias sigan siendo de una persona, pero enfrentada al sistema.
Eso convirtió el trabajo de Ataxx en algo mucho mayor que dibujar un tablero 7×7. Había que construir una CPU con cuatro niveles de dificultad, decidir cómo se representa un turno completo, implementar búsqueda alpha-beta, persistir la partida y hacer que deshacer tuviera sentido en un contexto competitivo.
El undo, por ejemplo, no puede comportarse igual que en un puzzle. Si el jugador deshace solo su último movimiento pero deja intacta la respuesta de la CPU, el estado deja de representar una ronda coherente. La solución fue pensar en unidades de interacción, no en operaciones aisladas.
También creamos estadísticas competitivas reutilizables. Ganar, perder, empatar, contar piezas o medir dificultad del rival son conceptos diferentes a «resolver un puzzle». Esa separación prepara a otros juegos contra CPU para compartir infraestructura sin fingir que son Sudokus con otro tablero.
Hidato: reconstruir el generador, no maquillar el tablero
Hidato fue uno de los ejemplos más claros de por qué algunas auditorías terminan en reconstrucción completa. La mecánica pide conectar números consecutivos a través de celdas adyacentes, y el interés depende muchísimo de qué pistas se muestran y de cómo se distribuye la ruta.
En lugar de conservar un motor superficial y añadirle estilos, reconstruimos la generación para producir puzzles únicos, añadimos variantes y conectamos el motor con las estadísticas de forma que pueda reportar detalles de la variante jugada.
También recibió onboarding específico. Un tutorial genérico puede explicar dónde están los botones, pero no enseña por qué una casilla concreta restringe la posición del siguiente número. Para nosotros, el onboarding está dejando de ser una capa cosmética y se está convirtiendo en una parte de la definición de cada juego.
Balance Loop: sustituir un fallback por una mecánica propia
Balance Loop dependía de una integración incompleta y no tenía la autonomía que buscábamos. La reconstrucción lo convirtió en un juego nativo con reglas, metadatos, controles, dificultades, generación con seed, validación y self-tests.
Este tipo de migración tiene dos beneficios. El primero es evidente: controlamos completamente la experiencia. El segundo es arquitectónico: podemos observar qué piezas del shell común sirven de verdad para motores diferentes y cuáles estaban demasiado ligadas a los primeros juegos.
No aspiramos a reescribir cualquier dependencia externa por principio. Hay motores open source excelentes y bien integrados. La regla es otra: cuando una integración impide alcanzar la calidad de producto que necesitamos, la frontera del motor debe revisarse.
Battleship: un puzzle de flota no es un juego de disparos
Battleship puede evocar el juego competitivo clásico, pero la variante de lógica es otra cosa. El jugador deduce la posición de una flota a partir de pistas y restricciones. Eso exige modelar segmentos de barcos, separaciones, recuentos y consistencia global.
La nueva implementación utiliza un motor nativo y generación determinista con solución única. Añadimos cuatro tamaños, cuatro dificultades, controles accesibles, responsive y onboarding localizado.
Lo relevante no es solo que Battleship haya pasado a estar «completo». El trabajo nos obliga a definir qué entendemos por dificultad. Ocultar más pistas puede hacer el tablero más vacío, pero no necesariamente más interesante. La dificultad debe medirse a través del comportamiento del solver y de las deducciones requeridas, no únicamente por una cantidad visual.
Aquarium: conservar una buena base también es una decisión de ingeniería
No todas las auditorías terminan reemplazándolo todo. Aquarium ya tenía un núcleo certificado que merecía conservarse. El trabajo consistió en completar la experiencia alrededor de ese núcleo y corregir puntos concretos de generación.
Añadimos sesiones generadas, persistencia, historial, teclado, responsive, feedback visual, accesibilidad e i18n. Durante las pruebas apareció además un problema de fiabilidad relacionado con el número de regiones y la generación de puzzles únicos. En lugar de taparlo aumentando reintentos indefinidamente, ajustamos la escala de regiones para que el espacio de generación fuera más fiable.
Ese detalle resume bien nuestra filosofía actual. «Generar hasta que funcione» es una estrategia peligrosa porque convierte los fallos de diseño en tiempo de CPU. Preferimos entender por qué una configuración produce demasiados estados ambiguos y modificar el modelo.
Takuzu: del prototipo fijo a un motor reproducible
Takuzu era otro caso clásico de prototipo que había sobrevivido más de la cuenta. Un tablero 6×6 puede demostrar la mecánica, pero no constituye una implementación completa.
La nueva versión genera puzzles con solver y solución única, ofrece cuatro tamaños y cuatro dificultades y se integra con persistencia, estadísticas, accesibilidad, responsive, onboarding e i18n.
Takuzu también sirve para comprobar que la arquitectura soporta variantes sin duplicar el motor. El tamaño cambia la densidad y el espacio de búsqueda; la dificultad cambia qué pistas se retiran y qué deducciones quedan disponibles. Esas dimensiones deben formar parte explícita del estado y de las estadísticas si queremos comparar partidas de forma honesta.
La solución única ya no se negocia cuando la mecánica la exige
Una de las diferencias más importantes entre la primera etapa y la actual es que hemos dejado de tratar la solución única como una mejora opcional. Si un puzzle promete deducción lógica y publica un tablero con varias soluciones, estamos rompiendo el contrato con el jugador.
Por eso casi todos los motores nuevos incluyen una forma de contar soluciones o demostrar unicidad. El método cambia: backtracking, exact cover, matching, búsqueda con poda, restricciones específicas o combinaciones de varias técnicas. Lo común es la evidencia.
La generación se vuelve entonces un pipeline. Crear candidato, resolver, contar, medir, aceptar o descartar. En algunos juegos añadimos simetría; en otros seeds reproducibles; en otros presets verificados. No buscamos un algoritmo universal porque los puzzles no comparten el mismo problema matemático.
Cuatro dificultades no significan cuatro números arbitrarios
También estamos revisando qué significa ofrecer «fácil, medio, difícil y experto». Es tentador mapear dificultad a tamaño: 6×6 fácil, 12×12 difícil. Pero tamaño y dificultad no son lo mismo.
Un tablero grande puede contener deducciones triviales repetidas. Uno pequeño puede exigir una cadena precisa de inferencias. Por eso intentamos que la dificultad se derive de señales del solver o de parámetros que tengan relación con el razonamiento necesario: profundidad, branching, número de pistas, estructura de restricciones, cantidad de estados forzados o distancia a la solución.
No todos los motores tienen todavía una métrica perfecta, pero la auditoría nos está obligando a documentar qué controla realmente cada nivel en lugar de mostrar cuatro etiquetas vacías.
Persistencia e historial cambian la forma de modelar el estado
Añadir «guardar partida» al final casi siempre sale caro. Si el motor no separa correctamente estado inicial, estado actual, movimientos, variante y metadatos, persistir puede terminar serializando demasiadas cosas o no las suficientes.
Las reconstrucciones recientes intentan tratar la persistencia como requisito desde el modelo. Una sesión necesita saber qué puzzle es, cómo reproducirlo, qué ha hecho el usuario y qué datos deben sobrevivir a una recarga.
El historial añade otro nivel. Deshacer no consiste siempre en invertir la última mutación. En Ataxx es una ronda. En un puzzle de colocación puede ser una acción. En juegos con herramientas auxiliares, algunas interacciones no deben contar como movimiento de la misma manera. Estas diferencias son justo la razón por la que compartimos infraestructura sin imponer un modelo único.
Las estadísticas también necesitan contexto
Hasta hace poco era fácil contar partidas y tiempos. Al crecer las variantes, esa información puede ser engañosa. Resolver un Hidato pequeño y uno grande no es equivalente. Ganar a la CPU fácil de Ataxx no se puede mezclar con experto. Una partida de Takuzu 6×6 y otra 14×14 necesitan etiquetas distintas.
Por eso los motores están empezando a reportar detalles de variante. La capa de estadísticas puede seguir siendo común, pero recibe suficiente contexto para no borrar las diferencias que importan.
Responsive y accesibilidad han dejado de ser una auditoría al final
La misma semana en la que completamos varios motores también ampliamos controles en distintos breakpoints, reforzamos la navegación móvil y definimos un footer responsive compartido. No es coincidencia.
Cuando el catálogo crece, cualquier defecto del shell se multiplica. Un botón demasiado pequeño no afecta a una página; afecta a decenas. Una navegación que funciona mal en móvil convierte cada juego bien construido en una experiencia peor.
La estrategia actual es arreglar primero los patrones compartidos y después los casos específicos. Eso hace que cada auditoría de juego tenga menos trabajo repetido y que una mejora transversal llegue inmediatamente a todo el catálogo.
- reglas y estados de victoria correctos;
- generación reproducible y fiable;
- solución única cuando el puzzle la requiere;
- dificultad con significado;
- persistencia e historial coherentes;
- estadísticas con contexto de variante;
- teclado, accesibilidad y feedback;
- responsive real, no solo ausencia de scroll horizontal;
- onboarding específico o perfil compartido justificado;
- traducciones completas en los idiomas publicados;
- tests, self-tests o validadores que puedan contradecir al motor.
La auditoría está cambiando cómo añadiremos el juego siguiente
El beneficio más interesante no es haber mejorado ocho títulos. Es que cada reconstrucción reduce la probabilidad de repetir el mismo tipo de incompletitud en el futuro.
Ahora sabemos que un motor nuevo necesita pensar en estadísticas desde el principio. Que la dificultad debe poder explicarse. Que el onboarding no puede añadirse como texto genérico al final. Que la persistencia necesita una identidad reproducible del puzzle. Que responsive incluye controles, no solo tablero. Que la solución única debe verificarse automáticamente y no darse por supuesta.
Eso transforma la auditoría en arquitectura. Cada defecto encontrado se convierte en una regla, un componente o una comprobación que abarata el siguiente juego.
Más profundidad antes que más catálogo
Seguimos queriendo incorporar puzzles nuevos. El catálogo no está cerrado y probablemente nunca lo esté del todo. Pero el orden de prioridades ha cambiado.
Un juego nuevo solo mejora la plataforma si alcanza un umbral de calidad suficiente. Mientras haya títulos antiguos que no lo cumplen, completar y consolidar produce más valor que añadir una tarjeta número 77 únicamente para aumentar el contador.
La paradoja es que este trabajo menos espectacular hace que el catálogo sea más escalable. Cada motor reconstruido nos deja piezas compartidas, mejores validadores, convenciones de estadísticas, patrones de onboarding y decisiones de UI que el siguiente puede reutilizar.
Al principio crecíamos sumando juegos. Ahora intentamos crecer haciendo que el juego número 76 y el número 12 parezcan parte del mismo producto, aunque sus reglas no tengan nada que ver.
Esa diferencia es difícil de resumir en una captura de pantalla, pero probablemente sea el cambio más importante que hemos hecho en PuzzleHub durante estas semanas.