Arquitectura del motor de juego MVC (Model-View-Controller): ¿Sí o No? [cerrado]

18

Cerrada . Esta pregunta está basada en la opinión . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda ser respondida con hechos y citas editando esta publicación .

Cerrado hace 4 años .

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

55

-1 y vota para cerrar. Todo lo que vale la pena decir sobre MVC en los juegos se dijo en gamedev.stackexchange.com/questions/3426/… , y hasta ahora todo lo que tenemos aquí es basura.

@ Joe Wreschnig eso es bastante duro, pero supongo que es cierto ...

— Spooks

@chaos: En realidad, voté su respuesta, pero realmente no necesitamos otra respuesta que diga "usar patrones si ayudan, no si no lo hacen". O tal vez lo hicimos, pero eso sigue siendo muy triste. Sin embargo, todavía no sé cómo referirme a expresiones como "Diseños en tiempo de ejecución como herencia" que no sean basura.

2

@ Joe: Oh, bueno, gracias. :) El argumento de que la OOP es gratuita hace que la mente se vuelva un poco confusa. Supongo que, según algunos estándares, no deberíamos necesitar puntos como los míos reiterados, pero los noobs suceden y también las preguntas duplicadas discutibles. También cumple la función de permitir a los recién llegados al sitio como yo reunir un poco de reputación a pesar de que la actividad se haya apagado de manera masiva. :) Quiero decir, maldición, tengo 40K rep en SO, pero aquí ni siquiera puedo editar una etiqueta wiki.

— caos

30

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 .

— caos
fuente

Querido Caos, me gusta más tu respuesta, por lo tanto, la marco como respuesta a mi pregunta. El enfoque MVC agrega abstracción al diseño del código. La abstracción usualmente agrega pasos adicionales de código, que podrían evitarse con un diseño más directo. Como entendí correctamente, no necesito preocuparme por el costo introducido por la abstracción agregada como resultado del diseño MVC.

— Bunkai.Satori

1

Buena respuesta, +1 en eso ... La teoría está muy bien, pero puede hacer que los juegos no se envíen si simplemente no lo haces.

— James

@ Bunkai.Satori: Agrega abstracción, y en mi opinión es una abstracción útil que paga su camino. Estoy de acuerdo con su última declaración, con la aclaración de que no es un coste, y que no creo que hay que preocuparse de ello.

— caos

4

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 de gotos 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í.

— DeadMG
fuente

-1. MVC es una decisión en tiempo de diseño. La herencia es una decisión en tiempo de diseño. Ambos ocurren antes del tiempo de compilación y el tiempo de ejecución. Ambos tienen importantes impactos en el rendimiento. La alineación no siempre hace que el código sea más rápido. Su propuesta de hilos es increíblemente ingenua. Nada es gratis.

Gracias DeadMG por tu respuesta. Básicamente, quiero decir que con cada nivel de abstracción, el código se vuelve lento, a medida que se agregan más y más pasos intermedios. MVC es un diseño más abstracto, que probablemente dará como resultado más pasos para lograr la misma tarea. Esto tendría influencia en la velocidad, en mi opinión.

— Bunkai.Satori

4

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.

— Ricket
fuente

1

Los lenguajes OO no son más lentos que los lenguajes de procedimiento. Si escribe algún código en C ++ que hace cambios de bits, no será más lento que en C. Un lenguaje o programa no es más lento en comparación con el de procedimiento simplemente porque está orientado a objetos. Los programas solo exhiben perjuicios de rendimiento porque están mal escritos . Como resultado, siento la necesidad de rechazar su respuesta.

— DeadMG

Hola Ricket, gracias por tu explicación. Suena muy lógico. DeadMG, bueno, por un lado tienes razón, por otro lado, creo que el enfoque OO agrega más bits de información en el código compilado que el lenguaje de procedimiento. Estos bits adicionales de código relacionado con OO hacen que el código resultante sea más lento. ¿Estás de acuerdo?

— Bunkai.Satori

3

Whoa ahora ... Claro, una línea simple en C ++ como a++será exactamente la misma que a++en C (donde aes 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.

— Ricket

2

Si la función es virtual, eso implica que el programa necesita elegir entre 2 versiones diferentes de la misma función en tiempo de ejecución. (De lo contrario, no lo haría virtual). En este caso, tiene un nivel adicional de condicionalidad o indirecto de todos modos, que tendría que implementar usted mismo en un lenguaje de procedimiento (por ejemplo, mediante un puntero de función o una instrucción de cambio) . Eso no es una sobrecarga, eso es intrínseco al problema.

— Kylotan