Como criar um jogo de passaro simples que não trava no celular
A maioria dos tutoriais que você encontra na internet mostra como fazer um jogo estilo Flappy Bird usando frameworks pesados. Eu parei de recomendar isso depois que vi gente tentando rodar Three.js num device com 2GB de RAM só pra fazer um pássaro pular. A verdade é que você não precisa de engine nenhuma pra isso. A abordagem mais sensata é usar canvas puro com JavaScript vanilla. O código cabe num único arquivo HTML e roda em qualquer navegador sem dependencies. O loop principal é basicamente isso: limpar o frame, atualizar posições, verificar colisões, redesenhar. Não tem mistério.
Por que todo mundo faz jogo de passaro errado na primeira tentativa
O erro mais comum é tentar otimizar prematuramente. Você começa com 30 sprites diferentes, animações CSS, sons, e aí o jogo vira um monstro que só roda em browsers modernos. Comece com o mínimo. Um retângulo verde representando o pássaro, dois retângulos marrons para os canos. Se o núcleo funciona, você adiciona complexidade depois. Se não funciona com retângulos, adicionar texturas 16x16 não vai resolver nada. Outra coisa que quase todo mundo erra é a detecção de colisão. Usar bounding boxes perfeitas ao redor dos sprites parece bonito mas gera frustração. O jogador morre num pixel onde claramente não havia desenho. A solução prática é reduziria a hitbox do pássaro em cerca de 20% na largura e altura. Isso já resolve 90% das reclamações de "jogo injusto".
No meu projeto recente, eu estava testando a detecção de colisão com os canos e notei que em resoluções de 360px de largura (comum em Androids antigos) a hitbox às vezes falhava porque o canvas fazia upscaling automático pelo navegador. O workaround foi definir explicitamente width e height no elemento canvas via atributos HTML, não via CSS. Isso trava a resolução interna e evita que o browser interfira nos cálculos de posição.
A estrutura básica que funciona
Você precisa de cinco variáveis de estado principais: posição Y do pássaro, velocidade vertical, array de canos, pontuação e estado do jogo (rodando ou parado). Cada frame você aplica gravidade à velocidade, soma à posição Y, move os canos para a esquerda, e verifica se algum cano saiu da tela para removê-lo do array. Quando um cano passa da posição X do pássaro sem colisão, você incrementa a pontuação. O timing do pulo é o que determina se o jogo é divertido ou não. A gravidade ideal fica entre 0.5 e 0.8 pixels por frame ao quadrado. O impulso inicial ao pular deve ser negativo, algo em torno de -8 a -10 pixels. Se o valor for muito alto, o pássaro sobe rápido demais e o jogador não tem controle fino. Se for baixo, o jogo fica lento e entediante. Teste com 0.6 de gravidade e -7.5 de impulso como ponto de partida.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Os canos precisam ser gerados com espaçamento consistente. A distância vertical entre o cano de cima e o de baixo varia entre 120 e 180 pixels. Menos que 120 e o jogo fica impossível em resoluções pequenas. Mais que 180 e perde o charme. Gere uma posição Y aleatória para o buraco a cada novo cano, mas garanta que o buraco nunca fique muito perto do topo ou do fundo da tela. Para rodar o loop, use requestAnimationFrame em vez de setInterval. O primeiro gera ticks sincronizados com a taxa de atualização da tela, o que significa que em monitors de 120Hz o jogo roda mais fluido sem alterar a lógica. Se você usa setInterval com 16ms fixos, jogos em telas de alta taxa de atualização ficam visualmente descompassados.
Distribuir o jogo de passaro para plataformas
Se o objetivo é apenas ter um link que funcione, hospede o arquivo HTML num serviço gratuito como GitHub Pages ou Netlify. É questão de minutos. Basta subir o arquivo e pronto. O jogo roda no navegador do usuário sem instalação. Para publicar em lojas de app, a situação muda. Você vai precisar empacotar o jogo com ferramentas como Cordova ou Capacitor. O processo básico é envolver o HTML/JS num WebView e gerar o APK ou IPA. O problema é que WebView em Android tem performance bem abaixo de um navegador nativo para animações. Testei isso na prática e o jogo caiu de 60fps para 30fps em dispositivos intermediários só por causa do overhead do WebView.
Se você quiser uma experiência mais próxima de app nativo sem compilação, considere usar um empacotador como FeltCode ou Godot exportando para HTML5. O Godot é overkill pra um jogo tão simples, mas oferece exportação direta para Android e iOS com bom controle de performance. O custo é curva de aprendizado maior e tempo de build mais longo. Uma alternativa que funciona bem pra jogos hypercasual é usar WebView wrappers leves como PWA (Progressive Web App). Você adiciona um manifest.json e um service worker, e o usuário pode "instalar" o jogo na tela inicial do celular. Não precisa passar por revisão de loja. A desvantagem é que funcionalidades como AdMob ou Google Play Games Services ficam limitadas ou inexistentes.
O que ninguém conta sobre monetização
O modelo mais comum para jogos desse tipo é anúncio interstitial a cada 3-5 partidas e rewarded video ao reviver. Mas há um detalhe prático: se você colocar o anúncio interstitial muito cedo, o usuário fecha o app antes de ver o anúncio e você não ganha nada. A experiência que funcionou pra mim foi mostrar o primeiro interstitial apenas após a terceira morte. Isso dá tempo suficiente de o jogador se conectar com o jogo, e ainda assim não é tão tarde a ponto de impedir o primeiro impacto de receita. Para rewarded video, ofereça ao menos duas vidas extras por sessão. Isso aumenta a taxa de completude do anúncio porque o jogador precisa do recurso. Jogos que oferecem apenas uma vida extra veem taxas de conclusão bem menores. É um equilíbrio delicado entre retenção e receita.
Outro ponto que muita gente ignora: a dificuldade deve escalar gradualmente. Canos que se movem mais rápido a partir de 10 pontos, ou buracos que ficam mais estreitos a partir de 25 pontos. Se o jogo não evolui, o jogador domina rápido e para de jogar. Escalonar a dificuldade é o que mantém o Loop de engagement funcionando além do terceiro dia. O código completo com tudo isso já discutido fica em torno de 200-300 linhas. Não precisa de biblioteca externa, não precisa de build system, e roda em qualquer lugar. Se você está começando agora, comece pelo canvas puro. Frameworks vêm e vão. Canvas ainda é a base de tudo.
