Console.Write("Hello World!");
Olá queridos corações valentes! Tudo bem com vocês?
Hoje estou aqui para postar mais um tutorial de nossa série de guia rápido de programação!
Na postagem anterior falamos sobre eventos nativos da engine e sua ordem de execução de chamada, algo de muita importância, pois, através destes eventos nós podemos iniciar, atualizar ou deletar (destruir) componentes de objetos de cena.
Lembre-se que estes eventos apenas funcionam da maneira correta quando estão dentro de uma classe que herda de Monobehaviour.
Porém, você deve estar se perguntando: "Essa tal classe "Monobehaviour" é tão importante assim?"
E a resposta que eu tenho para vocês é: SIM, muito importante! Uma classe dessas merece uma postagem apenas para ela.
Farei também uma comparação entre classes que derivam de Monobehaviour e as classes nativas do C#.
O que são Objetos de Jogo?
Antes de falarmos sobre as classes de Monobehaviour, vamos entender primeiramente o que são objetos de jogo (ou Game Objects).
Os objetos de jogo na Unity são todos aqueles objetos que você vai criar para a sua cena; eles são os responsáveis pelos comportamentos e características de tudo o que vai compor os elementos do game, desde personagens, cenário, efeitos (como partículas ou luzes), componentes de interface gráfica (UI), câmera, e etc.
Os game objects possuem em sua essência a prática da composição, ou seja, você pode conceber objetos diferentes, com características e comportamentos distintos, graças aos seus componentes anexados.
Todo objeto de jogo terá obrigatoriamente um componente chamado "Transform", que se trata de uma classe que gerencia a posição, rotação e escala do objeto em cena:
Você pode adicionar ou remover outros componentes aos objetos de jogo e é isso que o tornará único.
O que são Componentes?
Os componentes na Unity nada mais são que os scripts que você vai escrever para criar as ações e propriedades dos objetos. São também os componentes nativos da própria engine, como o Rigidbody ou Mesh Renderer, por exemplo.
Você pode adicionar componentes através da interface do programa clicando na opção "Add Component" (através do inspetor) e digitando na barra de pesquisas o nome do componente, ou simplesmente arrastando o mesmo diretamente para o inspetor. Via código adicionamos um componente a partir da função "AddComponent".
(Adicionado componentes através da interface)
C #:
void Start(){
{
this.gameObject.AddComponent<BoxCollider>();
}(Adicionando componente via código programado)
Você também pode remover componentes, tanto através da interface (clicando no ícone da engrenagem no inspetor e indo à opção "Remove Component)", quanto por código utilizando a função "Destroy".
(Removendo componente através do inspetor)
Você também pode remover componentes, tanto através da interface (clicando no ícone da engrenagem no inspetor e indo à opção "Remove Component)", quanto por código utilizando a função "Destroy".
(Removendo componente através do inspetor)
C #:
Destroy(this.gameObject.GetComponent<BoxCollider>());(Removendo componente por código)
Por fim, você pode ativar ou desativar esses componentes.
Na interface, basta ir ao inspetor e marcar (para ativar) ou desmarcar (para desativar) a caixa ao lado do nome do componente:
(Ativando e desativando um componente através do inspetor)
Por código, utilizamos o campo "enabled" para definir o estado do componente. Caso seja "true" o componente está ativado, no caso de "false", desativado:
C #:
public void OnClickButton(){
this.enabled = false;
}(Desativando componente a partir do click num botão)
Você pode fazer acesso a estes componentes dentro de seus códigos, basta utilizar a função "GetComponent", como visto no primeiro tutorial dessa série.
Os componentes vão fazer com que os objetos se tornem únicos dentro do seu jogo.
Você pode por exemplo ter dois game objects que possuem componentes semelhantes (colisores, renderizadores e corpo rígido, por exemplo) só que em um deles você anexou um script(componente) de movimentação através do Input do usuário, e no outro um componente de movimentação aleatória.
Mediante a este exemplo temos dois objetos diferentes, pois um se move através dos comandos do usuário, e o outro de forma pré-definida pelo script.
Os componentes na Unity são de suma importância, pois através deles você pode compor objetos diferentes, como dito anteriormente, criando assim infinitas possibilidades de objetos diferentes para o jogo.
No geral, podemos dizer que um game object nada mais é que um objeto que contém diversos componentes anexados a ele.
A classe Monobehaviour:
Vejamos o que a própria documentação da Unity diz a respeito dessa classe:
Caso seu inglês esteja enferrujado, a documentação diz:
"Monobehaviour é a classe-base que todo script na Unity deriva.
Quando você está usando C#, você deve explicitamente herdar de MonoBehaviour".
E agora você deve estar se perguntando... "Então só podemos usar scripts C# que derivem de Monobehaviour? Não posso utilizar classes que derivem de outras, ou até mesmo sem derivar de nenhuma outra classe?"
A resposta é simples: Sim, você pode criar classes dentro da Unity sem que elas derivem de Monobehaviour sem problema algum, aliás muitos projetos se utilizam de tais classes para manipular algo interno à lógica do game que não tange apenas a código para componentes, mas sim para outros propósitos, como a manipulação de objetos nativos do C# (sem que sejam objetos de jogos da Unity), ou até mesmo a criação de classes estáticas, por exemplo.
Porém qual a diferença entre um script/componente e uma classe nativa do C#?
A começar que uma classe na Unity pode apenas se tornar de fato um componente se ela herdar da classe Monobehaviour, ou seja, você só pode adicionar, remover e desativar/ativar estes componentes (seja via código ou interface do programa) se os mesmos forem classes filhas da super-classe: Monobehaviour.
Por isso que quando você cria um novo script dentro da Unity e ao abri-lo em seu editor favorito, a classe por padrão possui a herança em Monobehaviour, isso porque, a Unity entende que você está tentando criar um componente para seus objetos de cena:
A partir desta herança o script pode ser tratado como componente, ou seja, ele poderá ser anexado ou desanexado de um objeto de jogo, bem como poderá se utilizar das funções e eventos padrões que a super-classe gerencia, tais como: Start, Awake, Update, FixedUpdate, OnGUI, OnDestroy, OnCollisionEnter, e etc.
Scripts que herdam de Monobehaviour também podem possuir campos herdados dessa classe, como por exemplo uma instância da classe "Transform", que por sua vez possui acesso a propriedades e métodos desejáveis a um objeto de cena, a exemplo comum, sua posição no mundo:
C #:
void Update(){
var currentPosition = this.transform.position;
}Outro campo que herdamos de Monobehaviour é a instância da classe "GameObject", que nada mais é do que a instância daquele objeto de cena dentro do código-fonte da API da Unity, que possui propriedades relevantes daquele objeto, tais como: seu nome, sua tag e seu layer, e etc.
C #:
void Start(){
newName = this.gameObject.name + this.gameObject.tag
this.gameObject.name = newName;
}(Renomeando um objeto através de seu nome + sua tag referida)
Classes Monobehaviour x Classes padrões:
Desde que sabemos que classes herdadas de Monobehaviour são tratadas como componentes para a Unity e se utiliza de diversos métodos, eventos e campos de sua API, podemos dizer que os objetos de cena (que são compostos por diversos componentes) são diferentes das instâncias das classes "padrões/nativas" do C#.
Isso significa que por existir esta diferença, não podemos confundir objetos de jogo (Game Objects) com os objetos em C#.
Vejamos algumas de suas diferenças a seguir fazendo um paralelo a cada tipo de objeto:
Diferença 1 - Acesso a propriedades, métodos, eventos e etc:
A primeira e grande diferença é como fazemos acesso a campos entre esses dois tipos de classe: Enquanto numa classe "padrão" nós acessamos esses campos explicitamente através de sua instância, em objetos de cena fazemos acesso a seus componentes, ao invés de uma instância dos mesmos
Acesso de um método a uma instância:
C #:
objetoHeroiDeJogo.Atacar();Acesso a um componente de objeto de jogo:
C #:
this.GetComponent<AttackScript>().Atacar();Diferença 2 - Instância:
Na Unity nós instanciamos um objeto de jogo ao criá-lo diretamente na cena, ou dinamicamente (em tempo de execução) através da função "Instantiate", já no caso de classes padrões, nós instanciamos tais objetos através da palavra reservada "new":
C #:
Hero _hero = new Hero();Instanciando um Game Object dinamicamente em cena através do Instantiate:
C #:
var _hero = Instantiate(heroPrefab, transform.position, Quaternion.identity);Veja que para instanciar um objeto de jogo, além da função Instantiate, ainda precisamos de um prefab/referência do objeto a ser instanciado em cena.
(Para mais informações sobre esta função, consulte o link a seguir: Clique aqui)
Diferença 3 - Construção/Destruição da classe:
Em C#, as classes ao serem instanciadas, imediatamente chamam seus devidos construtores, estes podem ter alguma implementação ou não, porém sempre são chamados. Ao mesmo passo que, quando uma classe é destruída pelo Garbage Collector do .Net, o destrutor desta classe também é chamado.
Já no caso de classes do tipo "MonoBehaviour", não temos um construtor ou destrutor para estas classes, neste caso, suas alternativas como componentes são as já mencionadas funções "Start/Awake" para inicialização e "OnDisable/OnDestroy" para sua destruição.
C #:
public class Exemplo{
public Exemplo(){
// Implementação de inicialização da classe
}
~Exemplo(){
// Implementação da destruição/limpeza do objeto
}(Implementando um construtor e destrutor para classe C#)
C #:
public class Exemplo : MonoBehaviour{
private void Awake(){
// Implementação de inicialização do script
}
private void OnDestroy(){
// Implementação da destruição/limpeza do script
}(Implementando a inicialização e destruição do script)
Diferença 4 - Herança:
Como sabemos, em C# a herança múltipla não é suportada, ou seja, não podemos herdar de mais uma classe simultaneamente.
Devido a esta restrição, classes Monobehaviour já são classes que possuem uma herança direta, diferente de outras classes em C#, portanto a alternativa que temos para herdar de outras classes em scripts Monobehaviour seria a técnica da herança em cascata, ou seja, a super-classe herda de Monobehaviour e as sub-classes herdarão da sua super-classe e ao mesmo tempo de Monobehaviour (não deixando de ser um componente), por exemplo:
Classe-pai:
C #:
public class Character : MonoBehaviour{}Classes-filhas:
C #:
public class Player : Character{}
C #:
public class Enemy : Character{}Dessa forma as sub-classes "Player" e "Enemy" herdam comportamentos da super-classe "Character" que por sua vez, também herdam de "Monobehaviour", já que a classe "Character" faz herança da mesma, dessa forma, essas duas classes serão tratadas como componentes, portanto, poderão ser adicionadas a objetos de jogo.
Finalização:
A API da Unity é bastante extensa e complexa, claro que existem ainda diversas diferenças de implementação, manipulação e comportamentos entre objetos de jogo e objetos nativos do C#, porém eu quis salientar neste tópico apenas as diferenças mais exacerbadas e evidentes que podem acabar por confundir os programadores de plantão em relação ao tratamento e gerenciamento de classes "comuns" e classes de componentes da Unity. Fique a vontade para explorar mais dessas diferenças (e até semelhanças) e quem sabe deixar aqui seu feedback de colaboração!
No mais, aqui chega ao fim mais um tutorial do guia rápido de programação na Unity! Espero que tenham gostado de mais este conteúdo, e até a próxima. ❤
Próximo tópico do guia >> Resumo sobre os componentes mais relevantes da Unity e como manipulá-los via script
Anexos
Última edição:
