Atom Gauntlet: Protocol

O jogo

Polo é um ladrão preso em Carcere, uma estação prisional espacial. Os guardas de lá usam a Atom Gauntlet: uma luva capaz de reorganizar átomos e materializar armas do nada — mas só as que ela já conhece. Cada arma nova é um add-on que o jogador precisa encontrar pelo caminho.

Atacar consome energia da luva, e ela só recarrega nos checkpoints, que também salvam o progresso. Quando a energia acaba, Polo luta de punhos. São quatro alas até o Hangar — Celas, Manutenção, Armaria e a arena do Orion — três armas, quatro tipos de inimigo comum e um chefe.

O combate foi desenhado em torno de leitura, não de repetição. Cada inimigo anuncia o golpe antes de acertar, e insistir no botão é a forma mais rápida de morrer.

O que foi meu

No projeto original: a maior parte da programação, o Orion e as animações dele, a fase final no Hangar, e apoio no level design e na história. O sistema de combate, o sistema de armas, o consumo de energia, a máquina de estados dos inimigos, os checkpoints e as plataformas móveis saíram daqui.

Um ano depois, em 2026, voltei ao projeto sozinho — com autorização dos outros três — para consertar o que a entrega tinha deixado para trás. É dessa revisão que falam as seções abaixo, e é dela que vem o vídeo acima: na gravação antiga o jogo travava antes da última fase, e o Orion nunca chegava a aparecer.

A animação é a verdade do combate

Eu tinha quatro queixas anotadas, e elas pareciam quatro problemas diferentes: o combate era "dependente demais de timing"; o guarda acertava sem dar tempo de desviar; o atirador tinha cadência alta demais; o bumerangue não deixava janela para revidar.

Lendo o código, os quatro tinham o mesmo desenho por baixo. A animação era só um aviso para o Animator começar a tocar, e o dano corria num relógio próprio, em paralelo. No Polo, o dano saía no clique. No guarda, dois décimos de segundo depois do gatilho — mais de um segundo antes de a espada descer. No atirador, dois segundos antes de o disparo aparecer na tela. No bumerangue, no primeiro quadro do arremesso, antes de o braço se mover.

Sem dano preso à animação não existe aviso, e sem aviso não existe esquiva. Do lado de cá acontecia o mesmo ao contrário: atacar não custava nada, porque o Polo dava o golpe e seguia andando como se não tivesse dado.

A correção virou uma regra só: todo ataque tem preparação, impacto e recuperação, e o dano sai no quadro em que a arma encosta. O interessante foi que cada personagem precisou de uma técnica diferente para obedecer à mesma regra.

No Polo, cada arma tem uma duração própria e a animação é acelerada ou desacelerada para caber nela: o mesmo clipe leva meio segundo com a espada e um segundo e meio com o machado. Durante o golpe ele anda a 30% da velocidade e não gira — escolheu a direção, ela vale até o fim.

Nos inimigos comuns, a direção trava na metade da preparação. Essa é a janela de leitura: dá para ver aonde o golpe vai e sair de lá. E o acerto passou a exigir um arco frontal de 100 graus, então estar atrás do guarda deixou de dar no mesmo que estar na frente dele.

No boxeador, a mesma ideia com outra ferramenta. A animação dele é um recorte de uma gravação longa que contém dois socos. Em vez de refazer a animação, dividi o clipe nos três trechos que os socos criam e dei uma velocidade diferente a cada um: jab rápido de 0,25 s, uma preparação longa de 1,2 s que anuncia o soco forte, e 0,8 s de recuperação que é a janela do jogador. Um combo de dois tempos sem nenhuma animação nova.

No Orion a estrutura já estava certa — ele usa marcadores dentro do próprio clipe. O problema ali era de ordem: num dos ataques, o marcador que declara o fim vinha antes do que invoca as torretas. Ele se declarava livre, outro ataque cortava a animação no meio, e as torretas nunca chegavam a existir.

São dois métodos diferentes convivendo no mesmo jogo: tempo calculado em código nos inimigos comuns, eventos de animação no chefe. Isso foi deliberado. Misturar os dois dentro de um mesmo personagem é que seria confuso.

A execução que ninguém usaria

O machado permite executar: inimigo com pouca vida pode ser finalizado segurando uma tecla. Ao voltar ao jogo, percebi que nenhum jogador atento faria isso.

A conta não fechava. Executar exigia trocar para o machado, segurar a tecla por quase um segundo e trocar de volta — três ações — enquanto um golpe de espada resolvia na hora. E como todas as armas gastavam a mesma energia, não havia nada a economizar. Pior ainda: o machado tinha um bônus de dano contra inimigo ferido que o matava antes de a janela de execução abrir. Com o machado na mão, executar era literalmente inalcançável.

A pergunta que destravou isso não era sobre a execução. Era sobre o jogo inteiro: do que o jogador deve ter medo — de perder vida, ou de perder energia?

Escolhi energia. É o recurso que a luva usa, só volta nos checkpoints, e é o que dá identidade ao sistema. A partir dessa escolha a correção ficou evidente, e não precisou de mecânica nova nenhuma: cada arma passou a custar uma quantidade diferente de energia por golpe, e a janela de execução subiu de 20% para 40% da vida do inimigo.

A espada é a arma de dano. O martelo é pior de propósito — ele serve para quebrar coisas, não para lutar. E o machado tem exatamente a mesma eficiência da espada sendo três vezes mais lento: ninguém quer lutar com ele, todo mundo quer executar com ele.

Depois disso refiz a conta de energia de cada trecho entre checkpoints, somando o custo ideal de limpar aquele pedaço. O confronto final do pátio da Armaria — onde, no roteiro, Polo "por muito pouco consegue se livrar daquele grupo" — passou a custar mais energia do que cabe no medidor. Ele só é vencível executando. O clímax da fase obriga o jogador a usar a mecânica que ele acabou de ganhar, sem nenhum tutorial pedindo isso.

O Orion: uma escolha no meio da luta

O chefe tem 99 de vida divididos em três blocos, e o interessante acontece entre eles. Toda vez que um bloco acaba o Orion fica atordoado, e o jogador decide na hora: continuar batendo enquanto ele está vulnerável, ou correr até as costas dele e selar mais um pedaço do poder.

As duas escolhas mudam a luta em direções opostas. Bater durante o atordoamento irrita o Orion — ele volta mais rápido e mais perigoso. Selar faz o contrário: ele volta mais lento, mas o jogador abriu mão de dano livre e gastou energia para conseguir isso.

Na revisão, essa escolha quase não existia. O selo estava fora do alcance do jogador, dois metros acima do chão, e sem nenhum aviso na tela — metade do sistema era invisível. E o relógio que conta o intervalo entre os ataques especiais corria durante os ataques, então o "intervalo de três segundos e meio" era medido do começo de um golpe ao começo do outro. Como os golpes duram segundos, não sobrava quase nada: os ataques emendavam sem janela para revidar.

Hoje o relógio só anda quando o Orion está livre, e o intervalo escala com as duas decisões do jogador. Quem sela sempre mantém a janela praticamente intacta ao longo da luta. Quem bate sempre a vê encolher pela metade. A punição não é um número que aparece na tela — é o ar que falta entre um ataque e o seguinte.

Ele tem sete ataques e cinco estados de selo, de −2 a +2, e o modelo muda a cada bloco quebrado. Fazer os três estágios terem ataques e animações próprias, sincronizados, foi a parte mais trabalhosa do projeto inteiro.

O que ficou de fora

Inimigos com armadura estavam na apresentação original e continuam fora. Era funcionalidade nova, não conserto, e a revisão tinha prazo — o único blindado do jogo é o Orion, que invoca pedras que só o martelo quebra.

O sistema de diálogo também não foi tocado, e as falas entre os personagens ainda merecem outro tratamento. E o jogo continua curto para a quantidade de ideias que o sistema de armas comporta.

Sobrou um problema que eu não consegui provar: na primeira execução da build de Windows, o jogo fechou sozinho ao carregar a primeira fase. O mesmo arquivo funcionou em todas as execuções seguintes, sem nenhuma mudança. A suspeita é compilação de shaders na primeira abertura, mas suspeita não é diagnóstico, e prefiro registrar isso do que fingir que não aconteceu.

E ficou uma pergunta de design em aberto, que eu gosto de deixar registrada: selar custa 15 de energia, e quebrar os cristais para forçar o atordoamento custa mais ou menos os mesmos 15. Com o custo igual, selar é sempre a escolha melhor — o caminho agressivo precisa de alguma recompensa que ainda não existe. A luta funciona, mas a escolha ainda não é tão equilibrada quanto eu quero.

Equipe

Projeto integrado do 1º ano de Design de Jogos Digitais. Nenhum asset pago. A revisão de 2026 foi feita por mim, com autorização dos três.