Ir para o conteúdo
Avatar do Ned, mascote do GNORGNOR

Por que meu evento afeta todos os objetos? Como funcionam os eventos no Construct 3

Você colocou vários monstros na tela e criou um evento para destruir um monstro. Quando testou, todos sumiram de uma vez. Ou aconteceu o contrário: você esperava que algo afetasse todo mundo, e só um objeto reagiu. Não é bug. É a regra mais importante do event sheet do Construct 3. Quando ela faz sentido,…

Ned5 min read

This content isn't available in English yet — you're reading the original.

Porque todos os monstros somem?

Você colocou vários monstros na tela e criou um evento para destruir um monstro. Quando testou, todos sumiram de uma vez.

Ou aconteceu o contrário: você esperava que algo afetasse todo mundo, e só um objeto reagiu.

Não é bug. É a regra mais importante do event sheet do Construct 3. Quando ela faz sentido, muita coisa na engine para de parecer imprevisível.

Neste artigo vamos entender essa regra, testá-la em um experimento rápido e depois provocar o “erro” de propósito, para ver exatamente por que ele acontece.

Ainda não abriu o Construct 3? Comece por [Como começar no Construct 3? Conhecendo a engine antes de criar seu primeiro jogo — inserir link].

Primeiro: “Monster” não é um monstro só

Antes de falar de eventos, precisamos separar duas ideias que parecem iguais, mas não são.

💡 Conceito: tipo de objeto e instância

Pense em uma fôrma de biscoito. A fôrma define o formato. Com ela, você pode fazer um biscoito, dez ou cem. Todos saem iguais da fôrma, mas cada biscoito é uma coisa separada: um pode estar na ponta da bandeja, outro pode quebrar, outro pode ser comido.

No Construct 3 funciona de um jeito parecido:

  • Quando você cria um Sprite chamado Monster, está criando um tipo de objeto (object type). Ele é a “fôrma”.
  • Cada cópia de Monster colocada no layout é uma instância. É cada “biscoito”.

Todas as instâncias compartilham o que foi definido no tipo de objeto, como a imagem e os behaviors. Mas cada uma tem sua própria posição, seu próprio tamanho e seu próprio estado.

Então, quando você escreve “Monster” no event sheet, surge uma pergunta importante: quais monstros? Todos? Só alguns? Um só?

Quem responde isso são as conditions.

A regra: conditions escolhem, actions agem sobre os escolhidos

Um evento do Construct 3 não funciona como uma ordem gritada para o tipo de objeto inteiro (“Monstros, destruam-se!”). Ele funciona em duas etapas:

  1. As conditions verificam as instâncias e filtram aquelas que atendem aos critérios.
  2. As actions são executadas somente nas instâncias que passaram pelo filtro.

O Construct chama esse processo de escolher instâncias de picking. Você vai encontrar muito essa palavra em fóruns e na documentação.

🧠 Pense assim

A condition é uma peneira. Todas as instâncias passam por ela, e só as que atendem ao critério ficam retidas. A action age apenas sobre o que ficou na peneira.

E se nenhuma condition do evento mencionar Monster?

Então ninguém peneirou os monstros. Nesse caso, uma action de Monster vale para todas as instâncias.

Essa é a resposta para o título deste artigo.

🧪 Experimento: um clique, um monstro

Vamos ver isso acontecendo. O experimento leva poucos minutos.

Preparação:

1 – Crie um projeto novo.

    2 – Crie um Sprite chamado Monster (qualquer desenho serve, até um quadrado).

    3 – Coloque várias instâncias de Monster no layout, por exemplo copiando e colando. Cinco já bastam.

    4 – Adicione ao projeto os objetos Mouse e Keyboard. Eles não aparecem na tela, mas o Construct precisa deles para saber o que o jogador faz com o mouse e o teclado.

      📝 Os nomes de conditions e actions abaixo estão como aparecem no editor em inglês. O Construct 3 permite trocar o idioma da interface nas configurações (Settings). Se o seu editor estiver em outro idioma, os nomes podem aparecer traduzidos.

      Evento 1:

      ConditionMouse → On object clicked → Monster
      ActionMonster → Destroy

      Rode o projeto (preview) e clique em um dos monstros.

      Só o monstro clicado desaparece. Os outros continuam lá.

      Por quê? A condition On object clicked verificou todos os monstros e escolheu apenas a instância que recebeu o clique. A action Destroy só enxergou essa instância.

      💥 Agora vamos provocar o “erro”

      No mesmo event sheet, crie um segundo evento:

      Evento 2:

      ConditionKeyboard → On key pressed → Space
      ActionMonster → Destroy

      Rode o projeto e aperte a barra de espaço.

      Todos os monstros somem de uma vez.

      Por quê? Essa condition verifica o teclado, não os monstros. Nenhuma condition deste evento escolheu instâncias de Monster, então a action vale para todas.

      Percebe o que aconteceu?

      A action é exatamente a mesma nos dois eventos: Monster → Destroy. O que mudou foi a condition. Ela é que decide quem recebe a action.

      E quando há mais de uma condition?

      Um evento pode ter várias conditions, e todas precisam ser verdadeiras para as actions rodarem. Quando mais de uma condition fala do mesmo objeto, cada uma filtra um pouco mais o resultado da anterior.

      Imagine um evento que diga, em linguagem humana:

      “Monstro clicado e com menos de 5 pontos de vida → destruir.”

      A primeira condition escolhe o monstro clicado. A segunda verifica se aquele monstro tem pouca vida. Se não tiver, nada acontece.

      Para montar esse evento, cada monstro precisaria guardar a própria vida, e isso é assunto para o próximo passo. Por enquanto, guarde a ideia: conditions em sequência vão estreitando a seleção.

      ⚠️ Cuidado: erros comuns

      • Usar uma action de um objeto que nenhuma condition mencionou. Resultado: a action atinge todas as instâncias daquele tipo.
      • Achar que o evento “sabe” qual monstro você tinha em mente. Ele não sabe. Ele só sabe o que as conditions escolheram.
      • Combinar Every tick com Destroy. Every tick é uma condition do System que roda o tempo todo e não escolhe nenhum monstro. Um evento Every tick → Monster Destroy apaga todos os monstros assim que o jogo começa, e parece que eles nunca existiram.

      ✅ Checkpoint

      • Um tipo de objeto é a fôrma, e cada instância é uma cópia no layout.
      • Conditions escolhem instâncias (picking).
      • Actions agem apenas sobre as instâncias escolhidas.
      • Se nenhuma condition do evento escolheu aquele objeto, a action vale para todas as instâncias.

      Quando algo afetar objetos demais (ou de menos), faça esta pergunta:

      “Alguma condition deste evento escolheu esse objeto?”

      🎯 Missão GNOR

      1. Monte o projeto do experimento com 5 monstros.
      2. Faça o clique destruir só o monstro clicado.
      3. Faça a barra de espaço destruir todos os monstros.
      4. Compare os dois eventos e anote, com suas palavras, por que o resultado foi diferente.

      Desafio extra: consegue fazer a barra de espaço destruir só os monstros que estão na metade esquerda da tela?
      Dica: procure, nas conditions do próprio Monster, alguma que compare a posição do objeto.

      🏁 O que vem agora

      Agora sabemos que um evento não fala com “o objeto”, e sim com as instâncias que as conditions escolheram. Com isso, já conseguimos controlar se uma action atinge um monstro, alguns ou todos.

      Mas surge um novo problema: e se cada monstro precisar de vida própria, que diminui a cada clique, em vez de sumir de uma vez?

      Para isso, cada instância precisa guardar a própria informação. Esse é o assunto do próximo passo: variáveis de instância.

      Um grande Abraço!

      ned despedindo

      Newsletter

      Keep exploring with GNOR

      Sign-ups aren't live yet: sending will be connected soon.

      Written by

      Ned

      Conversa

      Comentários

      Carregando comentários…

      Deixe seu comentário

      Sem cadastro: só nome e e-mail. Seu e-mail não aparece no site e é usado apenas para identificar o comentário.

      Comentários passam por moderação antes de aparecer.

      Fundamentos

      Precisa aprender a programar para fazer jogos?

      Você teve uma ideia para um jogo. Começou a pesquisar como poderia criá-lo e, pouco tempo depois, apareceram palavras como programação, C#, JavaScript, variáveis, funções e lógica. E aí veio a dúvida: “Preciso aprender a programar para fazer jogos?” Se você nunca programou antes, essa pergunta pode ser suficiente para fazer desenvolvimento de jogos parecer…

      1 min read