Arquitectura de la arquitectura del juego: ¿ver componentes o MVC?

Question

Estoy tratando de construir un marco reutilizable muy ligero para mis juegos, en lugar de comenzar desde cero cada vez que empiezo un juego. Tengo una arquitectura impulsada por componentes, p. Entidad compone un componente de posición y un componente de la Salud y el componente Ai etc.

Mi gran pregunta es si mi modelo compone vista componentes para permitir más de una vista del modelo, o si se debe utilizar un MVC más cierto cuando el el modelo no conoce sus puntos de vista, y se gestionan externamente.

He intentado 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 genial saberlo.

Answer 1

depende de su audiencia, desarrolladores de juegos, incluido yo mismo no estamos muy acostumbrados al modelo MVC, aunque la mayoría lo sabe, no es tan fácil mantenerlo limpio, debido a las bajas en el desarrollo (no hay razones técnicas serias) . Entonces, por experiencia, he visto docenas de frameworks de juegos comenzar como MVC, pero solo un par fue capaz de mantenerlo hasta el final. Mi teoría es que MVC agrega demasiada complejidad y pequeños beneficios para pequeños juegos desechables (con normalmente algunos desarrolladores), y es difícil mantener la mayoría de los objetos de juego limpiamente separados en la mayoría de los 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 para el rendimiento y soluciones adhoc rápidas (que se reescribirán si es necesario en la continuación (si hay una)).

Sin embargo, con la advertencia anterior, es mejor apuntar alto, porque si lo logras es mejor :) y si fallas, bueno a malo. Probablemente deberías probar el MVC, pero no te preocupes si falla, los desarrolladores de juegos profesionales han fallado muchas veces en la tarea :)

Answer 2

Sin duda votaría por el modelo para no saber nada sobre sus puntos de vista. El acoplamiento flojo es bueno: código de modelo más simple, pruebas más fáciles, más opciones.

Answer 3

Sé que esta pregunta podría estar desactualizada, pero debo 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. Conozco mis problemas con la programación de juegos, cuando el programa se vuelve más grande y, en su mayoría, la estructura se vuelve demasiado compleja para mantener. Lo siguiente es que sé que cambiaré todos los gráficos cuando encuentre un artista que esté dispuesto a trabajar en ello. Pero hasta entonces, voy a usar mis propios gráficos falsos. 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 los objetos interactúan (detección de colisión, por ejemplo). La lógica del juego se captura en los modelos, por lo 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 tiene todo junto: todos los gráficos, sonidos, todo; entonces puedes codificar directamente.

Mi MVC es una configuración por convención, que ralentiza la creación de prototipos un poco. PERO (!) Las iteraciones de desarrollo se pueden hacer mucho más fácilmente. Las pruebas, especialmente las Pruebas unitarias, se realizan mucho más rápido. Diría que MVC convierte su curva de velocidad de desarrollo (que normalmente es una curva anti-exponencial) en una curva exponencial. Lento al principio, pero cada vez más rápido al final.

Answer 4

MVC funciona muy bien para juegos, al menos para mis juegos que están diseñados para plataformas cruzadas. Realmente depende de cómo lo implemente para obtener el beneficio.