O simulador de dinossauro do Chrome é mais complexo do que parece
A maioria das pessoas nem sabe que está rodando um jogo que já foi estudado academicamente. O simulador de dinossauro aparece quando você não tem conexão com a internet no Google Chrome. É aquele bichinho pixelado que corre e pula obstáculos. Parece simples. É. Mas tentar programar uma IA que jogue bem envolve algumas escolhas técnicas que vão te dar trabalho se você não souber o que está fazendo.
Como configurar seu próprio simulador de dinossauro local
Você precisa do jogo em si para treinar qualquer modelo. Tem formas mais fáceis, mas a que funciona consistentemente é clonar o repositório do chrome-dino ou usar o projeto do github que empacota o jogo como um sprite sheet animado. Eu usei a abordagem do chrome-dino original mesmo, peguei os assets diretamente do source code do Chromium, que estão disponíveis publicamente nos repositórios do Google. O jogo roda como um canvas HTML5, então qualquer script de automação consegue ler os frames. O problema é que rodar só o jogo não resolve nada se você quer treinar algo inteligente. A parte difícil é transformar o estado do jogo em vetores que um algoritmo consiga processar. O canvas tem dimensões fixas: 600 por 175 pixels na versão padrão. Cada frame mostra a posição exata do dinossauro, dos ossos e dos pterodáctilos. Se você ler pixel a pixel, vai gastar tempo demais. A solução razoável é fazer resize para algo como 84 por 84 pixels por canva, converter pra escala de cinza e empilhar quatro frames consecutivos. Isso dá ao modelo informação de velocidade e direção sem sobrecarregar a memória.
Eu perdi cerca de três dias tentando rodar com resolução nativa porque a GPU do meu laptop mais antigo não conseguia acompanhar o treinamento. A cada epoch, o tempo de processamento disparava e os resultados pioravam por overfit. Reduzir para 84x84 corrigiu isso de uma vez. O tempo de treinamento caiu de algo em torno de 4 horas por epoch para cerca de 25 minutos, dependendo do batch size que você escolhe.
Arquitetura que funciona na prática
Para o simulador de dinossauro, você não precisa de uma rede neuronal super elaborada. Comece com um DQN simplificado. O estado de entrada são os quatro frames empilhados. A saída é um tensor com duas ações: pular ou não pular. O reward function é simples demais pra ser bonito — ganhe um ponto por frame sobrevivido, perca 100 pontos se bater. Isso funciona melhor do que colocar reward positivo para pular, porque o modelo entende que pular por pular não compensa. A experiência replay é onde muita gente erra. Use um buffer de tamanho pelo menos 10.000 transitions. Se o buffer for pequeno, o modelo esquece situações antigas e passa a depender só dos padrões mais recentes, o que causa instabilidade séria durante o treino. O epsilon-greedy começa em 1.0 e decai linearmente até 0.01 ao longo de 100.000 steps. Decaimento exponencial também funciona, mas a versão linear é mais previsível e fácil de debugar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O target network deve ser atualizado a cada 1.000 steps. Atualizar com muita frequência faz o training oscilar. Atualizar de não estabiliza o aprendizado. Esse número de 1.000 veio de testes práticos, não de teoria pura.
Pegadinhas que ninguém conta
O simulador de dinossauro tem um bug real no mecanismo de geração de obstáculos que quase ninguém menciona. Quando o jogo atinge velocidades acima de 11 unidades, a lógica de spawn dos cactos passa a criar combinações impossíveis de pular. Dois cactos pequenos lado a lado com spacing menor que 150 pixels aparecem regularmente nessa faixa de velocidade. Se seu modelo nunca viu isso durante o treino, ele vai falhar sistematicamente nesses frames. A workaround que eu encontrei foi forçar seeds de RNG específicas durante o treino para garantir que o modelo encontrasse esses cenários, mesmo que raramente. Sem isso, a taxa de colisão saltava de 12% para mais de 40% em velocidades altas. Outro ponto: o jogo não é determinístico como a maioria pensa. Mesmo com seed fixa, variações sutis na renderização do canvas podem alterar os valores de pixel em até 2 ou 3 unidades por frame. Isso significa que dois runs idênticos com o mesmo código podem produzir resultados ligeiramente diferentes. Se você está comparando políticas ou medindo ganho de desempenho entre versões, anote sempre o seed e o framework usado. Caso contrário, suas métricas não são reproduzíveis.
O simulador de dinossauro também não lida bem com pterodáctilos voando baixo quando o jogo entra em modo hard. A detecção de colisão do navegador padrão do Chrome usa hitboxes um pouco maiores que o visual. O modelo pode parecer estar seguro baseado nos pixels, mas o jogo já considerou colisão. Isso é especialmente problemático para quem tenta usar visão computacional pura sem considerar a hitbox real. Use bounding box baseado nas coordenadas oficiais do sprite, não nos pixels renderizados na tela.
Links e recursos úteis
O jogo original já vem embutido no Chrome. Basta desconectar a internet e digitar chrome://dino. Para quem quer versão local com código aberto, o repositório chrome-dino do github tem build pronto. A versão do DeepMind usada no paper original está disponível como parte do gym Retro. Existem também implementações em PyTorch no Kaggle que servem de ponto de partida, mas a qualidade varia muito — algumas usam reward functions equivocadas que levam o modelo a aprender políticas subótimas. Se o objetivo é só jogar e relaxar, o simulador de dinossauro já instalado no Chrome resolve. Se é estudo ou experimentação, prepare-se para lidar com questões de normalização de input, estabilidade de treinamento e those edge cases de colisão que o jogo não documenta em lugar nenhum. Nada disso é impossível, mas exige atenção prática que tutoriais genéricos costumam pular.
