¿Compartimentación como MVC en los juegos? [cerrado]

Estaba contemplando el diseño de un juego (traducir un juego de mesa a la computadora, específicamente, lo cual supongo que es relevante en este caso) y se me ocurrió que podría tener sentido construir el 'juego' separado de la 'pantalla'.

Me permitiría crear un prototipo de algo rápidamente con una interfaz de texto simple, y luego ir más allá. También me permitiría transferir el juego a otros medios más fácilmente.

¿Es este tipo de compartimentación común en los juegos? ¿Debería tratar de desglosar más las cosas? ¿Hay complicaciones que pueda estar perdiendo?

Un juego de mesa es un buen ejemplo de un juego que podría hacerse usando MVC, ya que la lógica del juego (modelo) existe de manera bastante independiente de las imágenes (vista). Sin embargo, si considera un juego de acción como Gears of War, la geometría de los modelos 3D es intrínseca a la lógica del juego, por lo que separar la vista como si fuera intercambiable se vuelve inútil. Unity3D es un gran ejemplo de una forma más específica de organizar el código del juego. Tiene una clase de entidad base a la que agrega funcionalidad con componentes, donde un componente puede manejar el dibujo de la entidad, una lógica de juego, etc. Consulte estas famosas publicaciones de blog sobre el tema:

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

http://gameprogrammingpatterns.com/component.html

Mi opinión sobre esto:

• El modelo es donde reside la mayoría de los datos y tiene lugar toda la lógica.
  Lee una cola de eventos de entrada y modifica el estado del juego en consecuencia.
  Luego procesa cosas como la física y otros componentes principales que también actualizan el estado del juego.
  Lazo. Eso es todo.
  El objetivo es hacer que el modelo sea independiente: no depende de la vista o del controlador: debería poder crear un programa que solo ejecute un modelo.
• La vista simplemente lee el estado del juego del modelo, actualiza sus propios componentes dedicados a la representación de los datos y muestra cosas en la pantalla.
  Nunca escribe nada en el modelo, es un proceso de solo lectura, excepto tal vez el registro de algún controlador de eventos (como "Hey Mister Model, cuando detecte una colisión entre esos dos objetos, ¡llame a mi controlador de eventos que reproduce un sonido! ").
• El controlador captura los eventos de entrada y los pasa a la cola de entrada del modelo. Lee la vista (¿se hizo clic en este botón en un botón de la interfaz de usuario?).

De esa manera, puede conectar un controlador falso que lee un archivo que contiene eventos de entrada pregrabados.
También haga una vista simple que solo registre cosas en un archivo.
Muy útil para pruebas y depuración.

Recuerde realizar la actualización del modelo a una velocidad constante (paso de tiempo fijo), y la vista y el controlador lo más rápido posible (pero no demasiado variable).

Ese tipo de compartimentación es la división entre un motor y un código de juego, y es bastante común. Hay mucho espacio para la abstracción en el camino.

Su motor y los datos gráficos específicos de sus juegos podrían considerarse como la Vista, su código de juego, el Modelo, y el controlador sería cualquier pegamento que use para decirle a su motor qué textura aplicar a qué entidad en su código de juego.