Como utilizar o design pattern MVC na Unity?

Muito interessante a sua dúvida.

Apesar de algumas pessoas se referirem ao MVC como um ''design pattern'', eu acho que ele vai muito mais além que isso, na verdade pode ser referido como uma arquitetura, pois ele vai moldar a estrutura de toda a sua aplicação (ou maior parte dela).

Apesar de que, não é errado defini-lo como padrão de projeto, já que diversos autores assim o fazem e por também estipular um padrão a ser seguido.

Sobre sua dúvida, eu acho que no desenvolvimento de jogos temos essas camadas um pouco mais "explícitas" ou difundidas do que vemos no desenvolvimento web que pode parecer ser algo mais "abstrato", já que nos utilizamos (pelo menos na Unity) de componentes (classes herdadas do MonoBehaviour) para realizar as ações e comportamentos de objetos (oq poderia estar diretamente ligado ao Controller), claro, a possibilidade da utilização das estruturas convencionais da linguagem C# em classes de não-componentes ou até mesmo as classes gerenciadoras (como uma classe "Singleton", por exemplo), que podem definir a lógica e as validações da aplicação (oq se refere ao Model), sem dizer a parte gráfica como UI ou outros elementos gráficos que permitem a interface com o usuário (o View).

Lembrando um pouco das definições do modelo MVC, temos que:

Model: Comportamento lógico, regras de negócio da aplicação e armazenamento de dados;

View: Interface com o usuário, output das informações, feedback ao jogador que algo mudou/está mudando;

Controller: Controla a interação do usuário com a interface gráfica e instrui/notifica o view e o model com as ações determinadas mediante a essas interações (inputs).

Quer um exemplo bem bobo de um fluxograma de MVC?

Imagine q vc tem uma UI na Unity com dois elementos: um input field (onde o usuário pode colocar algum texto) e um botão.

Aqui estamos simulando um formulário de login (sem a senha haha) para o jogador logar na sua conta e poder jogar.

O jogador deve preencher seu nome de usuário nesse input field e validar essa informação, e quando ele estiver pronto, poderá clicar no botão para prosseguir.

Nossos objetos de UI (o input field e o button) são os objetos do view, que compõe a interface com o usuário.

Quando vc quer validar se o usuário existem e se ele está certo, vc pode querer ter uma regra de negócio, como por exemplo, só pode existir um usuário com o mesmo login, o nome de usuário não pode conter caracteres especiais, e deve ter mais de 4 caracteres para ser válido.

Para estruturar suas regras e lógica da aplicação, vc vai criar uma classe que vai manipular e verificar esses dados, onde vc valida se oq a pessoa digitou está dentro das suas regras, e em caso positivo, emitir um feedback ao usuário que o login dele foi um sucesso (output).

Para estruturar a classe que valida e também realiza a lógica de armazenamento de dados, vc vai se utilizar do model, pq é essa camada q define oq deve ser seguido nesse momento para que o login seja realizado.

Para receber as informações do usuário, vc vai receber oq a pessoa digitar dentro do input field (q está na camada de view) e vai enviar essa informação para oq está na camada de model (para realizar a validação), por isso aqui, temos o controller, que vai controlar essas ações e vai ser o intermediário (nesse caso) da camada view (preencher algo no input field) para a camada model (pegar esses dados e validar).

Quando a pessoa clicar no botão de "OK", estamos interagindo com o view, e passando pelo controller, pois ele quem gerencia as interações do usuário, lembra? Então o controller vai avisar à camada de modelo q o botão foi pressionado, e assim o model vai poder realizar as suas validações.

Independente se o usuário vai pode fazer login ou não (se ele passa ou não pelas validações dentro da camada 'model'), essa camada vai precisar notificar a camada view q algo está certo ou errado com o login.

Então por exemplo, digamos q temos um "text box" escondido num primeiro momento, e quando o login está errado, esse text apareça na tela escrito algo como "login incorreto, favor tentar novamente".

A camada model vai notificar a camada "controller" que algo deu errado com o login, assim a camada "controller" vai acionar alguma ação a ser realizada pela parte do view, nesse caso, ativar, o textbox de aviso e não deixar o usuário prosseguir com o login. 

Veja q temos o controller aqui como um mediador entre as duas camadas, algo q vemos muito na utilização do pattern Mediator, onde as mudanças de estados de um objeto são sempre repassadas para o mediador, q assim, notifica os outros objetos interessados dessa mudança.

Outro modelo mais direto q temos é onde o model notifica diretamente o view sobre as mudanças (oq quebra um pouco a estrutura do MVC).

E assim fechamos o fluxograma das camadas MVC.

O MVC é muito mais utilizado no desenvolvimento de estruturas web, mas como vc viu acima, também pode ser bem útil no desenvolvimento de jogos, apesar de que, essas camadas são mais perceptíveis neste último, pelos motivos já citados acima.

Sobre os design patterns mais utilizados para jogos, não é certo dizer exatamente quais são, pois dependendo do seu problema vc pode ter q utilizar algum "menos conhecido", mas eu posso te dar certeza de que esses a seguir são bastante úteis:

Abstract Factory

Que é meio oq temos na Unity com a representação de componentes e prefabs;

Strategy

Muito útil em diversas situações, principalmente para criarmos algoritmos para serem compartilhados com qualquer objeto sem nenhum tipo de dependência (e muito útil para chamar ou gerenciar as classes models);

Decorator

Meio que oq temos hj em dia com a Unity ao utilizarmos a adição e remoção de componentes diferentes dentro de objetos;

Singleton

Útil demais para classes gerenciadoras;

Observer

Caso vc queira estabelecer a comunicação entre objetos sem criar dependências (usada em conjunto com events do unity/c#)

*Pode ser através desse pattern q as notificações entre as camadas MVC podem ocorrer, viu?

Iterator

Interessante usar se vc tem q analisar ou percorrer uma coleção muito complexa.

Claro que, existem diversos outros patterns úteis por aí no dev de jogos, mas acredito q esses sejam de longe os mais essenciais, entretanto, caso queria conhecer os demais, tem tudo nesse site aí onde passei de referência para cada pattern, lá tem explicações desses padrões de uma forma bem didática e divertida, sem dizer q tem exemplos para diversas linguagens (incluindo C#, claro), então fica a dica da leitura para todos.

É isso aí, espero ter ajudado em algo com esse post. o/