Estudo de caso de engenharia de produto
Um dashboard local-first para caça competitiva de MVPs
Transformação de observações sensíveis ao tempo em inteligência de respawn, decisões de rota, notificações e progresso persistente para uma competição mensal.
Fluxo de decisão do tracker
O problema de produto
O servidor de Ragnarok Online mantém um ranking mensal de caça a MVPs com recompensas valiosas para as quatro primeiras posições. MVPs que nascem naturalmente concedem entre 10 e 50 pontos conforme seu nível, e cada um segue um cooldown de respawn diferente.
Meu tempo disponível para jogar era limitado, principalmente aos fins de semana. Permanecer competitivo dependia menos de jogar continuamente e mais de preservar informações corretas sobre as kills, antecipar as próximas janelas e escolher a rota de maior valor dentro do tempo disponível.
Design orientado ao gameplay ativo
A interface foi projetada como um dashboard operacional, não como um catálogo passivo. Registrar uma kill ou um MVP found dead salva o horário e a última posição observada no mapa, alimentando imediatamente a próxima decisão. Status, pontos, favoritos, contexto de localização e comparação com o ranking permanecem visíveis com interação mínima enquanto o jogo está aberto.
O tracker apoia o planejamento de rotas sem impor um caminho fixo. Respawns próximos podem ser avaliados junto ao valor em pontos, ordem de deslocamento, presença de concorrentes e ao custo de perseguir um MVP valioso em um mapa muito disputado.
Modelo de tempo e notificações
O modelo de domínio combina o último horário de kill observado com o cooldown de cada MVP para calcular uma janela esperada de respawn e derivar estados de espera, proximidade, disponível, desconhecido ou pausado. A interface atualiza esses estados continuamente, sem exigir recálculo manual.
Notificações do navegador são disparadas em um limite configurável, no aviso final de um minuto e quando o MVP deve estar vivo. Cada notificação é vinculada ao respawn calculado, impedindo que ciclos repetidos de atualização enviem o mesmo alerta mais de uma vez.
Contexto espacial e competitivo
Um seletor de mapa armazena a última posição observada em coordenadas normalizadas, não em pixels. Isso mantém os marcadores portáveis entre diferentes tamanhos de renderização e permite que tooltips recuperem mapa e localização em caçadas futuras.
O controle de pontos suporta personagens principal e secundário, enquanto snapshots do ranking preservam as primeiras posições e calculam mudanças ao longo do tempo. Disponibilidade e contexto competitivo transformam timestamps em decisões sobre onde investir os próximos minutos.
Arquitetura local-first
A aplicação usa JavaScript modular, HTML e CSS sem framework, mantendo o fluxo central rápido e sem runtime adicional. O localStorage oferece persistência imediata; normalização versionada e importação e exportação JSON preservam compatibilidade conforme o modelo de dados evolui.
O estado opcional entre dispositivos usa Netlify Functions autenticadas e Netlify Blobs com consistência forte. Saves são executados com debounce, sobrescritas e loads manuais exigem confirmação, e uma chave secreta protege o dataset pessoal. Essa escolha é intencionalmente adequada a uma ferramenta individual, sem ser apresentada como um sistema completo de identidade multiusuário.
Resultado e próxima fronteira
Durante as sessões, os próximos MVPs permaneciam visíveis em vez de se perderem entre diversos cooldowns independentes. Isso permitiu planejar sequências melhores, reagir a mapas disputados e priorizar oportunidades de pontos sem desperdiçar o tempo limitado dos fins de semana.
O repositório evoluiu incrementalmente de um tracker funcional para módulos separados de domínio, armazenamento, notificações, mapas, ranking, interface e sincronização. Oferecer o produto à comunidade é a próxima fronteira: a chave compartilhada daria lugar a identidade de usuários, datasets isolados e onboarding preparado para múltiplas pessoas.