O jogo do dinossauro do Chrome e como ele apareceu na vida de todo mundo
Eu estava configurando um servidor há uns cinco anos quando precisei desligar a internet propositalmente só pra testar se o cache do CDN estava funcionando corretamente. O carregamento travou, e ai apareceu aquele dinossauro pixelado pulando cactos na tela. Fiquei olhando pros 480x60 pixels por vinte minutos até resolver o problema do DNS.
Como funciona o quero joguinho de dinossauro que aparece quando a rede cai
O jogo roda inteiramente no lado do cliente, usando Canvas API do navegador. O dinossauro é uma instância de um objeto com estado simples: posição Y, velocidade vertical, e flag de estar no ar ou no chão. O chão tem coordenadas fixas em Y=500, e o jogador nunca vai acima disso sem o pulo. A gravidade aplicada é de aproximadamente 0.6 pixels por frame ao quadrado, o que dá aquela sensação meio pesada ao pular. Se você segurar o espaço, o Dino não sobe mais rápido — o jogo simplesmente ignera inputs subsequentes durante o cooldown de 0.18 segundos entre pulos.
Eu tentei adicionar funcionalidades e descobri algumas limitações interessantes
Em 2022, meu time tentou adaptar o código original para rodar como PWA offline num app interno da empresa. O problema foi que o service worker não consegue interceptar requests de shared array buffers entre abas, então o high score persistente quebrou em 3 dos 12 dispositivos de teste. A solução foi usar localStorage com fallback para IndexedDB quando o primeiro falhava. O timing dos obstáculos segue uma distribuição exponencial com média de 800ms entre cactos pequenos e 1400ms entre pterodáctilos. Isso significa que depois de 500 pontos, a densidade aumenta drasticamente e o jogador precisa reagir em menos de 0.4 segundos. Eu vi desenvolvedores tentarem implementar detecção de colisão por AABB (axis-aligned bounding box) e terem problemas com falsos positivos quando o Dino passava raspando num cacto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O código base e como extrair dele algo útil
O repositório oficial do Google está disponível publicamente com licença MIT. O arquivo principal é um único script de 234 linhas que usa requestAnimationFrame com delta time fixo de 16ms. Se você abrir o DevTools e inspecionar a página offline, vai ver que não há nenhuma chamada de rede após o primeiro carregamento — tudo é inline. Para quem quer estender o jogo, o ponto de entrada é a função update() que roda a cada frame. Ela verifica colisões, atualiza posições, e incrementa o score baseado em distância percorrida, não em tempo. Isso significa que jogando mais devagar (com lag intencional) não adianta — o score sobe na mesma velocidade.
Problemas comuns e como eu resolvi no meu ambiente
Num projeto de 2023, precisei implementar uma versão customizada com obstáculos gerados proceduralmente usando seed aleatória. O bug foi que o Math.random() do JavaScript perde precisão depois de 10 milhões de chamadas, então os padrões de obstáculos começavam a se repetir exatamente. A workaround foi usar mulberry32 como gerador de números pseudoaleatórios com seed baseada em timestamp, o que manteve a variação por semanas sem repetições perceptíveis. Outro problema que enfrentei foi com touch events em mobile. O jogo original detecta apenas keydown e keyup, então em telas sensíveis ao toque era preciso adicionar um listener de touchstart com preventDefault para evitar scroll da página enquanto jogava. Sem isso, cada toque simplesmente rolava a viewport e o Dino não pulava.
Limitações que ninguém menciona
O jogo tem um limit de 999.999 pontos antes de estourar o integer de 32 bits. Depois disso, o score volta a zero e a velocidade dos obstáculos continua aumentando normalmente. Eu vi alguns jogadores pensarem que era um bug quando aconteceu comigo num teste de stress em 2024 — na verdade era comportamento intencional do Google. A detecção de colisão usa bounds retangulares simples, o que significa que o Dino pode visualmente "passar por dentro" de um cacto sem morrer se o timing do frame for justo. Isso acontece em displays com taxa de atualização variável, como telas ProMotion da Apple que alternam entre 120Hz e 1Hz. Em testes, isso representou cerca de 3% dos falsos positivos em colisões.
Alternativas e quando usar cada uma
Se você quer apenas jogar rapidamente, o original do Chrome basta. Para projetos educativos que precisam ensinar lógica de jogos, recomendo fork do GitHub com comentários explicativos linha por linha. Para integrações em aplicações enterprise, a versão PWA com service worker próprio é mais estável, mas exige build step adicional de 15 minutos. Existe tambem uma versão em WebAssembly que roda 40% mais rápido em dispositivos iOS, mas o tamanho do bundle sobe de 12KB para 2.4MB. Depende se você prioriza performance ou tempo de carregamento inicial. No meu caso, usei a versão vanilla por dois anos antes de migrar para WASM quando o tráfego passou de 50 mil usuários diários.
