MVC na Unity

MVC pode corrigir a falta de organização na forma de se trabalhar desenvolvendo jogos, que pode custar caro, limitando até mesmo o potencial dele.

Mas, uma das maiores preocupações é mandar o core central do software.

E que seja de forma que todos possam compreender claramente os scripts e o funcionamento.

Pois, afinal, se você trabalha em uma empresa, outras pessoas precisam entender como o sistema do seu jogo funciona.

E assim poder prestar manutenção e melhorias futuras, caso o projeto necessite.

MVC: Padrões de design de software

Com os padrões de designs, podemos unificar a forma de se trabalhar para todos.

E garantindo assim a compreensão comum, sobre o funcionamento dos sistemas criados.

E em jogos, por exemplo, temos diversos sistemas trabalhando em conjunto.

Por exemplo uma parte do código cuida do jogador, outros menus, I.As de inimigos, sistema de dano, etc.

E imagina vários programadores trabalhando isoladamente em cada uma delas e depois tentando unir tudo.

Ou seja, logo com padrões de projetos isolamos as partes centrais facilitando todo esse processo.

MVC: EC (Entidade-Componente)

É um padrão usado na Unity onde são definidos quais as entidades e componentes que algo terá.

Por exemplo: na Unity temos um game object Cubo, ele é uma “Entidade”.

E que nele podemos anexar diferentes “Componentes” com características distintas como: Rigidbody, box collider, animator, etc.

Ou seja, temos uma “Entidade” que pode se comportar de maneiras diferentes a depender do “Componente anexado”.

Mas esse conceito se estende até para a codificação de scripts.

Herança

Na programação podemos usar um conceito chamado “Herança”, onde criamos uma classe “Pai”, contendo as características base.

E posteriormente podemos criar classes “Filhas” que herdam da classe base.

Mas que por sua vez, a modificam conforme a necessidade.

E como cada classe Herdeira faz modificações no funcionamento base, caso sejam anexadas em um mesmo GameObject, podemos enfrentar problemas.

Porém, isso se complica quando temos vários programadores trabalhando em um sistema.

E todos começam a gerar classes herdeiras de uma classe base.

E logo com tantas classes herdeiras fazendo suas próprias modificações, surge o problema do “Diamante”.

Por exemplo: uma classe D, herda de duas classes, B e C, com a mesma classe base A.

E isso pode acarretar inúmeros bugs inesperados em seu jogo, então padrões como o MVC nos ajudam nesse problema.

O “Model” representa a lógica do jogo e os dados sobre regras, mecânicas, algoritmos e estruturas de dados.

A “View” é responsável pela apresentação dos dados do jogo e pela interação com o jogador, exibindo as informações de uma maneira compreensível para ele.

O “Controller” atua como intermediário entre o Model e a View, recebendo as entradas do usuário (como pressionar um botão) da View e as utiliza para atualizar o Model.

Aplicando MVC na Hierarquia

A hierarquia da Unity pode se tornar um caos a medida que o seu projeto cresce, com componentes de todos os tipos misturados.

E podemos aplicar desde aqui o padrão MVC.

Pois, criamos um Game Object Application e dentro dele outros 3: Model, View e Controller.

E que por sua vez guardarão os respectivos objetos alinhados com suas funções.

Por exemplo, em Model ficará todos os GameObjects relacionados a sistema que geram dados: Game Manager, SoundManager, etc.

Mas, em View ficará o restante dos objetos e elementos da cena do jogo: câmeras, chão, inimigos, player, etc.

Problema de referência

Na Unity precisamos arrastar objetos para variáveis no inspector ou busca-lo via script.

Mas e se por algum motivo seu inspector, perder todas as referências rodando na maquina do usuário?

E por isso o MVC é importante, pois, podemos criar um sistema só para guardar essas referências.
E evitar um crash do jogo em caso de urgência.

Pois, o Application será o “contêiner” principal e dentro dele todos os outros objetos estarão devidamente organizados.

Em SubContêiners Model, View e Controller, que guardarão respectivamente todos os outros objetos da cena.

MVC: Trabalho Organizado

Outra grande vantagem, seria trabalhando com mais de um programador, padronizando os endereços dos objetos que precisam ser manipulados.

Por exemplo, você precisa adicionar um novo save via script da pontuação do jogador.

E nesse caso o endereço seria: Application.Model.GameData.Save(25);

E dessa forma o caminho fica muito mais claro e organizado, para encontrar o que você precisa acessar:

Dados: Ir para application > model > …

Lógica/Fluxo de trabalho: Ir para application > controller > …

Renderização/Interface/Detecção: Ir para application > view > …

MVC: Partindo para o Código

Até agora olhamos apenas para a hierarquia, mas precisamos levar o MVC para a codificação também.

E aqui cada Game Object criado para Application, Model, Controller e View, precisam ter também os seus scripts (classes) respectivas.

E então criamos a Classe Application, e dentro dela variável para Model, Controller e View.

Pois, assim a classe Application terá acesso direto para essas 3 classes.

E seguindo, usamos a mesma lógica: dentro de Model, teremos variáveis relacionadas a todas as classes.

Mas que terão a função Model no jogo: ModelPlayerData, ModelMenuController, ModelSoundManager.

E na Classe View o mesmo, adicionando variáveis para todas as classes relacionadas a função View.

Ou seja, dessa forma cada sistema que for criar, você irá pensar classificando ele em MVC.

E adicionar a tag Model, Controller ou View antes do seu nome na classe, de acordo com sua função.

CLASSIFICAÇÃO DE CLASSES

Dessa forma apenas as Classes Model, ficam responsáveis por manipular, dados e a lógica base do jogo.

As classes tageadas com Controller apenas receberão dados da model e passarão para a classe view exibir, e vice-versa.

E por fim as classes Viewrs apenas capturam dados e exibem ao jogador.

E recebem a resposta do jogador, devolvendo esses dados para o controller moderar e entregar para as classes Models.

Mas, pode ser bem difícil definir em qual padrão uma classe ou objeto de jogo se encaixa melhor.

Pois, algumas definições podem deixar essa distinção mais prática e fácil de se perceber.

Model

• Mantem os dados principais e o estado do jogo, como jogador.helth, skills, etc.
• Serializar, desserializar e/ou converter entre tipos.
• Carregar/salvar dados (localmente ou na Web).
• Notificar os controladores sobre o andamento das operações.
• Armazene o estado do jogo para o StateMachine do jogo.

View

• Pode obter dados de modelos para representar o estado atualizado do jogo para o usuário.
• Nunca deve mutar modelos.
• Implementa estritamente as funcionalidades de sua classe.
• Um Modo de View deve atuar como uma caixa preta que tem uma interface e notifica eventos importantes.
• Não armazena dados principais (como velocidade, saúde, vidas,…)

Controller

• Não armazena dados principais.
• Às vezes, pode filtrar notificações de Exibições indesejadas.
• Atualiza e usa os dados do modelo.
• Gerencia o fluxo de trabalho de cena do Unity.

Com toda estrutura do MVC aplicada em seu projeto fica muito mais fácil de se trabalhar com um ou mais programadores no mesmo projeto.

Pois, é possível dividir o trabalho em programadores que cuidem da parte modal do projeto.

E que irão manipular a alterar tudo relacionado ao núcleo central de código.

E outros que fiquem com a parte mais Viewr.

Codificando e trabalhando apenas em como esses dados transitam da parte Model para serem exibidas ao usuário, e vice e versa.

E sem contar que via script temos um acesso extremamente organizado do que são scripts View, modal e controller.

E Entender o MVC a principio pode parecer complexo, mas ao ser aplicado o desenvolvimento do seu jogo se torna muito mais eficaz.

Quer aprender a criar o seu primeiro jogo saindo do zero, mesmo que nunca tenha tido experiencia antes?

O curso Start Gamedev foi feito pra você, e o melhor você paga um preço extremamente baixo para dar seu primeiros passos!

Clique neste texto para conhecer o curso, ou assista a uma review completa logo abaixo!