Estoy leyendo un gran libro, Game Coding Complete , y ese libro recomienda encarecidamente utilizar el enfoque MVC (Modelo-Vista-Controlador) , con tres capas clave:
- Capa de aplicación del juego
- Game Logic
- Vista del juego
Para mí, este enfoque parece una exageración para un juego de computadora móvil.
¿Cuál es tu opinión, por favor? ¿Vale la pena implementar esta arquitectura, incluso si agrega comunicación adicional necesaria entre módulos? ¿Puede este diseño consumir tanta energía de la CPU que, al final, el resultado sería significativamente más lento que si no se implementara?
architecture
Bunkai.Satori
fuente
fuente
Respuestas:
De alguna manera, apoyo el uso de una estructura MVC incluso para un juego móvil simple. Por lo menos, ayuda con un problema que afecta a los desarrolladores que no lo han mordido suficientes veces: separar el código de visualización de la lógica del juego.
Sin embargo, también diré que tenga en cuenta que MVC, como todos los patrones de diseño, existe para facilitarle la vida . Eso significa que si, en un momento dado, mantenerse dentro de un conjunto de reglas sobre lo que debe y no debe hacer cuando usa MVC le está haciendo la vida más difícil, ignórelo . Sucederá una de dos cosas: 1) te morderán más tarde, y luego entenderás por qué hacerlo de manera diferente en primer lugar realmente habría hecho tu vida más fácil a largo plazo, o 2) ninguna consecuencia en absoluto.
La programación de computadoras, por su naturaleza, tiene muchos seguidores de reglas que valoran la adhesión al principio elegante en lugar de lograr algo, y les encanta proponer su sistema de valores; no dejes que te hagan uno de ellos. Lo más importante que le puede pasar a tu juego es enviarlo .
fuente
Los diseños en tiempo de compilación no consumen energía de la CPU, a menos que tenga un compilador increíblemente abismal. Un lenguaje o enfoque orientado a objetos no es diferente en características de rendimiento que uno de procedimiento. No invocará ningún gasto adicional por usar MVC. La modularidad existe en tiempo de compilación, no en tiempo de ejecución, una vez que el código está en línea y optimizado, no hará ninguna diferencia.
Muchos juegos modernos realmente ejecutan los modelos y las vistas en subprocesos separados y obtienen grandes beneficios de rendimiento en la mayoría de las plataformas.
En última instancia, MVC es un buen diseño que le brinda un mayor mantenimiento y menos errores, etc. de forma gratuita . No hay razón para no usarlo. Es como preguntar por qué debería usar un
forbucle en lugar degotos escrito a mano . A menos que tenga un diseño superior en mente, es mucho mejor que nada.Editar: los diseños en tiempo de compilación no consumen energía de la CPU. Obviamente, los diseños en tiempo de ejecución, como la herencia, sí.
fuente
Casi siempre existe una compensación entre la claridad del código y los requisitos técnicos (velocidad, memoria, etc.) del programa. Los lenguajes orientados a objetos tienen una sobrecarga en comparación con los lenguajes de procedimiento, pero se ha demostrado que tienen muchas ventajas sobre los lenguajes de procedimiento, especialmente en el mantenimiento a largo plazo del código (errores, etc.) y, a menudo, también en la velocidad de desarrollo.
Con eso en mente, propongo que vale la pena implementar MVC por tu bien como programador de juegos . Su código seguirá mejor los principios orientados a objetos, especialmente la encapsulación , y es probable que le resulte mucho más fácil mantenerlo (corregir errores o agregar nuevas funciones).
Por otro lado, asegúrate de terminar un juego y no pasar tanto tiempo trabajando en el "motor" que nunca se haga.
Para obtener más información, lea la pregunta "¿Por qué MVC y TDD no se emplean más en la arquitectura del juego?" y mi muy larga respuesta.
fuente
a++será exactamente la misma quea++en C (dondeaes un tipo primitivo, etc., etc.). Pero considere una clase C ++ simple con una función virtual que hace algo, esa función virtual incurre en una sobrecarga considerable frente a una función C simple, incluso si el código interno es idéntico. Los lenguajes orientados a objetos tienen una sobrecarga . Perdón por decir explícitamente "velocidad". Si las asignaciones de memoria adicionales y tales no resultan en un programa más lento, entonces está absolutamente correcto.