01Sobre o projeto
O Véu é um RPG cooperativo de ação e exploração em desenvolvimento, com estilo visual HD-2D. O projeto tinha uma prancha de referência de escala antiga (v1.0), desenhada quando o elenco jogável era de quatro personagens com Kael como unidade base. O jogo pivotou para uma campanha solo com Ceci como protagonista — a prancha antiga ficou obsoleta na unidade de medida, mas as relações de proporção entre os elementos do cenário (caixa, pedestal, arco, coluna) continuavam válidas.
02O desafio técnico
Recalibrar toda a escala do cenário (FirstPlayableSpace.tscn) e do NPC Kael a partir de Ceci como nova unidade 1.0×, sem:
- Redimensionar nenhum PNG-fonte.
- Commitar qualquer mudança antes de aprovação visual explícita.
- Alterar câmera ou zoom para mascarar problema de proporção.
- Assumir que escala de colisão é igual a escala visual — o erro clássico onde o collider herda o fator de escala do sprite e acaba maior que a área real que o personagem ocupa no chão.
03A abordagem
Medição real, não estimada
Leitura do canal alfa dos PNGs via Python/PIL para achar a altura e largura visível de verdade — ignorando padding transparente — de Ceci, Kael e de cada prop do cenário.
Cena de QA isolada antes de tocar na cena real
ScaleReference.tscn construída do zero só para comparação lado a lado, aprovada visualmente pelo dev antes de qualquer mudança na cena de produção.
Erro real, correção real
Na primeira rodada, a colisão do Kael foi escalada pelo mesmo fator do sprite (1.85×) — resultado: um círculo de colisão do tamanho da cintura para baixo, cobrindo até o joelho. O dev identificou no review ("radius 25.9 parece excessivo para um NPC de 170px") e pediu correção baseada na área real ocupada pelos pés.
Vão do arco recalculado por varredura de pixel
Em vez de mover os colliders dos pilares "no chute", o canal alfa do PNG do arco foi escaneado em várias alturas para achar a borda real da pedra — só então o vão livre foi recalculado (alvo: 52–64px), garantindo que o collider nunca ultrapassasse a pedra visível.
Obstáculo técnico do motor, resolvido em tempo real
Um TileMapLayer populado por script só renderizava em runtime, não no viewport estático do editor. Solução: anotar o script com @tool, fazendo o mesmo código rodar dentro do editor — permitindo ver costura, repetição e mistura de variantes de piso sem precisar dar Play.
Transparência sobre o que não deu para testar
Um bloqueio real de foco de janela (segunda tela do dev competindo por foco do SO) impediu teste de movimento ao vivo dentro do Godot. Em vez de forçar ou simular esse teste, a verificação foi substituída por análise geométrica (collider + varredura de pixel), com essa limitação registrada explicitamente no relatório.
04Resultado
(Ceci = 1.00×)
(corrigido de 25.9)
(faixa-alvo: 52–64px)
comparadas (64/80/96px)
Nada foi commitado sem aprovação explícita — todo o processo ficou em cenas de QA isoladas, revisáveis e descartáveis.
05Aprendizado
"Não é um prompt mágico que acerta de primeira — é iteração real: o dev aprovou parte, rejeitou parte com números concretos, o agente corrigiu com medição, e ficou registrado onde o processo bateu num limite real, em vez de simular sucesso."
06Galeria — material de referência do projeto
As peças abaixo são a bíblia visual de O Véu (identidade, mundo, sistemas e UI) usada como referência de contexto — não são as telas de QA da recalibração de escala em si, que ficaram em cenas de teste internas.
07Fechamento
Esse é o padrão de trabalho técnico que buscamos com IA: não delegar julgamento, delegar execução — e manter o humano no controle de aprovação, com evidência mensurável em vez de "parece que ficou bom".
Tem um problema técnico específico pra resolver?
Conta pra gente o que você precisa construir.
Vamos construir →