Caso de ingeniería de producto
Un dashboard local-first para la cacería competitiva de MVPs
Transformación de observaciones sensibles al tiempo en inteligencia de respawn, decisiones de ruta, notificaciones y progreso persistente para una competencia mensual.
Flujo de decisión del tracker
El problema de producto
El servidor de Ragnarok Online mantiene un ranking mensual de cacería de MVPs con recompensas valiosas para las cuatro primeras posiciones. Los MVPs que aparecen naturalmente otorgan entre 10 y 50 puntos según su nivel, y cada uno sigue un cooldown de respawn diferente.
Mi tiempo disponible para jugar era limitado, principalmente a los fines de semana. Mantenerme competitivo dependía menos de jugar continuamente y más de conservar información correcta sobre las kills, anticipar las próximas ventanas y elegir la ruta de mayor valor dentro del tiempo disponible.
Diseño orientado al gameplay activo
La interfaz fue diseñada como un dashboard operativo, no como un catálogo pasivo. Registrar una kill o un MVP found dead guarda la hora y la última posición observada en el mapa, alimentando inmediatamente la siguiente decisión. Estado, puntos, favoritos, contexto de ubicación y comparación con el ranking permanecen visibles con interacción mínima mientras el juego está abierto.
El tracker ayuda a planificar rutas sin imponer un camino fijo. Los respawns próximos pueden evaluarse junto al valor en puntos, el orden de desplazamiento, la presencia de competidores y el coste de perseguir un MVP valioso en un mapa muy disputado.
Modelo de tiempo y notificaciones
El modelo de dominio combina la última hora de kill observada con el cooldown de cada MVP para calcular una ventana esperada de respawn y derivar estados de espera, proximidad, disponible, desconocido o pausado. La interfaz actualiza continuamente esos estados sin exigir cálculos manuales.
Las notificaciones del navegador se disparan en un umbral configurable, en el aviso final de un minuto y cuando el MVP debería estar vivo. Cada notificación se vincula al respawn calculado, evitando que ciclos repetidos de actualización envíen la misma alerta más de una vez.
Contexto espacial y competitivo
Un selector de mapa almacena la última posición observada como coordenadas normalizadas, no como píxeles. Esto mantiene los marcadores portables entre distintos tamaños de renderizado y permite recuperar mapa y ubicación en futuras cacerías.
El control de puntos admite personajes principal y secundario, mientras snapshots del ranking conservan las primeras posiciones y calculan cambios en el tiempo. Disponibilidad y contexto competitivo transforman timestamps en decisiones sobre dónde invertir los siguientes minutos.
Arquitectura local-first
La aplicación usa JavaScript modular, HTML y CSS sin framework, manteniendo rápido el flujo central y sin runtime adicional. localStorage ofrece persistencia inmediata; la normalización versionada y la importación y exportación JSON preservan compatibilidad mientras evoluciona el modelo de datos.
El estado opcional entre dispositivos utiliza Netlify Functions autenticadas y Netlify Blobs con consistencia fuerte. Los guardados tienen debounce, las sobrescrituras y cargas manuales exigen confirmación, y una clave secreta protege el dataset personal. Esta elección es adecuada para una herramienta individual, sin presentarse como un sistema completo de identidad multiusuario.
Resultado y próxima frontera
Durante las sesiones, los próximos MVPs permanecían visibles en vez de perderse entre múltiples cooldowns independientes. Esto permitió planificar mejores secuencias, reaccionar ante mapas disputados y priorizar oportunidades de puntos sin desperdiciar el tiempo limitado de los fines de semana.
El repositorio evolucionó incrementalmente desde un tracker funcional hacia módulos separados de dominio, almacenamiento, notificaciones, mapas, ranking, interfaz y sincronización. Ofrecerlo a la comunidad es la próxima frontera: la clave compartida daría paso a identidad de usuarios, datasets aislados y onboarding para múltiples personas.