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

19

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?

Asmor
fuente

Respuestas:

7

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

Iain
fuente
MVC puede funcionar bien para FPS, consulte gamasutra.com/features/20050414/rouwe_01.shtml para al menos una referencia.
stonemetal
3
"... la geometría de los modelos 3D es intrínseca a la lógica del juego ..." Por lo tanto, la geometría se convierte principalmente en datos del modelo para ser manipulados por el controlador (en este caso, afecta a la física, por lo que existe con todas las demás físicas parámetros) para fines de lógica de juego. Si también se utiliza para la vista, como en este caso, eso se considera secundario, ya que la verdadera simulación es el controlador que afecta al modelo; La vista es irrelevante. (Algunos cuestionan si los datos de configuración deberían existir en el modelo; depende de usted, pero el principio sigue siendo el mismo). Este es un enfoque purista.
Ingeniero
5

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).

Splo
fuente
0

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.

Ziplin
fuente
2
Esto no es del todo cierto. MVC define la separación de estado (el modelo) de la interfaz de usuario (la vista y el controlador). Un "motor" es un marco genérico sobre el cual se pueden construir juegos, y podría contener los elementos básicos para el modelo, la vista y el controlador.
MikeWyatt