Como funcionam os jogos de dinossauros robôs no navegador
Se você já clicou duas vezes na tela sem querer enquanto tentava carregar uma página lenta e viu aquele dinossauro pixelado correndo, você já conheceu um jogo de dinossauro robô. Não é nada sofisticado do ponto de vista técnico, mas a lógica por trás dele é mais interessante do que a maioria das pessoas imagina. O Chrome T-Rex game, por exemplo, usa apenas HTML5 Canvas com JavaScript puro. Sem bibliotecas, sem frameworks, sem dependências externas. O código é algo em torno de 10 a 15 kilobytes se você extrair o essencial. Eu fiquei prendendo o jogo durante uma dessas reuniões chatas que todo mundo já teve em que você deveria estar prestando atenção em slides e não estava. A versão que eu achei tinha um bug curioso: após um certo tempo, a velocidade aumentava a ponto de o dinossauro parecer travar visualmente. O problema real era que o loop de renderização usava requestAnimationFrame sem um delta time fixo, então a taxa de atualização do monitor influenciava diretamente a velocidade do jogo. Em monitores de 144Hz o jogo rodava quase duas vezes mais rápido do que em 60Hz. A solução foi simples — substituir o incremento de velocidade por um cálculo baseado em milissegundos entre frames usando um objeto Date.now() ou melhor ainda, a API performance.now().
O conceito por trás de jogos de dinossauros robôs
A ideia central é o que chamamos de infinite runner. O cenário se move em direção ao jogador, obstáculos surgem em intervalos pseudo-aleatórios e o controle é basicamente um pulo. Alguns jogos mais recentes adicionam obstáculos voadores, rochas, cactos duplos, e até mecânicas de agachamento. A parte mais trabalhosa não é a renderização em si, mas a geração procedural de obstáculos. Tem gente que não considera isso importante, mas é onde a maioria dos clones falha. Um erro comum que eu vejo em praticamente todos os tutoriais por aí é usar Math.random() puro para determinar quando e onde os obstáculos aparecem. O resultado é um padrão repetitivo que o jogador acaba memorizando em três ou quatro rodadas, e o jogo perde qualquer graça. A solução que eu adotei foi usar uma semente pseudo-aleatória simples combinada com um intervalo mínimo entre obstáculos — você define um range de 1500 a 2500 milissegundos entre cada spawn, e o jogo nunca fica totalmente previsível mas também nunca fica impossível.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que ninguém menciona é o sistema de colisão. Detecção AABB (Axis-Aligned Bounding Box) funciona perfeitamente para sprites retangulares simples. Mas se você tentar fazer colisão pixel-perfect em jogos de dinossauros robôs, vai perder performance e não ganhar nada útil. A diferença visual é insignificante e o custo computacional é desnecessário para algo que roda no navegador. A persistência de pontuação alta também merece atenção. Usar localStorage é a maneira mais direta de salvar o recorde do jogador. Mas tem um problema: se o usuário limpar o cache do navegador, o recorde some. Para resolver isso, algumas versões mais elaboradas enviavam os dados para um backend simples com Firebase ou Supabase. Se o seu objetivo for apenas um protótipo ou brincadeira, localStorageResolve. Se quiser algo permanente, vale a pena configurar um banco leve.
O aspecto sonoro também costuma ser esquecido. O original da Google tem aquele som de batida na queda, que é um áudio de 8 bits empilhado em um base64 inline. Para jogos de dinossauros robôs com mais polimento, um loop de música de fundo estilo chiptune consegue aumentar muito a experiência sem comprometer a performance. AudioContext com WebAudio API funciona bem para isso, mas exige cuidado com políticas de autoplay dos navegadores modernos. Se você quer testar ou modificar os jogos de dinossauros robôs que eu mencionado, o código-fonte do Chrome T-Rex está disponível abertamente. Basta abrir as ferramentas de desenvolvedor (F12) na aba de página offline e acessar os assets originais. Diversos forks e reimaginações também existem em plataformas como GitHub e Itch.io, alguns com mecânicas completamente diferentes como tiros, power-ups e modos cooperativos.
Por que esses jogos continuam relevantes
Existem razões práticas para essa categoria continuar produzindo versões novas. O primeiro é a acessibilidade extrema. Um jogo desse tipo roda em qualquer dispositivo com navegador, desde um smartphone básico até um PC gamer. O segundo é a carga cognitiva mínima — ninguém precisa ler tutorial ou assistir vídeo de instrução para entender como jogar. O terceiro, e talvez o mais relevante, é que ele serve como base perfeita para aprendizado de programação web. Professores e mentores usam esse tipo de projeto porque cobre gráficos 2D, lógica de jogo, manipulação de DOM e event handling tudo em um escopo que cabe em um final de semana. O limite principal é que, depois de algumas horas, a repetitividade torna o jogo descartável. A única saída para manter o interesse é adicionar progressão — desbloqueio de personagens, cenários alternativos, modos de desafio com condições específicas. Isso exige uma camada extra de arquitetura que muitos projetos amadores não implementam, e é onde a maior parte desses clones morre.
