Introdução -
Olá pessoal, bem vindos a mais um tutorial da série "Guia rápido de programação em Unity".
No tutorial anterior, nós vimos como utilizar algumas das funções mais recorrentes da API da Unity. Hoje irei dar continuidade à série explicando sobre algo muito relevante em relação à engine: A ordem de execução de eventos.
O que são eventos:
Antes de entrarmos de fato nesse assunto, vou explanar rapidamente o que seriam os tais "eventos".
Em programação orientada a eventos, um event (evento) nada mais é que uma função como outra qualquer, com a diferença na forma como ela é chamada.
Funções "comuns" são chamadas "manualmente", como fizemos com todas as funções do tutorial anterior, ou seja, são chamadas em tempo de compilação.
Já no caso de eventos, eles podem ser chamados em momentos específicos, no caso da Unity, a própria engine fica encarregada de gerenciar essas chamadas de alguns eventos específicos de sua API, ou seja, nós como usuários não temos controle de quando eles(os eventos) serão invocados, pois eles são chamados em tempo de execução.
Podemos ter eventos que são chamados quando passamos o mouse sobre algum objeto, outro evento que é invocado quando clicamos com o lado esquerdo do mouse, ou até mesmo quando alteramos um campo dentro de um componente de UI (vide o InputField, por exemplo).
Perceba que nós como usuários da Unity não temos um real controle de quando essas funções são chamadas, quem se encarrega de gerenciar tais eventos, é a própria engine.
Eventos de inicialização:
Dito isto, perceba que sempre que criamos um novo script na Unity, o nosso código além de fazer referencia às bibliotecas necessárias, definir a classe do script e a herança do MonoBehaviour, ainda por cima sempre declara duas funções padrões: Start e Update.
Por conta de suas chamadas serem realizadas a partir da engine, que é responsável por gerenciar essas ações, podemos classificar ambas funções como eventos.
Sabemos que o Start é chamado quando o objeto é inicializado, e que o Update é chamado muitas vezes por segundo, mas será que é só isso?
Além do Start, ainda temos outros dois eventos responsáveis pela inicialização de Game Objects, são eles: Awake e OnEnable.
Na verdade, esses dois eventos são chamados ANTES do Start. A ordem de execução destes eventos de inicialização é esta:
Awake: O evento Awake é chamado assim que o objeto é instanciado e ativado em cena, no primeiro frame de carregamento. É o primeiro evento de inicialização a ser invocado.
Ele é chamado apenas uma vez, a não ser que se recarregue a cena ou que a mesma seja carregada de forma aditiva.
Se o Game Object que contiver o Awake estiver desativado, e depois ser ativado, ele vai invocar o Awake (pela primeira vez), porém, caso o script que contenha o evento Awake estiver desativado, o Awake será chamado mesmo assim.
Essa é uma grande confusão que ocorre às vezes: Existe uma diferença entre desativar/ativar o Game Object em si, e algum script/componente que ele comporte: O Awake é chamado assim que o Game Object for ativado, porém, ele será invocado MESMO que o script que o contenha estiver desativado.
Utilize o Awake como inicializador para o próprio script, seja para inicializar variáveis ou obter componentes dependentes. É como se fosse o construtor de classes "nativas" do C#.
Exemplo de uso:
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Awake.html
OnEnable: É invocado assim que o objeto é ativado em cena e o seu script habilitado, porém, após a chamada do Awake.
Toda vez que o script é inabilitado e depois habilitado novamente, o OnEnable será chamado, assim como quando o Game Object for desativado e ativado, ele novamente será invocado, ao contrário do Awake que é chamado apenas uma vez durante o ciclo de vida do script.
Você pode utilizar esse evento para gerenciar algo que ocorre toda vez que o objeto ou o script são ativados (como a reinicialização de variáveis, por exemplo):
No exemplo acima, a variável "example" é setada com o valor zero quando o Game Object é ativado, a partir daí o Update incrementa esse valor. Quando você desativa o script ou o Game Object e o reativa, a variável "example" é resetada para o valor zero novamente.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnEnable.html
Start: O evento Start é chamado apenas uma vez, após o Awake e o OnEnable.
Ele é chamado assim que o Game Object está ativo em cena e o script que o contém esteja habilitado.
Você pode utilizar esse evento para inicializar a comunicação com objetos ou scripts externos, que já tiverem a sua inicialização através do Awake.
Dessa forma, você tem dois momentos para controlar uma inicialização, caso necessite, se a ordem de inicialização de algum componente, objeto, ou valor importe.
Você pode "atrasar" a inicialização do Start através de Coroutines, por exemplo:
No caso do exemplo acima, o Start será chamado após 3 segundos.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html
Eventos de Atualização:
Agora vamos falar um pouco sobre os eventos que são invocados em dependência da taxa de frames do jogo/projeto:
FixedUpdate: Este evento é chamado num controle fixo de frames per second, estipulado pela engine de física da Unity.
Ele pode ser chamado com mais frequência que o Update, ou com menos frequência (por isso o fluxograma acima pode às vezes ser invertido em alguns casos), pois nós podemos definir a taxa de quadros em que o FixedUpdate poderá ser chamado.
Para alterar a taxa de chamadas do FixedUpdate vá em >> Edit >> Project Settings >> Time >> Fixed TimeStep.
Por padrão o "TimeStep" é definido por 0.02, ou seja, o evento será chamada à cada 0.02 segundos.
A utilização do FixedUpdate é recomendada quando queremos gerenciar principalmente componentes de física, como o Rigidbody, por exemplo, pois como ele é chamado numa taxa fixa e precisa, não teremos problemas de irregularidades em cálculos da física do jogo (como aplicar a força num objeto de formas inconstantes à cada quadro):
O código acima se trata de um script bem simples de pulo, onde quando o jogador pressionar "Space" o objeto receberá uma força sob seu rigidbody na direção pra cima. Perceba que a ação de física "adicionar força a um corpo rígido" está sendo realizada dentro do FixedUpdate.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html
Update: O evento de Update é muito utilizado em jogos, pois é um evento que será chamado muitas vezes por segundo.
No caso da Unity, o Update é chamado dependendo do frame per second do jogo, ele será chamado uma vez a cada quadro, logo, se o jogo está rodando à 60 fps, ele será chamado 60 vezes por segundo.
Utilizamos o Update quando queremos verificar ou validar algo que deva estar em constante observação, como o momento em que alguma tecla é pressionada durante o jogo para realizar alguma ação. A tecla pode ser pressionada a qualquer momento, por isso este tipo de verificação deve estar dentro de um evento de Update.
Por conta de suas chamadas inconstantes (depende muito do fps do jogo), não é recomendável utilizar comandos que necessitem de uma maior precisão, como cálculos de física, por exemplo, dentro do Update. Para estes fins você deve sempre estar multiplicando os valores a serem calculados por um fator multiplicador que irá tentar "padronizar" essa irregularidade de chamadas, no caso, temos o campo "deltaTime" acessado através da classe "Time".
Porém, é muito mais simples utilizar o FixedUpdate para estes casos, como visto acima.
No código acima, o Update detecta quando o jogador pressiona ou deixa de pressionar a tecla "Space" e emite uma mensagem para cada ação.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html
LateUpdate: Este evento é chamado sempre após o Update, e isso é algo positivo caso queiramos manter alguma ordem de execução para alguma ação (como no caso dos inicializadores).
A própria documentação da Unity sugere que o LateUpdate é perfeito para gerenciar o movimento de câmeras, visto que o Update/FixedUpdate será responsável por movimentar o personagem, o LateUpdate é chamado logo em seguida, ajustando a câmera após a movimentação do player.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.LateUpdate.html
*Todos os eventos de Frame-Rate serão chamados apenas enquanto o objeto estiver ativo em cena, e o script habilitado.
Eventos de destruição:
Existem dois eventos que gerenciam as ações para GameObjects que serão desativados ou destruídos:
OnDisable: Este evento será chamado assim que o objeto se tornar inativo, ou seu script desabilitado, sendo oposto ao OnEnable.
O OnDisable também será chamado assim que o objeto ou seu script/componente for destruído (tanto por conta de funções como "Destroy", quanto quando a cena se encerrar).
OnDestroy: O evento "OnDestroy" será chamado assim que o objeto for destruído ou seu script/componente, após a chamada do "OnDisable".
Isso lhe dará uma ordem de execução para a destruição do objeto, assim como no caso dos inicializadores, se a ordem de chamadas para tal ação for importante, por exemplo.
Exemplo de uso do OnDestroy:
No exemplo acima, quando o Game Object for destruído, um prefab contendo uma animação de explosão será instanciado na mesma posição que o objeto destruído.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnDestroy.html
Lembrete:
*Lembrando que os eventos mostrados neste tutorial só serão invocados de forma correta, caso estejam contidos dentro de uma classe que herde de MonoBehaviour, pois é a partir desta classe que a Unity pode gerenciar a chamada destes eventos, e também é a partir deste tipo de classe que os scripts se tornam componentes, sendo assim, sua inicialização, atualização e destruição só poderão ocorrer quando estiverem contidos num objeto em cena.
Você pode declarar funções com os nomes dos eventos aqui mostrados em classes que não herdem de MonoBehaviour, porém elas não vão funcionar da forma esperada (não serão chamadas como mostrado ao longo do tutorial) e isso não é considerado uma boa prática.
Finalização:
E aqui chega ao fim mais um tutorial sobre programação na Unity! Espero que este tutorial possa sanar de uma vez por todas as dúvidas que os usuários tanto iniciantes quanto avançados tem em relação a estes eventos, suas diferenças e ordem de execução.
Próximo tópico do guia >> "MonoBehaviour x Classes Nativas"
Olá pessoal, bem vindos a mais um tutorial da série "Guia rápido de programação em Unity".
No tutorial anterior, nós vimos como utilizar algumas das funções mais recorrentes da API da Unity. Hoje irei dar continuidade à série explicando sobre algo muito relevante em relação à engine: A ordem de execução de eventos.
O que são eventos:
Antes de entrarmos de fato nesse assunto, vou explanar rapidamente o que seriam os tais "eventos".
Em programação orientada a eventos, um event (evento) nada mais é que uma função como outra qualquer, com a diferença na forma como ela é chamada.
Funções "comuns" são chamadas "manualmente", como fizemos com todas as funções do tutorial anterior, ou seja, são chamadas em tempo de compilação.
Já no caso de eventos, eles podem ser chamados em momentos específicos, no caso da Unity, a própria engine fica encarregada de gerenciar essas chamadas de alguns eventos específicos de sua API, ou seja, nós como usuários não temos controle de quando eles(os eventos) serão invocados, pois eles são chamados em tempo de execução.
Podemos ter eventos que são chamados quando passamos o mouse sobre algum objeto, outro evento que é invocado quando clicamos com o lado esquerdo do mouse, ou até mesmo quando alteramos um campo dentro de um componente de UI (vide o InputField, por exemplo).
Perceba que nós como usuários da Unity não temos um real controle de quando essas funções são chamadas, quem se encarrega de gerenciar tais eventos, é a própria engine.
Eventos de inicialização:
Dito isto, perceba que sempre que criamos um novo script na Unity, o nosso código além de fazer referencia às bibliotecas necessárias, definir a classe do script e a herança do MonoBehaviour, ainda por cima sempre declara duas funções padrões: Start e Update.
Por conta de suas chamadas serem realizadas a partir da engine, que é responsável por gerenciar essas ações, podemos classificar ambas funções como eventos.
Sabemos que o Start é chamado quando o objeto é inicializado, e que o Update é chamado muitas vezes por segundo, mas será que é só isso?
Além do Start, ainda temos outros dois eventos responsáveis pela inicialização de Game Objects, são eles: Awake e OnEnable.
Na verdade, esses dois eventos são chamados ANTES do Start. A ordem de execução destes eventos de inicialização é esta:
Awake: O evento Awake é chamado assim que o objeto é instanciado e ativado em cena, no primeiro frame de carregamento. É o primeiro evento de inicialização a ser invocado.
Ele é chamado apenas uma vez, a não ser que se recarregue a cena ou que a mesma seja carregada de forma aditiva.
Se o Game Object que contiver o Awake estiver desativado, e depois ser ativado, ele vai invocar o Awake (pela primeira vez), porém, caso o script que contenha o evento Awake estiver desativado, o Awake será chamado mesmo assim.
Essa é uma grande confusão que ocorre às vezes: Existe uma diferença entre desativar/ativar o Game Object em si, e algum script/componente que ele comporte: O Awake é chamado assim que o Game Object for ativado, porém, ele será invocado MESMO que o script que o contenha estiver desativado.
Utilize o Awake como inicializador para o próprio script, seja para inicializar variáveis ou obter componentes dependentes. É como se fosse o construtor de classes "nativas" do C#.
Exemplo de uso:
C #:
private void Awake()
{
// Obtendo componentes dependentes:
_objectRigidbody = GetComponent<Rigidbody>();
// Inicializando valores de variáveis:
_characterLife = 10;
_isAlive = true;
}Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Awake.html
OnEnable: É invocado assim que o objeto é ativado em cena e o seu script habilitado, porém, após a chamada do Awake.
Toda vez que o script é inabilitado e depois habilitado novamente, o OnEnable será chamado, assim como quando o Game Object for desativado e ativado, ele novamente será invocado, ao contrário do Awake que é chamado apenas uma vez durante o ciclo de vida do script.
Você pode utilizar esse evento para gerenciar algo que ocorre toda vez que o objeto ou o script são ativados (como a reinicialização de variáveis, por exemplo):
C #:
using UnityEngine;
public class Test : MonoBehaviour
{
public int example;
private void OnEnable()
{
example = 0;
}
private void Update()
{
example++;
}
}No exemplo acima, a variável "example" é setada com o valor zero quando o Game Object é ativado, a partir daí o Update incrementa esse valor. Quando você desativa o script ou o Game Object e o reativa, a variável "example" é resetada para o valor zero novamente.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnEnable.html
Start: O evento Start é chamado apenas uma vez, após o Awake e o OnEnable.
Ele é chamado assim que o Game Object está ativo em cena e o script que o contém esteja habilitado.
Você pode utilizar esse evento para inicializar a comunicação com objetos ou scripts externos, que já tiverem a sua inicialização através do Awake.
Dessa forma, você tem dois momentos para controlar uma inicialização, caso necessite, se a ordem de inicialização de algum componente, objeto, ou valor importe.
Você pode "atrasar" a inicialização do Start através de Coroutines, por exemplo:
C #:
using UnityEngine;
using System.Collections;
public class Test : MonoBehaviour
{
private IEnumerator Start()
{
yield return new WaitForSeconds(3);
Debug.Log("Atrasando a chamada do Start");
}
}No caso do exemplo acima, o Start será chamado após 3 segundos.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html
Eventos de Atualização:
Agora vamos falar um pouco sobre os eventos que são invocados em dependência da taxa de frames do jogo/projeto:
FixedUpdate: Este evento é chamado num controle fixo de frames per second, estipulado pela engine de física da Unity.
Ele pode ser chamado com mais frequência que o Update, ou com menos frequência (por isso o fluxograma acima pode às vezes ser invertido em alguns casos), pois nós podemos definir a taxa de quadros em que o FixedUpdate poderá ser chamado.
Para alterar a taxa de chamadas do FixedUpdate vá em >> Edit >> Project Settings >> Time >> Fixed TimeStep.
Por padrão o "TimeStep" é definido por 0.02, ou seja, o evento será chamada à cada 0.02 segundos.
A utilização do FixedUpdate é recomendada quando queremos gerenciar principalmente componentes de física, como o Rigidbody, por exemplo, pois como ele é chamado numa taxa fixa e precisa, não teremos problemas de irregularidades em cálculos da física do jogo (como aplicar a força num objeto de formas inconstantes à cada quadro):
C #:
using UnityEngine;
[RequireComponent(typeof(Rigidbody))]
public class Test : MonoBehaviour
{
public float jumpForce;
private bool isJumping;
private Rigidbody _objectRigidbody;
private void Awake()
{
isJumping = false;
_objectRigidbody = GetComponent<Rigidbody>();
}
private void Update()
{
isJumping = Input.GetKeyDown(KeyCode.Space);
}
private void FixedUpdate()
{
if (isJumping)
_objectRigidbody.AddForce(Vector2.up * jumpForce);
}
}Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html
Update: O evento de Update é muito utilizado em jogos, pois é um evento que será chamado muitas vezes por segundo.
No caso da Unity, o Update é chamado dependendo do frame per second do jogo, ele será chamado uma vez a cada quadro, logo, se o jogo está rodando à 60 fps, ele será chamado 60 vezes por segundo.
Utilizamos o Update quando queremos verificar ou validar algo que deva estar em constante observação, como o momento em que alguma tecla é pressionada durante o jogo para realizar alguma ação. A tecla pode ser pressionada a qualquer momento, por isso este tipo de verificação deve estar dentro de um evento de Update.
Por conta de suas chamadas inconstantes (depende muito do fps do jogo), não é recomendável utilizar comandos que necessitem de uma maior precisão, como cálculos de física, por exemplo, dentro do Update. Para estes fins você deve sempre estar multiplicando os valores a serem calculados por um fator multiplicador que irá tentar "padronizar" essa irregularidade de chamadas, no caso, temos o campo "deltaTime" acessado através da classe "Time".
Porém, é muito mais simples utilizar o FixedUpdate para estes casos, como visto acima.
C #:
using UnityEngine;
public class Test : MonoBehaviour
{
private void Update()
{
if (Input.GetKeyDown(KeyCode.Space))
Debug.Log($"A tecla {KeyCode.Space.ToString()} foi pressionada");
if (Input.GetKeyUp(KeyCode.Space))
Debug.Log($"A tecla {KeyCode.Space.ToString()} deixou de ser pressionada");
}
}No código acima, o Update detecta quando o jogador pressiona ou deixa de pressionar a tecla "Space" e emite uma mensagem para cada ação.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html
LateUpdate: Este evento é chamado sempre após o Update, e isso é algo positivo caso queiramos manter alguma ordem de execução para alguma ação (como no caso dos inicializadores).
A própria documentação da Unity sugere que o LateUpdate é perfeito para gerenciar o movimento de câmeras, visto que o Update/FixedUpdate será responsável por movimentar o personagem, o LateUpdate é chamado logo em seguida, ajustando a câmera após a movimentação do player.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.LateUpdate.html
*Todos os eventos de Frame-Rate serão chamados apenas enquanto o objeto estiver ativo em cena, e o script habilitado.
Eventos de destruição:
Existem dois eventos que gerenciam as ações para GameObjects que serão desativados ou destruídos:
OnDisable: Este evento será chamado assim que o objeto se tornar inativo, ou seu script desabilitado, sendo oposto ao OnEnable.
O OnDisable também será chamado assim que o objeto ou seu script/componente for destruído (tanto por conta de funções como "Destroy", quanto quando a cena se encerrar).
C #:
using UnityEngine;
public class Test : MonoBehaviour
{
private void OnDisable()
{
Debug.Log("Objeto desabilitado");
}
}OnDestroy: O evento "OnDestroy" será chamado assim que o objeto for destruído ou seu script/componente, após a chamada do "OnDisable".
Isso lhe dará uma ordem de execução para a destruição do objeto, assim como no caso dos inicializadores, se a ordem de chamadas para tal ação for importante, por exemplo.
Exemplo de uso do OnDestroy:
C #:
using UnityEngine;
public class Test : MonoBehaviour
{
public GameObject _explosionAnimation;
private void OnDestroy()
{
Instantiate(_explosionAnimation,
this.transform.position, Quaternion.identity);
}
}No exemplo acima, quando o Game Object for destruído, um prefab contendo uma animação de explosão será instanciado na mesma posição que o objeto destruído.
Documentação oficial: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnDestroy.html
Lembrete:
*Lembrando que os eventos mostrados neste tutorial só serão invocados de forma correta, caso estejam contidos dentro de uma classe que herde de MonoBehaviour, pois é a partir desta classe que a Unity pode gerenciar a chamada destes eventos, e também é a partir deste tipo de classe que os scripts se tornam componentes, sendo assim, sua inicialização, atualização e destruição só poderão ocorrer quando estiverem contidos num objeto em cena.
Você pode declarar funções com os nomes dos eventos aqui mostrados em classes que não herdem de MonoBehaviour, porém elas não vão funcionar da forma esperada (não serão chamadas como mostrado ao longo do tutorial) e isso não é considerado uma boa prática.
Finalização:
E aqui chega ao fim mais um tutorial sobre programação na Unity! Espero que este tutorial possa sanar de uma vez por todas as dúvidas que os usuários tanto iniciantes quanto avançados tem em relação a estes eventos, suas diferenças e ordem de execução.
Próximo tópico do guia >> "MonoBehaviour x Classes Nativas"
Última edição:
