Pitch: Desenvolvendo um Aplicativo para Análises de Partidas de Valorant com Inteligência Articial

Há um bom tempo, antes mesmo de existir o Valorant, eu descobri que dava para baixar dados de partidas de League of Legends direto da Riot - com zero burocracias e sem pagar nada por isso. Como eu queria aprender um pouco mais sobre análise de dados e Machine Learning - algo que todo adolescente curte - resolvi usar o Lolzinho para tentar prever a chance de se ganhar uma partida com base em partidas anteriores. Não preciso nem dizer o resultado: não funcionou. Na verdade, eu não sabia muito bem o que estava fazendo - só segui uns tutoriais genéricos na internet e usei com meus dados.

A saga do Lolzinho terminou por aí, mas a ideia de usar os dados para analisar partidas do jogador ainda não tinha sumido totalmente.

Nessa mesma época, eu gostava muito de usar o LoLSUMO, um aplicativo que permitia analisar suas partidas do LOL e pontuava suas estatísticas de acordo com o que ele achava justo. Por exemplo: se você matou muito, ele dizia que, nisso, você jogou como um Challenger; mas se você farmou pouco, ele te pontuava como Ferro. E, no fim, te dava um rank geral, com base em todas as métricas. Nada disso tinha impacto real no jogo, mas era muito legal ver que você, no Ferro II, jogou como um Ouro I.

Surge um Novo Jogo

Com o nascimento do Valorant, vários aplicativos para análise de estatísticas das partidas surgiram - o mais famoso sendo o Tracker. Sendo bem honesto, eles funcionam muito bem para o que propõem - mostrar para o jogador as estatísticas.

Meu problema com esses aplicativos é que eles:

1. Mostram MUITA coisa que a maioria das pessoas não precisa - ou não quer - saber (como: KAST, ADR, ACS, ADDR e muito mais siglas).
2. Eles só mostram as coisas. Eu gosto muito de saber minha porcentagem de HS, mas seria melhor ainda saber como ganhar a partida - porque, no fim das contas, é isso que as pessoas realmente querem. Não adianta ter a melhor taxa de HS, ACS, ADR etc, e perder a partida - o PDL vai cair do mesmo jeito.

Foi com tudo isso em mente que eu tive a ideia de tentar fazer meu próprio aplicativo para análise de partidas, focando totalmente em mostrar o mais importante e oferecer feedback sobre como melhorar.

Nasce o ValorWise

Eu falhei em prever vitórias no LOL. Mas essa ideia de ir além das métricas simples e dizer ao jogador como ganhar nunca me saiu da cabeça. Com todos os aplicativos mostrando somente a parte técnica (o KAST, o ADR e um monte de siglas), o jogador, no fundo, só quer saber: 'O que eu fiz de errado e como corrijo para subir de patente?'. Foi aí que nasceu o ValorWise.

Em vez de mostrar um KAST de 70%, o ValorWise diz, por exemplo: "Seu ponto fraco é o clutch 1v1. Tente segurar a posição por mais tempo em vez de se antecipar."

Buscando a Aprovação da Riot

Diferente do LOL, no Valorant você precisa da autorização da desenvolvedora do jogo para obter os dados dos usuários - muito mais seguro para os jogadores, mas meio chato para quem só quer desenvolver.

Não sei se é assim com todo mundo, mas levou quase três meses entre eu mandar um protótipo no Figma e eles aprovarem uma chave para desenvolvimento (!).

Desenvolvendo o Aplicativo

Desenvolver o aplicativo foi muito complicado porque eu queria poder testar com dados reais, mas eu ainda não tinha a chave da API. Então, eu utilizei dados falsos para simular os dados dos jogadores, o que funcionou enquanto eu não tinha os dados reais.

Mas quando finalmente eu tive acesso à API oficial, mudar todo o backend para se adequar aos dados reais se mostrou um grande desafio - não porque a API fosse complicada, mas porque muito do que a gente já tinha feito e pensado não ia funcionar com a API real. Alguns dados que a gente precisava não vinham na API, e outros a gente acabou descobrindo que ia precisar depois.

Uma coisa que eu aprendi com esse projeto é que não adianta tentar se preparar: as coisas nunca ocorrem como você pensou.

Lidando com Versionamento da API

Eu nunca tinha lançado um aplicativo realmente - já tinha feito alguns como teste e tudo mais, mas publicar de fato eu nunca tinha feito. E muita coisa que eu estava acostumado a fazer eu tive que reaprender.

Uma dessas coisas foi o versionamento da API. Eu sei que virou padrão e todo mundo (ou quase todo mundo, eu acho) começa uma rota com /api/v1/nomeDaRota, mas eu, pelo menos, nunca precisei usar uma v2 nos meus projetos. Não que eu não saiba a necessidade de realmente versionar a API, mas porque as APIs de todos os meus projetos pessoais eram usadas somente pelas minhas aplicações (geralmente WEB) e sempre eram atualizadas junto com o servidor. Então, no pior dos casos, bastava o usuário atualizar a página e o erro sumia (acho que é assim que funciona, não?).

Mas com aplicações móveis as coisas mudam, e muito. Isso porque os usuários não costumam atualizar o aplicativo assim que uma nova versão sai - às vezes, alguns usuários simplesmente não atualizam nunca. E sua API precisa lidar com isso.

Constantes e Regras de Negócio Mutáveis

Outra coisa que me deu um pouco de problema foi como lidar com regras de uso e constantes. No início, eu criei um monorepo para lidar com a aplicação, e criei um package para as constantes (coisas como nomes de ranks, quantidade de usos diários da IA etc.) e importava ele tanto no backend como no aplicativo. Mas, como eu falei no tópico anterior, as pessoas não atualizam o aplicativo com a frequência esperada, e isso me deu alguns problemas.

Para deixar mais claro, vamos a um exemplo: digamos que eu defini que um usuário poderia usar no máximo 10 análises por dia. Essa constante estaria em vigor tanto no app do usuário quanto no servidor. O problema ocorria quando eu mudava esse número para, por exemplo, um máximo de 5 usos por dia. Nesse caso, se um usuário tivesse feito 5 análises, o aplicativo ainda permitiria que ele fizesse a sexta, mas o servidor retornaria um erro.

Para resolver isso, eu comecei a enviar todas as informações importantes e que poderiam mudar via API. Assim, se uma regra de negócios mudasse, o cliente não precisava necessariamente atualizar o aplicativo para receber a mudança.

Isso foi um problema também quando eu decidi criar um plano novo. Até então, os usuários tinham duas opções: ou eram usuários gratuitos (sem plano) ou usuários pagos (com plano). Para os usuários pagos, um dos diferenciais era a remoção de anúncios. Mas eu queria que o novo plano fosse diferente: ele deveria ser mais barato, porém com anúncios.

Eu até já tinha pensado que algo assim poderia ocorrer, e havia criado desde o início um package para validar coisas do tipo - quem pode usar a coisa x, acessar a página y etc. O problema era: esse pacote era importado pelo aplicativo e dependia de uma atualização para mudar. Foi então que eu decidi também mover para o servidor a lista de coisas que o usuário podia ou não fazer - sempre verificado pelo servidor, claro.

Analisando as partidas

Atualmente, nós utilizamos alguns métodos para analisar as partidas do jogador. Após extrairmos, limparmos e analisarmos os dados, nós extraímos indicadores. Em seguida, utilizamos um conjunto de LLMs (modelos de IAs para geração de texto), geramos uma análise para o usuário.

Nós permitimos que o usuário analise uma partida e receba uma explicação sobre diversos pontos do jogo, mas também temos um chatbot que permite que os usuários façam perguntas e tirem dúvidas, não só sobre alguma partida dele, mas sobre o jogo em geral.

Vale destacar que recentemente várias pessoas comentaram sobre o uso do TOON, uma espécie de JSON para LLMs, que lembra muito um CSV. Ainda não testei para ver se realmente ajuda a diminuir a quantidade de tokens utilizados enquanto mantém a mesma qualidade de saída, mas fica como um TODO.

Publicando o Aplicativo na Play Store

Antigamente, publicar um aplicativo era muito simples: bastava criar uma conta de desenvolvedor, pagar a taxa, responder alguns formulários e pronto! Seu aplicativo estava agora disponível para bilhões de pessoas e o céu era o limite (ou não).

Hoje em dia as coisas mudaram um pouco. Além de tudo o que falei, você também precisa testar seu aplicativo com pessoas reais. Para ser mais exato, ao menos 14 pessoas precisam testar seu aplicativo por no mínimo 2 semanas. Após isso, você pode mandar um formulário pedindo a aprovação.

Pode parecer simples, mas é um pouco mais complicado do que parece. Isso porque as pessoas precisam realmente usar o app, e se o número de pessoas ficar abaixo do pedido, o tempo deixa de contar. Também li alguns relatos de pessoas que tiveram a aprovação negada, pois o Google entendeu que não houve teste o suficiente.

Para o futuro

Esse é um projeto que está bem no início e ainda tenho várias ideias para implementar. Ainda falta muita coisa para ele ficar perfeito, mas estou melhorando ele aos poucos.

Vale destacar que esse é um projeto que eu desenvolvi com alguns amigos, tanto programadores quanto artistas. Então além de um projeto comercial, também era um projeto bem pessoal.

Quem ficou curioso e quiser testar, pode fazer isso clicando aqui.

Tentei falar de alguns problemas que apareceram e como nós lidamos com eles. Ainda faltou falar de muita coisa, quem sabe faço uma parte 2 :p.