A local-first dashboard for competitive MVP hunting

The Ragnarok Online server runs a monthly MVP hunting ranking with valuable rewards for the first four positions. Naturally spawning MVPs award between 10 and 50 points according to their level, and each one follows a different respawn cooldown.

My available playtime was limited, mostly to weekends. Staying competitive therefore depended less on playing continuously and more on preserving accurate kill information, anticipating the next windows, and choosing the highest-value route through limited time.

The interface was designed as an operational dashboard rather than a passive catalog. A kill or found-dead observation records the timestamp and last-seen map position, then immediately feeds the next decision. Status, points, favorites, location context, and leaderboard comparisons remain visible with minimal interaction while the game is running.

The tracker supports route planning rather than prescribing one fixed route. Upcoming respawns can be weighed against point value, travel order, competing players, and whether a crowded map makes an otherwise valuable MVP worth pursuing.

The domain model combines the last observed kill time with each MVP's cooldown to calculate an expected respawn window and derive waiting, soon, alive, unknown, or paused states. The UI refreshes those states continuously so the dashboard stays useful without requiring manual recalculation.

Browser notifications fire at a configurable threshold, at the final one-minute warning, and when an MVP should be alive. Notifications are keyed to each calculated respawn so repeated refresh cycles cannot send the same alert more than once.

A map picker stores the last-seen position as normalized coordinates rather than image pixels. This keeps markers portable across different rendered map sizes and allows tooltips to restore both map and location context during later hunts.

Point tracking supports primary and secondary characters, while leaderboard snapshots preserve the current top positions and calculate changes over time. Together, respawn availability and ranking context turn raw timestamps into decisions about where the next minutes of play are best spent.

The application uses modular vanilla JavaScript, HTML, and CSS so the core workflow remains fast and has no framework runtime. Browser localStorage provides immediate persistence, while versioned normalization and JSON import/export preserve compatibility as the data model evolves.

Optional cross-device state uses authenticated Netlify Functions and strongly consistent Netlify Blobs. Saves are debounced, manual overwrite and load operations require confirmation, and a secret sync key protects the current single-user dataset. This is intentionally appropriate for a personal tool rather than being presented as a complete multi-user identity system.

During active sessions, upcoming MVPs remained visible instead of being lost among many independent cooldowns. That made it possible to plan better hunting sequences, react to crowded maps, and prioritize point opportunities without wasting limited weekend playtime.

The repository evolved incrementally from a functional tracker into separated domain, storage, notification, map, leaderboard, UI, and cloud-sync modules. Offering it to the wider game community is a clear next product boundary: shared-secret persistence would give way to user identity, isolated datasets, and community-ready onboarding.