Entendendo mecânicas de dificuldade progressiva em jogos
Trabalhar com jogos no inferno — como chamamos no desenvolvimento independente de jogos no Brasil — é uma questão de balanceamento, não de sadismo. O jogador precisa sentir que vai fracassar, mas saber que tem ferramentas para superar. Quando eu estava desenvolvendo um roguelike indie com dois colegas, entramos num problema interessante: a curva de dificuldade do jogo no inferno simplesmente não funcionava. A primeira versão tinha inimigos que cresciam exponencialmente em HP e dano, o que soa lógico à primeira vista, mas na prática só criava frustração, não desafio.
O problema do scaling exponencial
A abordagem mais comum é multiplicar os stats dos inimigos a cadaWave ou ciclo. Isso funciona em jogos como Enter the Gungeon, mas requer um trabalho de tuning massivo. O meu time começou com uma multiplicação de 1.15x por wave, o que, matematicamente, resulta em hp absurdo já na wave 8. O jogador morria antes de aprender os padrões de ataque. A solução foi limitar o crescimento de hp a 1.10x e aumentar o dano dos inimigos em vez disso, mantendo encontros mais curtos e mais frequentes. Isso mudou completamente a sensação de jogo. Em vez de batalhas desgastantes de três minutos, tínhamos encontros de 30 segundos que exigiam reação rápida.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Implementação técnica
Para quem quer reproduzir isso, o primeiro passo é criar uma tabela de dados separada da lógica do jogo. Não use variáveis hard-coded dentro dos objetos dos inimigos. Use um arquivo JSON ou YAML com todos os parâmetros: HP base, dano, velocidade, cooldown de ataque, drop rate. Aí você aplica a fórmula de scaling via script. No meu caso, usei Ccom Unity e escrevi um gerenciador chamado DifficultyManager que lê a tabela e aplica os multiplicadores com base na wave atual. O código em si é simples, mas a configuração da tabela é que leva tempo. Um detalhe importante: separe scaling numérico de spawning. Aumento de stats é diferente de aumento de quantidade de inimigos. Quando você junta os dois, o jogo vira um pesadelo computacional e a experiência do jogador piora. Meu conselho é aumentar stats até a wave 5, depois começar a adicionar inimigos, e só então aplicar os dois juntos a partir da wave 10.
O erro que cometi
O maior erro do nosso projeto foi ignorar o fator humano no balanceamento. Nós testamos sozinhos durante semanas e achávamos que estava difícil o suficiente. Quando mostramos para amigos de fora, percebeu-se que a wave 6 era praticamente impossível para quem nunca tinha jogado aquele tipo de jogo. A solução foi criar um sistema de scaling adaptativo que detecta a taxa de morte do jogador e ajusta levemente os multiplicadores. Não é um cheat — é apenas evitar que 60% dos jogadores desistam na mesma wave. O sistema registra as mortes e, se a taxa passar de 70% em três sessões consecutivas, ele reduz o scaling em 10% para a próxima partida.
Download e recursos
Se você quer ver na prática como essa estrutura funciona, deixei o DifficultyManager como open source no meu GitHub. O repositório inclui a tabela JSON de exemplo, o script em Ce um cenário de teste básico. Você pode clonar e adaptar para seu próprio projeto. O link está nos comentários fixados. Não é perfeito — tem bugs conhecidos em multiwave rápidos — mas serve como ponto de partida sólido. O ponto principal é que jogo no inferno não é sobre fazer algo impossivelmente difícil. É sobre criar uma tensão controlada onde o jogador sente o perigo sem ser esmagado por ele. Se você seguir a estrutura de scaling gradual e separar stats de spawning, já estará à frente de 80% dos projetos indie que vejo por aí. O resto é teste e ajuste.
