Construct do Zero: Otimização, Depuração e Testes Sem Programar

Otimização, depuração e testes: o trio que evita “bugs fantasmas”

Em jogos feitos por eventos, a maior parte dos problemas vem de três fontes: (1) eventos disparando mais vezes do que você imagina, (2) objetos/efeitos em quantidade acima do necessário, e (3) diferenças entre dispositivos (FPS, resolução, touch). Este capítulo foca em ferramentas e rotinas para encontrar a causa real (depuração), medir impacto (otimização) e garantir que não volte (testes e regressão), sem escrever código.

Conceitos essenciais (sem teoria demais)

• Depurar: observar o jogo “por dentro” enquanto roda (instâncias, variáveis, condições verdadeiras/falsas) para achar a origem do comportamento errado.
• Otimizar: reduzir custo de CPU/GPU/memória sem mudar a experiência do jogador (ou mudando o mínimo possível).
• Testar: executar um conjunto repetível de verificações (checklist) para garantir que entradas, telas e regras continuam funcionando após mudanças.

Ferramentas práticas do Construct para depuração

1) Debugger: o painel que mostra o estado real do jogo

O Debugger permite inspecionar, em tempo real, o que existe na cena e quais valores estão ativos. Ele é a forma mais rápida de responder perguntas como: “quantos inimigos existem agora?”, “qual é o valor de vida do jogador?”, “este objeto está com colisão ativada?”, “o FPS caiu quando?”

Passo a passo: usando o Debugger para inspecionar instâncias

• Execute o jogo em modo de prévia (preview).
• Abra o Debugger (painel de depuração) durante a execução.
• Localize a seção de Objects/Instances e selecione o objeto que quer investigar (ex.: Player, Enemy, Bullet, UI).
• Observe:
  • Contagem de instâncias (se está crescendo sem parar, há vazamento de objetos).
  • Variáveis de instância (ex.: hp, state, invulnerable, cooldown).
  • Propriedades (posição, ângulo, opacidade, visibilidade, colisão/physics conforme o caso).
• Enquanto joga, provoque o problema e veja quais valores mudam no momento exato do bug.

2) Inspeção por “marcadores” visuais e textos de debug

Além do Debugger, é útil criar um modo de depuração dentro do próprio jogo, que você liga/desliga. Isso acelera a identificação de estados e colisões sem ficar alternando painéis.

Passo a passo: criando um “Debug Mode” sem poluir o jogo

• Crie uma variável global debugMode (0/1).
• Crie um evento para alternar: ao pressionar uma tecla (ex.: F1) ou um botão oculto no mobile, debugMode = 1 - debugMode.
• Crie um texto (ou UI pequena) que só aparece quando debugMode = 1 e mostre informações úteis:
  • vida do jogador, estado atual, cooldowns
  • quantidade de inimigos, balas e partículas
  • FPS e tempo de delta (se disponível)
• Opcional: desenhe “hitboxes” usando sprites simples sem textura (retângulos) ou trocando a animação para uma versão de debug quando debugMode = 1.

Identificando gargalos comuns (e como confirmar)

Gargalo 1: objetos demais (instâncias acumulando)

Sintoma típico: FPS cai com o tempo, mesmo sem “muita coisa acontecendo”. Causa comum: projéteis, inimigos, efeitos e pickups não são destruídos ao sair da tela ou ao finalizar sua função.

Checklist rápido

• Contagem de instâncias aumenta continuamente no Debugger?
• Existe evento de Destroy para objetos temporários (balas, partículas, efeitos)?
• Há spawners criando objetos sem limite (por tempo e sem condição)?

Ajustes práticos

• Destruir ao sair da área jogável (fora da câmera ou fora do layout).
• Colocar limite de instâncias por tipo (ex.: máximo de 30 inimigos ativos).
• Usar pooling (reutilização) quando aplicável: em vez de criar/destruir o tempo todo, ocultar e reativar instâncias (se seu projeto já usa esse padrão).

Gargalo 2: partículas e efeitos visuais em excesso

Partículas são baratas até deixarem de ser. O custo cresce com taxa de emissão, vida longa, blend modes pesados e quantidade simultânea.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Como confirmar

• Desative temporariamente o emissor (evento condicional) e compare FPS.
• Observe no Debugger a contagem de instâncias de partículas (ou do objeto que representa o efeito).

Ajustes práticos

• Reduzir rate de emissão e lifetime.
• Evitar partículas em tela inteira quando não necessário.
• Trocar efeitos contínuos por “bursts” curtos (explosões rápidas).
• Diminuir quantidade em dispositivos móveis (condição por plataforma ou por qualidade).

Gargalo 3: loops e eventos rodando “a cada tick” sem necessidade

Em Construct, eventos que rodam todo frame podem virar um custo invisível, especialmente se fazem buscas, comparações complexas ou iteram muitos objetos.

Como confirmar

• Identifique grupos de eventos que rodam sempre (sem condição de estado).
• Procure por eventos que fazem ações pesadas repetidamente (ex.: recalcular UI, procurar alvos, checar colisões manualmente) mesmo quando nada mudou.

Ajustes práticos

• Transformar “checagens contínuas” em checagens por evento: só atualizar quando algo muda (ex.: vida mudou, pontuação mudou).
• Usar timers/cooldowns para reduzir frequência (ex.: checar alvo a cada 0,2s em vez de todo frame).
• Desativar grupos de eventos quando não estão em uso (ex.: lógica de combate desligada em menus).

Ajustes de colisão e física com foco em estabilidade

Problemas típicos que parecem “bug” mas são configuração

• Colisão grande demais: o jogador toma dano “sem encostar”.
• Colisão pequena demais: tiros atravessam inimigos.
• Física/solid causando travas: inimigo encosta em canto e fica vibrando ou preso.
• Várias colisões no mesmo frame: dano duplicado, knockback exagerado.

Passo a passo: rotina de ajuste de hitbox

• Ative debugMode e mostre a hitbox (visual) do objeto.
• Compare a hitbox com o sprite em diferentes animações (andar, atacar, pular).
• Se a hitbox muda muito por animação, considere:
  • padronizar o tamanho do collision polygon
  • usar um objeto “Hitbox” separado (invisível) seguindo o sprite, quando fizer sentido
• Teste colisões em velocidade alta (dash, knockback) para garantir que não “atravessa”.

Passo a passo: evitando dano duplicado por múltiplas colisões

• Defina uma variável de instância no Player: invuln (0/1) e/ou invulnTime.
• No evento de colisão com inimigo/projétil:
  • Condição extra: Player.invuln = 0
  • Ações: aplicar dano, ativar invulnerabilidade, iniciar timer para desligar após X segundos.
• Se o dano vem de projétil, destrua/desative o projétil no primeiro acerto para impedir múltiplos hits.

Checklist de testes (entradas, resoluções e regressão)

1) Checklist de entradas: teclado

• Movimento: esquerda/direita/cima/baixo (ou WASD) responde sempre.
• Teclas simultâneas: mover + pular + atacar não trava.
• Teclas de sistema do jogo: pause, reiniciar, abrir menu funcionam e não disparam duas vezes.
• Segurar tecla vs. toque rápido: ações que devem ser “uma vez” não repetem indevidamente.

2) Checklist de entradas: mouse

• Cliques em botões: área clicável corresponde ao visual.
• Hover (se existir): não fica preso em estado errado.
• Arrastar (se existir): não “solta” fora do esperado.
• Cliques rápidos repetidos: não duplicam compra/ação/seleção.

3) Checklist de entradas: touch

• Toque único: botões respondem sem atraso.
• Toque contínuo: controles virtuais mantêm estado corretamente.
• Multitoque: mover e pular/atacar ao mesmo tempo funciona (se o jogo exige).
• Toque perto das bordas: UI não fica inacessível.

4) Checklist de resoluções e aspect ratios

• 16:9 (desktop), 19.5:9 (celulares), 4:3 (tablets antigos) e uma resolução bem pequena.
• UI: barras, ícones e textos não saem da tela e não sobrepõem elementos críticos.
• Área jogável: jogador não nasce fora da câmera; spawns não aparecem “dentro” da UI.
• Safe area (mobile): elementos importantes não ficam colados nas bordas.

5) Checklist de regressão (após mudanças)

Use sempre que você alterar eventos de combate, spawn, UI ou câmera.

• Combate: dano, invulnerabilidade, knockback e morte continuam corretos.
• Spawns: limites de inimigos e timers continuam respeitados.
• UI: pontuação/vida atualizam apenas quando mudam (e não somem).
• Fluxo: pause, game over e reinício não duplicam objetos nem música.
• Performance: FPS e contagem de instâncias não pioraram após a mudança.

Exercício guiado: ciclo de depuração completo (3 problemas típicos)

Objetivo: escolher um dos problemas abaixo, reproduzir, medir, encontrar a causa, corrigir e documentar a correção nos comentários dos eventos. Faça o exercício em uma cópia do projeto ou usando versionamento/backup.

Estrutura do ciclo (use como roteiro)

Problema A: dano duplicado (o jogador perde 2x vida em um único contato)

Como reproduzir (exemplo)

• Entre em uma área com inimigo de contato.
• Encoste no inimigo enquanto está se movendo para frente.
• Observe se a vida cai duas vezes quase ao mesmo tempo.

Depuração (passo a passo)

• No Debugger, selecione o Player e observe hp e qualquer variável de invulnerabilidade/cooldown.
• Ative debugMode e mostre na tela: hp, invuln e um contador de “hits recebidos” (variável que incrementa quando toma dano).
• Verifique se existem dois eventos diferentes aplicando dano (ex.: colisão com inimigo e colisão com hitbox do inimigo).
• Verifique se o evento de colisão está dentro de um loop/For Each que pode disparar mais de uma vez.

Correções comuns (escolha a que se aplica)

• Adicionar gate de invulnerabilidade: condição Player.invuln = 0 antes de aplicar dano.
• Desativar a fonte do dano após o hit: destruir projétil, desativar hitbox, ou marcar inimigo como “já acertou” por um curto período.
• Unificar o ponto de dano: manter apenas um evento responsável por reduzir HP (outros eventos apenas disparam sinais/flags).

Comentário recomendado no evento (modelo)

// FIX (2026-01-25): Dano duplicado ao encostar no inimigo. Causa: evento de colisão disparava em frames consecutivos sem invulnerabilidade. Correção: condição Player.invuln=0 + timer de 0.5s para reativar dano. Validado: contato contínuo não reduz HP mais de 1x por janela.

Problema B: inimigo travando (fica preso em quina, vibra ou para de perseguir)

Depuração (passo a passo)

• Observe no Debugger: velocidade, direção, estado (patrulha/perseguição), e posição do inimigo.
• Ative hitboxes visuais para ver se a colisão está “pegando” em cantos.
• Desative temporariamente: (1) knockback, (2) física/solid, (3) mudança de direção automática, para descobrir qual parte causa o travamento.
• Verifique se há eventos conflitantes no mesmo frame (ex.: um evento manda ir para a direita e outro manda parar).

Correções comuns

• Ajustar collision polygon para reduzir “ganchos” em quinas.
• Adicionar lógica de “destravar”: se velocidade ~0 por X tempo enquanto deveria andar, inverter direção ou aplicar pequeno deslocamento.
• Garantir que apenas um estado controla o movimento por vez (patrulha OU perseguição), desativando grupos conforme o estado.

Comentário recomendado (modelo)

// FIX (2026-01-25): Inimigo travava em quinas. Causa: hitbox com canto agudo + eventos de troca de direção conflitantes. Correção: simplificação da hitbox e prioridade de estados (patrulha desativada durante perseguição). Validado em 3 áreas com paredes estreitas.

Problema C: UI fora do lugar (em resoluções diferentes)

Depuração (passo a passo)

• Teste em pelo menos 3 aspect ratios (ex.: 16:9, 19.5:9, 4:3).
• No Debugger, selecione elementos de UI e observe posição X/Y e se estão em layer correta.
• Verifique se algum evento reposiciona UI “a cada tick” com valores fixos que não consideram viewport.
• Ative um overlay de debug mostrando largura/altura da viewport e margens (em texto).

Correções comuns

• Ancorar UI por bordas (margens) em vez de coordenadas absolutas.
• Separar UI em layer que não sofre parallax/scroll e garantir que a câmera não afeta a UI.
• Atualizar posição apenas quando a resolução mudar (ou ao iniciar a cena), evitando recalcular todo frame.

Comentário recomendado (modelo)

// FIX (2026-01-25): UI saía da tela em 4:3 e 19.5:9. Causa: posicionamento absoluto (X=900) ignorando viewport. Correção: ancoragem por margem (direita/superior) usando tamanho da viewport; atualização apenas no start e quando resize. Validado em 3 resoluções.

Rotina recomendada para manter qualidade (rápida e repetível)

• Antes de adicionar feature: defina como você vai testar (qual checklist será afetado).
• Depois de implementar: rode o Debugger e confirme contagem de instâncias e variáveis críticas.
• Antes de considerar “pronto”: execute o checklist de entradas + 3 resoluções + regressão do que você mexeu.
• Ao corrigir bug: comente o evento com causa, correção e como validou (para não reaparecer).