Como funciona o sistema de pulo no Mario e por que ele é mais complicado do que parece
A mecânica de pulo do Super Mario Bros. tem sido estudada por programadores e speedrunners há décadas. Se você quer entender jump mario jump na prática, precisa ir além da superfície. O pulo não é apenas um botão premido — ele envolve variáveis de velocidade vertical, gravidade personalizada e um timer que varia conforme a duração da pressão no botão. Muitos desenvolvedores independentes tentam recriar essa física e acabam cometendo o mesmo erro: usam gravidade linear simples. O pulo do Mario usa uma aceleração progressiva. O personagem cai devagar no início e acelera conforme desce. Isso cria aquela sensação característica de flutuação no ápice do salto. Sem esse ajuste, o pulo parece artificial e pesado demais.
Jump mario jump: a física por trás do salto perfeito
Aqui está como implementar isso do jeito certo. Você precisa de três variáveis principais: velocidade vertical (vy), gravidade (gravity) e força do pulo (jumpForce). No início de cada frame, subtraia gravity de vy. Se o jogador estiver no chão e pressionar o botão de pulo, defina vy como negativo de jumpForce. A coisa importante que a maioria esquece é o variable jump height — quanto mais tempo segurar o botão, mais alto o pulo vai. Isso se consegue simplesmente interrompendo a redução da velocidade vertical quando o jogador solta o botão cedo o suficiente. No meu primeiro projeto de platformer, eu configurei a gravidade para 980 unidades por segundo ao quadrado, com jumpForce de 400. O resultado era um pulo que parecia mais com um coelho do que com o Mario. Passei duas semanas ajustando os valores antes de perceber que o problema não era a gravidade em si, mas a falta de uma variável de cancelamento de queda. Quando o jogador pressiona direção oposta durante o pico do pulo, o Mario original reduz rapidamente a velocidade vertical. Implementei um multiplicador de 0.6 em vy nesse cenário específico e o controle ficou muito mais responsivo.
Outro detalhe que poucos mencionam: o coyote time. Isso permite que o jogador pule quelques frames após sair da borda de uma plataforma sem cair imediatamente. Sem isso, a precisão necessária frustra qualquer playercasual. Eu uso um timer de 6 frames de tolerância — suficiente para ser Perdoável mas não tão generoso que pareça mágica.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Dificuldades e onde o sistema quebra
O principal problema que encontrei ao trabalhar com essa mecânica foi o wall jump. Quando o Mario encosta em uma parede enquanto sobe, a física muda completamente. A velocidade horizontal é invertida com uma força diferente da gravidade normal, e existe um friction específico que impede o personagem de escorregar indiscriminadamente. Meu código inicialmente tratava o wall jump como um pulo normal com vetor alterado, o que resultava em saltos inconsistentes — às vezes o personagem subia muito, outras vezes quase não saía do lugar. A correção veio quando tratei o wall jump como um estado separado, com suas próprias constantes de velocidade e gravidade reduzida pela metade durante o contato com a parede. Outro problema prático é a colisão na ponta das plataformas. Quando o jogador está no limite exato entre o chão e o vazio, o cálculo de ground check pode falhar um frame e fazer o personagem cair quando não deveria. A solução que adotei foi expandir a caixa de detecção do chão em 2 pixels horizontalmente. Isso resolve a maioria dos casos sem introduzir comportamentos estranhos.
Não adianto que esse sistema seja perfeito. Em resoluções altas com frame rate variável, a física baseada em tempo pode desincronizar se não for implementada com delta time consistente. Jogos mais antigos funcionavam bem porque rodavam em 60fps fixo. Em engines modernas, você precisa garantir que todas as atualizações de física usem o mesmo timestep ou implementar um fixed update separado do render loop. O Mario original tinha exatamente 60 frames por segundo e toda a física era calculada em incrementos fixos de aproximadamente 16,67 milissegundos. Replicar isso fielmente em uma engine moderna exige atenção redobrada. Se o seu objetivo é apenas um jogo simples sem necessidade de fidelidade ao original, vale a pena considerar soluções prontas como o sistema deCharacterController da Unity ou o PhysBody do Godot. Eles não replicam exatamente a física do Mario, mas economizam horas de depuração. Para quem busca precisão cirúrgica, however, a implementação manual continua sendo o caminho, ainda que demande mais tempo e teste iterativo.
O download de exemplos práticos pode ser encontrado em repositórios open source que já implementam essas mecânicas. Procure por "Mario physics implementation" no GitHub — existem vários projetos com comentários explicativos que ajudam a entender cada variável e seu efeito no comportamento do personagem. Recomendo começar pelo mais simples e ir adicionando complexidade gradualmente, testando cada mudança individualmente.
