Construct do Zero: Event Sheets e Lógica por Eventos (Fundamentos)

O que é uma Event Sheet (e por que ela “vira” o seu código)

No Construct, a lógica do jogo é construída com eventos em vez de linhas de código. Uma Event Sheet é uma lista de regras do tipo SE (condições) ENTÃO (ações). Cada evento pode ter:

• Condições: o que precisa ser verdadeiro para o evento acontecer.
• Ações: o que o Construct executa quando as condições são atendidas.
• Subeventos: eventos “filhos” que refinam a lógica do evento pai.
• Triggers (gatilhos): condições que disparam no momento exato em que algo acontece.
• Comparações: checagens numéricas e de texto (igual, maior, menor, contém etc.).
• Variáveis: globais, locais e de instância para guardar estado.

Pense assim: cada linha na Event Sheet é uma regra. O motor avalia essas regras e executa as ações conforme as condições.

Estrutura fundamental: Condições, Ações e o “filtro” de instâncias

Condições

Condições são perguntas. Exemplos comuns:

• Entrada: “Mouse clicou no objeto?”
• Estado: “Player está com vida <= 0?”
• Colisão: “Player colidiu com Inimigo?”
• Tempo: “A cada 1 segundo…”

Ações

Ações são comandos. Exemplos:

• Mudar de layout
• Definir variável
• Spawnar objeto
• Tocar som

Seleção (picking): quando o Construct escolhe “quais instâncias” serão afetadas

Se você tem 10 inimigos na tela e cria um evento “Inimigo: Destroy”, o Construct precisa saber quais inimigos. Muitas condições fazem uma seleção automática (picking). Exemplo: “Player colidiu com Inimigo” seleciona o(s) inimigo(s) envolvidos na colisão. As ações do evento afetarão apenas as instâncias selecionadas.

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

Subeventos: organizando lógica sem duplicar regras

Subeventos são úteis para criar “camadas” de decisão. Exemplo didático:

Evento: Player está no chão (condição)  -> (ações gerais de chão)    Subevento: Tecla Pular pressionada (trigger) -> (ação: aplicar impulso)

O subevento só é avaliado se o evento pai for verdadeiro. Isso reduz repetição e melhora legibilidade.

Triggers (gatilhos) vs condições contínuas

Existem condições que são avaliadas continuamente e condições do tipo trigger (gatilho).

Condição contínua (ex.: “Tecla está pressionada”)

Enquanto a tecla estiver pressionada, a condição fica verdadeira. Se você colocar uma ação de “Spawn” aqui, ela pode acontecer várias vezes por segundo.

Trigger (ex.: “On clicked”, “On key pressed”, “On created”)

Dispara uma vez no momento do evento. É ideal para ações que não devem repetir (abrir menu, iniciar fase, tocar um som único, confirmar um botão).

Comparações: a base para decisões

Comparações aparecem em várias condições (ou em condições específicas de “Compare”). As mais comuns:

• = igual
• != diferente
• < menor, > maior
• <= menor ou igual, >= maior ou igual

Exemplos práticos de decisões:

• Se GlobalVariable Pontos >= 100, liberar uma porta
• Se Player.Health <= 0, ir para GameOver

Variáveis: Global, Local e de Instância (quando usar cada uma)

Variáveis Globais

Servem para valores que precisam ser acessíveis em qualquer lugar (e, frequentemente, entre layouts). Exemplos: pontuação total, dificuldade, volume, número de vidas.

Boas práticas: nomes claros e consistentes, como gScore, gLives, gDifficulty.

Variáveis de Instância

Ficam dentro de cada instância de um objeto. Se você tem 5 inimigos, cada um pode ter seu próprio HP, Speed, State.

Exemplo: Enemy.HP diminui apenas no inimigo atingido (especialmente quando o evento seleciona a instância correta).

Variáveis Locais

Existem em um escopo limitado (normalmente dentro de um evento/ação de função ou bloco). São úteis para cálculos temporários sem “poluir” o projeto com variáveis permanentes.

Exemplo de uso: guardar um valor intermediário para decidir qual layout carregar, ou calcular um dano final antes de aplicar.

“Every tick” vs eventos disparados: desempenho e intenção

Every tick

É uma condição que roda continuamente (a cada frame). Use quando algo realmente precisa ser atualizado o tempo todo: seguir um alvo, atualizar HUD com valores que mudam constantemente, aplicar efeitos contínuos.

Risco comum: colocar ações que deveriam acontecer uma vez (como trocar de layout) dentro de “Every tick”. Isso pode causar repetição, travamentos, ou comportamento inesperado.

Eventos disparados (triggers)

Use para ações pontuais: clique em botão, pressionar tecla, criação de objeto, fim de animação, colisão inicial, etc.

Regra prática: se a ação deve acontecer uma vez por interação, prefira trigger.

Conectando Layouts a Event Sheets e reutilizando folhas

Um layout pode usar uma Event Sheet específica. Você também pode reutilizar lógica compartilhada entre layouts, mantendo consistência e reduzindo duplicação.

Estratégia recomendada de organização

• Event Sheet do Menu: lógica de botões e navegação do menu.
• Event Sheet da Fase: lógica de gameplay (player, inimigos, pontuação).
• Event Sheet compartilhada (opcional): utilidades comuns (atalhos, áudio, debug, funções gerais).

Como reutilizar sem duplicar

Em vez de copiar e colar eventos entre folhas, prefira incluir/compartilhar uma folha comum (quando aplicável) ou manter eventos equivalentes agrupados e padronizados. O objetivo é: se você corrigir um comportamento, não precisar corrigir em 3 lugares diferentes.

Boas práticas: nomes claros, comentários e agrupamento

Nomes

• Botões: BtnPlay, BtnRestart, BtnBack
• Layouts: Menu, Fase01, GameOver
• Variáveis globais: gScore, gLives

Comentários

Use comentários para explicar a intenção do bloco, não o óbvio. Exemplo: “Navegação do Menu” ou “Reinício de partida reseta estado global”.

Grupos

Crie grupos por área do jogo:

• MENU - Navegação
• FASE - Estado do jogo
• GAMEOVER - Reinício

Exercício prático: trocar entre Menu e Fase01 via botão + reiniciar no GameOver

Objetivo: implementar navegação básica usando eventos com triggers, mantendo organização e boas práticas.

Pré-requisitos do exercício

• Você já tem os layouts: Menu, Fase01, GameOver.
• No layout Menu, existe um botão (sprite ou nine-patch) chamado BtnPlay.
• No layout GameOver, existe um botão chamado BtnRestart.

Passo 1: criar/atribuir Event Sheets para cada layout

Crie (ou selecione) as folhas:

• ES_Menu para o layout Menu
• ES_Fase01 para o layout Fase01
• ES_GameOver para o layout GameOver

Em cada layout, confirme que ele está apontando para a Event Sheet correta. A ideia é: lógica do menu fica no menu, lógica do gameover fica no gameover, e o gameplay fica na fase.

Passo 2: Menu → Fase01 (clique no botão)

Na ES_Menu, crie um grupo chamado MENU - Navegação e adicione um comentário: “Eventos de troca de tela do menu”.

Crie o evento usando trigger (para não repetir):

Evento: BtnPlay -> On clicked    Ação: System -> Go to layout