Um tutorial recém-publicado do canal Gorka Games cravou o que chama de “o erro de 90% dos iniciantes em UE5”: concentrar lógica no Event Tick — o evento que roda a cada frame — e, com isso, multiplicar cálculos desnecessários por 60 execuções por segundo (ou mais), até o projeto ficar lento, instável ou até travar.
O que o Event Tick faz (e por que ele vira um “vazamento” de desempenho)
No Blueprint, o Event Tick executa “por frame”. Em um jogo a 60 FPS, isso significa que qualquer cadeia de nós conectada nele roda 60 vezes por segundo. A tese do vídeo é direta: em sistemas comuns (pickup, regeneração de vida, HUD), isso costuma ser desperdício de CPU, porque a lógica não precisa ser avaliada o tempo todo.
O autor reforça que, isoladamente, um Tick simples pode parecer inofensivo. O problema aparece quando vários atores e widgets repetem o mesmo padrão: pequenas rotinas por frame se somam, “engolindo” performance ao longo do tempo.
Exemplo 1: pickup não deve medir distância a cada frame
No primeiro caso, um item “flutuante” foi construído com Tick para checar, por frame, a distância entre o player e o objeto. Se estivesse abaixo de 100 unidades, o item seria coletado e removido do mundo.
O vídeo aponta o que está errado: medir distância continuamente “não faz sentido” quando a coleta depende de proximidade. Em vez disso, a checagem deve acontecer só quando existe um evento real de interação.
A alternativa mostrada é criar uma Sphere Collision (um volume invisível que detecta sobreposição) chamada “trigger” e usar OnComponentBeginOverlap. Na prática: o Blueprint roda uma vez quando o player entra no volume, em vez de rodar todo frame.
Para filtrar quem pode coletar o item, o tutorial usa uma checagem de tag (ex.: “Player”). Se um inimigo encostar no trigger, não coleta; se o ator com a tag correta entrar, coleta.
Exemplo 2: regeneração de vida via Timer, não via Tick
O segundo exemplo mira um padrão clássico: health regen. O sistema original verificava no Tick se a vida era menor que 100 e, se fosse, adicionava 1 ponto, com um Clamp para manter o valor entre 0 e 100.
O tutorial substitui a lógica por Set Timer by Event. Em linguagem simples: em vez de rodar a cada frame, você agenda um evento para rodar em intervalos (por exemplo, 1 segundo) e com looping. Isso reduz radicalmente a frequência de execução e dá controle fino do ritmo da regeneração.
O fluxo apresentado é: Begin Play (evento que dispara quando o jogo começa) inicia o timer; o timer chama um Custom Event (“Regenerate Health”) periodicamente; e o Blueprint ainda pode incluir um Branch para só executar se a vida estiver abaixo do máximo, evitando trabalho sem necessidade.
Exemplo 3: bindings em widgets também rodam por frame
O alerta mais importante para UI: bindings de widgets (como “bind” do Percent de uma Progress Bar) podem atualizar a cada frame. No exemplo do vídeo, o binding acessa o player, faz cast para o personagem e divide a vida por 100 para alimentar o Percent (0 a 1) da barra.
O problema: esse binding vira um “Tick disfarçado” dentro da interface, repetindo cast e leituras todo frame. Em projetos com HUD complexa, isso pode virar um gargalo silencioso.
A alternativa apresentada é atualizar o widget só quando a vida mudar: obter a referência do widget, garantir que o elemento de UI esteja marcado como “Is Variable” no Designer, e chamar Set Percent diretamente no momento em que a variável de vida é alterada (por dano ou regen). Resultado: a UI para de recalcular quando nada mudou.
Quando o Tick ainda faz sentido
O vídeo não demoniza o Tick por completo. Ele continua sendo útil quando a lógica realmente precisa de precisão por frame — como animações suaves, interpolação e movimentos que exigem atualização contínua. A regra prática defendida é simples: se o evento pode ser acionado por colisão, timer ou mudança de estado, não há motivo para usar Tick.
Para ver os Blueprints, nós e substituições em ação (incluindo o passo a passo completo de cada troca), o convite é direto: assista ao vídeo oficial.
Fonte: Gorka Games