Compartimento MVC-like em jogos? [fechadas]

Eu estava contemplando o design de um jogo (traduzindo um jogo de tabuleiro para o computador, especificamente, o que suponho ser relevante neste caso) e me ocorreu que poderia fazer sentido criar o 'jogo' separado da 'exibição'.

Permitir-me-ia criar um protótipo de algo rapidamente com uma interface de texto simples, e depois abordar isso mais tarde. Isso também me permitia portar o jogo para outras mídias mais facilmente.

Esse tipo de compartimentação é comum nos jogos? Devo tentar quebrar as coisas ainda mais? Existem complicações que podem estar faltando?

Um jogo de tabuleiro é um bom exemplo de um jogo que pode ser feito usando o MVC, pois a lógica do jogo (modelo) existe independentemente dos visuais (exibição). No entanto, se você considerar um jogo de ação como Gears of War, a geometria dos modelos 3D é intrínseca à lógica do jogo, portanto, separar a vista como se fosse intercambiável se torna inútil. O Unity3D é um ótimo exemplo de uma maneira mais específica de organizar o código. Você tem uma classe de entidade base na qual você adiciona funcionalidade aos componentes, onde um componente pode lidar com o desenho da entidade, outro com lógica de jogo etc. Confira estas famosas postagens de blog sobre o assunto:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

Minha opinião:

• O modelo é onde está a maioria dos dados e toda a lógica ocorre.
  Ele lê uma fila de eventos de entrada e modifica o estado do jogo de acordo.
  Em seguida, processa coisas como física e outros componentes principais que também atualizam o estado do jogo.
  Ciclo. Isso é tudo.
  O objetivo é tornar o modelo independente: ele não depende da visão ou do controlador: você deve poder criar um programa que execute apenas um modelo.
• A visualização simplesmente lê o estado do jogo do modelo, atualiza seus próprios componentes dedicados à representação dos dados e exibe itens na tela.
  Ele nunca grava nada no modelo, é um processo somente leitura, exceto talvez o registro de algum manipulador de eventos (como "Hey Mister Model, quando você detecta uma colisão entre esses dois objetos, chame meu manipulador de eventos que reproduz um som!" ").
• O controlador captura eventos de entrada e os passa para a fila de entrada do modelo. Ele lê a visualização (o clique deste botão aconteceu em um botão da interface do usuário?).

Dessa forma, você pode conectar um controlador falso que lê um arquivo que contém eventos de entrada pré-gravados.
Faça também uma visão simples que apenas registra as coisas em um arquivo.
Muito útil para teste e depuração.

Lembre-se de fazer a atualização do modelo a uma taxa constante (etapa de tempo fixo) e a visualização e o controlador o mais rápido possível (mas não muito variável).

Esse tipo de compartimentação é a divisão entre um mecanismo e um código de jogo e é bastante comum. Há muito espaço para abstração ao longo do caminho.

Os dados gráficos específicos de seu mecanismo e de seus jogos podem ser considerados como o modo de exibição, o código de jogo, o modelo e o controlador seria a cola que você usar para informar ao mecanismo qual textura aplicar a qual entidade do código de jogo.