¿Arquitectura del marco de juego - ver componentes o MVC?

Question

Estoy tratando de construir un marco muy ligero y reutilizable para mis juegos, en lugar de empezar desde cero cada vez que comienzo un juego. Tengo una arquitectura dirigida por componentes, por ejemplo, La entidad compone un componente de Posición y un componente de Salud y un componente Ai, etc.

Mi gran pregunta es si mi modelo compone los componentes de vista para permitir más de una vista del modelo, o si usar un MVC más verdadero donde el modelo no conoce sus vistas, y se gestionan externamente.

He probado ambos métodos, pero si alguien conoce los pros y los contras de cada enfoque y cuál es el estándar de la industria, sería bueno saberlo.

Answer 1

depende de su audiencia, los desarrolladores de juegos, yo mismo no estoy muy acostumbrado al modelo MVC, aunque la mayoría lo sabe, no es tan fácil mantenerlo limpio, debido a las bajas en el desarrollo (no por razones técnicas serias). Así que por experiencia, he visto docenas de marcos de juegos que comienzan como MVC, pero solo un par pudo mantenerlo hasta el final. Mi teoría es que MVC agrega demasiada complejidad y pocos beneficios para los juegos pequeños desechables (con normalmente algunos desarrolladores), y es muy difícil mantener la mayoría limpia de los objetos del juego en estas capas para juegos grandes / complejos. Y dado que los juegos tienen una fecha de lanzamiento, muchas veces sacrifican la claridad del código y la reutilización del rendimiento y las soluciones adhoc rápidas (que se reescribirán si es necesario en la secuela (si la hay)).

Sin embargo, con la advertencia anterior, es mejor apuntar alto, porque si tienes éxito, es mejor :) y si fallas, bien o mal. Así que probablemente deberías probar el MVC, pero no te preocupes si falla, todos los desarrolladores de juegos profesionales han fallado en la tarea muchas veces :)

Answer 2

Sin duda, votaría a favor del modelo para que no sepa nada sobre sus puntos de vista. El acoplamiento suelto es bueno: código de modelo más simple, pruebas más fáciles, más opciones.

Answer 3

Sé que esta pregunta puede estar desactualizada, pero necesito responderla. En realidad, comencé a programar un juego en Lua (con LÖVE) y comencé a programar un MVC - Framework para él. Al principio, usar MVC realmente depende de lo que quieras. Sé que mis problemas con la programación de juegos, cuando el programa se hace más grande, y en su mayoría la estructura se vuelve demasiado compleja de mantener. Lo siguiente es que sé que cambiaré todos los gráficos cuando encuentre un artista que esté dispuesto a trabajar para ello. Pero hasta entonces, voy a usar mis propios gráficos ficticios. Quiero que el artista se sienta libre de hacer lo que quiera, sin depender de ninguna resolución o restricción de color. Eso significa que podría tener que cambiar el código de presentación completo (!). Tal vez incluso la forma en que interactúan los objetos (detección de colisiones, por ejemplo). La lógica del juego está capturada en los modelos, así que puedo concentrarme en eso. Y creo que la lógica del juego es la parte más importante de hacer un juego. ¿No es así? Espero que veas mi punto.

Pero, si lo tienen todo juntos: todos los gráficos, sonidos, todo esto; entonces puedes codificar directamente.

Mi MVC es una configuración-sobre-convención-asno, que ralentiza un poco el prototipo. PERO (!) Iteraciones de desarrollo pueden hacerse mucho más fácilmente. Las pruebas, especialmente las pruebas unitarias, se hacen mucho más rápido. Yo diría que MVC convierte tu curva de velocidad de desarrollo (que normalmente es una curva anti-exponencial) en una curva exponencial. Lento al principio, pero más y más rápido al final.

Answer 4

MVC funciona muy bien para juegos, al menos para mis juegos diseñados para multiplataforma. Realmente depende de cómo lo implementes para obtener el beneficio.