Data Science aplicado a jogos: meu estágio na Wildlife Studios

Por que a parte difícil não é escrever a query, e sim descobrir qual pergunta vale a pena responder

Por Gabriel Lucena, Data Science Intern · setembro 2026

Antes da Wildlife Studios, eu era estudante de matemática aplicada na Unicamp e já tinha alguma experiência criando versões fan de jogos antigos. Construir esses jogos me ensinou como um game funciona por dentro, mas eu também queria trabalhar com dados. Na Wildlife, encontrei a chance de juntar os dois mundos e trabalhar com Data Science aplicado a jogos.

Entrei no começo do ano passado, no time de New Games Insights. Imaginava que ia explorar os dados, escrever algumas queries e gerar gráficos para responder perguntas, mas logo percebi que o escopo era muito mais amplo do que isso. Para cada pergunta aparentemente simples — “por que os jogadores estão parando nesse nível?” — eu precisava entender o que a gente queria medir, por que queria medir aquilo e como responder. Saber se estamos respondendo à pergunta certa é fundamental. E saber quais resultados e descobertas são de fato valiosos importa tanto quanto. A maior parte do trabalho acontece antes do código: entender o problema e discutir com o time até chegar lá. É mais lento e muito mais colaborativo do que eu imaginava, e é exatamente isso que deixa o trabalho empolgante.

Trabalhar com dados é entender como o jogador se relaciona com o jogo

Meu trabalho é entender como o jogo funciona de verdade: o que o torna divertido, o que faz o jogador querer jogar mais uma vez, o que faz ele gastar dinheiro. Também buscamos entender o que está funcionando e o que não está. É comum, por exemplo, investigar a calibragem do jogo para descobrir quando a economia está quebrada — e por que está quebrada, para conseguirmos agir sobre isso.

Uma das minhas primeiras análises foi exatamente essa. Os jogadores estavam acumulando uma quantidade enorme de moedas. Olhei o saldo de moedas ao longo dos níveis e o acúmulo ficou evidente. Depois quebrei o dado entre fontes e ralos (sources e sinks): os ralos eram baixos e constantes de um nível para o outro, enquanto as fontes só cresciam. A proposta foi calibrar a fonte que aumentava a renda do jogador de forma exponencial e seguir discutindo que oportunidades a gente tinha de aumentar os ralos ao longo da progressão. A conclusão foi clara o suficiente para que o ajuste da economia entrasse como prioridade no roadmap.

Enquanto estive no New Games Insights, trabalhei em vários protótipos de jogos que estávamos testando e desenvolvendo para melhorar cada game como produto. É muito legal mergulhar em vários jogos ao mesmo tempo: dá para comparar como cada um está performando em relação aos outros e, às vezes, é preciso entender um jogo muito a fundo e propor formas criativas de destrinchar um problema. Hoje trabalho em dois jogos com mais profundidade. Ter passado por vários antes me deu repertório: cada jogo tem um tipo diferente de problema e, depois de alguns, você começa a reconhecer os padrões.

De um hackathon a um projeto de verdade

De vez em quando a gente se afasta das atividades principais para participar de um hackathon, em que é possível construir um jogo inteiro em três dias ou tocar outro tipo de projeto. No meu primeiro, escolhi desenvolver um bot capaz de responder perguntas abertas sobre o comportamento dos jogadores. A ideia era liberar nosso tempo para as perguntas mais demoradas e dar autonomia para os product managers conseguirem respostas fora dos dashboards, de forma mais rápida.

A ideia e o potencial eram bons, e decidimos continuar com o projeto depois do hackathon. Ele virou meu projeto principal por um tempo: o bot rodava no nosso Slack e a gente tinha jobs em produção. Mas, no fim, a adoção não foi suficiente para justificar o tempo que estávamos investindo — então decidimos parar de investir nele.

Isso poderia ser visto como um fracasso, e a gente seguiu para o próximo projeto de jogo. Mas, ao longo do desenvolvimento, eu ampliei bastante meu conhecimento e aprendi a quebrar uma pergunta aberta em três partes: o que queremos medir, por que queremos medir e como responder — transformando uma pergunta vaga em uma análise fechada, confiável e rigorosa. Esses padrões me deixaram melhor nos jogos em que trabalhei depois e também me ajudaram a melhorar nossas bibliotecas e ferramentas, aquelas que permitem construir as análises mais comuns de forma mais rápida e com mais confiança. No fim, o processo de trabalhar nesse projeto foi importantíssimo para a forma como eu trabalho hoje.

IA para ir mais fundo nas análises

Esses padrões viraram o fluxo de trabalho que uso todos os dias. Montei uma forma de trabalhar em que a IA agêntica cuida da parte operacional da análise: escrever código, montar notebooks, gerar dashboards. Eu fico com a parte que exige julgamento de verdade: entender o problema, questionar as hipóteses e decidir o que a análise precisa provar antes que eu acredite nela.

Na prática, o trabalho operacional deixou de ser o gargalo. Uma análise que antes levava dias hoje flui muito mais rápido e com mais consistência, porque o processo está padronizado e é reprodutível. As bibliotecas e ferramentas que construímos juntos ajudam nessa consistência: elas dão funções e convenções padrão que combinamos como time, então conseguimos confiar no que estamos produzindo. Isso me deixa livre para gastar meu tempo nas perguntas que são realmente difíceis.

E não sou só eu. Vi o uso de IA crescer muito no time no último ano e meio. A pergunta não é mais “vale a pena usar?”, e sim “como usar bem?”.

A cultura de dados que encontrei aqui

Antes de entrar, eu não sabia muito bem o que esperar: era minha primeira experiência em uma empresa de tecnologia. O que encontrei aqui me surpreendeu — decisões realmente guiadas por dados e discussões técnicas profundas. Dado não é um monte de relatório que alguém pede no fim do processo: faz parte de como as decisões são tomadas desde o começo.

Mas o que mais me impressionou foi a autonomia. Como estagiário, eu esperava receber tarefas bem definidas e executá-las. Em vez disso, participo da discussão desde o início e ajudo a direcionar as prioridades. Também sinto que o time realmente quer que eu aproveite o máximo dessa experiência.

Nesse período tive dois gestores, e os dois me colocaram em situações em que eu pudesse aprender. Estavam sempre por perto e me incentivavam a questionar as coisas, a entender por que estávamos fazendo daquele jeito e a dar minha opinião. “Por que estamos fazendo assim?” nunca foi uma pergunta ruim aqui. É uma pergunta esperada.

O processo é a parte divertida

Se eu tivesse que resumir a experiência: o time trabalha em projetos interessantes, se dedica de verdade a eles e se ajuda para atacar os problemas que valem mais a pena entender. Chegar na melhor resposta é o que a gente quer, e nem sempre é fácil chegar lá.

Entrei achando que Data Science era só responder perguntas. Mas o que importa é o processo de entender até chegar na resposta: as discussões, as hipóteses que a gente descarta no caminho, o gráfico que contraria o que todo mundo esperava. Esse processo é o que torna divertido trabalhar na Wildlife, e não consigo imaginar um lugar mais divertido para fazer isso do que dentro de um jogo — eu construía jogos para entender como eles funcionavam por dentro e hoje desmonto jogos com dados.

Se a parte que te interessa é justamente aquela em que ninguém tem a resposta ainda, esse é um bom lugar para estar.