Como lidar com merges no código do jogo do dinossauro do Chrome
O jogo do dinossauro do Chrome é basicamente um arquivo JavaScript embutido no Chromium, e quem tenta fazer modificações ou atualizar forks acaba se deparando com a mesma situação repetidamente: precisar dar merge em alterações sem quebrar a mecânica original. Aqui eu falo direto do que acontece na prática, sem rodeio.
merge master jogo dinossauro
Quando você baixa uma versão popular do jogo do dinossauro (tem dezenas de repositórios no GitHub) e quer incorporar mudanças do repositório original ou de outra fork, o processo de merge segue o mesmo padrão de qualquer projeto JavaScript, mas com detalhes que só aparecem quando o código não está documentado e tem variáveis globais espalhadas. A primeira coisa é verificar o branch principal do repositório que você considera fonte oficial. Normalmente é "master" ou "main", mas varia conforme o fork. Minha recomendação prática: não faça merge direto no branch principal antes de testar. Clone o repositório, crie um branch de teste, traga as alterações por "git pull upstream master" ou "git merge", e rode uma verificação visual. O jogo do dinossauro tem lógica de colisão baseada em frame e velocidade progressiva, então qualquer diferença em timers pode causar comportamentos estranhos que não aparecem até você jogar alguns minutos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Já tive um caso em que o merge trouxe uma atualização de sprites que alterava implicitamente o bounding box da hitbox do Cacti. O código não quebrou, não deu erro no console, mas o dinossauro começava a morrer alguns milissegundos antes do contato visual. A solução foi comparar os valores de collision offset no arquivo de configuração entre a versão base e a atualizada, e ajustar manualmente os valores de "tWidth" e "tHeight" no objeto do obstáculo. Isso resolveu em cerca de dez minutos, depois de duas horas testando rodadas diferentes para entender onde estava o descompasso. Outro ponto que costuma causar dor de cabeça são as dependências de build. Versões mais recentes usam TypeScript ou bundlers, enquanto versões antigas rodam direto em JS puro. Se o repositório que você está mesclando mudou a stack, o comando de build pode falhar silenciosamente e você acaba achando que o merge está correto porque o git não reclama. Verifique se o arquivo final gerado corresponde ao esperado antes de considerar o processo concluído.
Se seu objetivo é apenas adaptar o jogo para uso local ou estudar como ele funciona, talvez não precise de merge de versionamento de código. Você pode copiar o executável ou o trecho JavaScript diretamente do navegador abrindo DevTools no momento offline, salvando o script e isolando as partes que precisa. Isso evita problemas de conflito de branches e é mais rápido para experimentação. Dito isso, se você insiste em manter um repositório sincronizado com múltiplas fontes, o fluxo mais estável que eu uso é: primeiro congelar a versão base em um tag, depois aplicar alterações menores em branches separados, testar cada um individualmente, e só então mesclar para master após validação manual. Isso corta pelo menos dois terços do tempo que eu gastava antes resolvendo conflitos que nem apareciam nos testes iniciais.