MVC o componentes, o ambos?

Soy un desarrollador experimentado, pero recientemente he querido entrar en la programación de juegos, pero como saben, el desarrollo del juego es una bestia completamente diferente de la mayoría de las otras formas de programación (quizás solo superado por el desarrollo del sistema operativo).

Dicho esto, he estado leyendo Game Coding Complete (ISBN 978-1-58450-680-5) por Mike McShaffry.

Originalmente iba a intentar desarrollar con un modelo de componentes con la variedad de componentes habituales (por ejemplo, SpacialComponent, VisualComponent, EntityLogicComponent, etc.), sin embargo, el Sr. McShaffry recomienda usar el modelo MVC que parece muy atractivo, pero no estoy seguro de cómo puede hacer que funcione con el modelo de componentes si es posible, pero, sin componentes, el modelo MVC parece una especie de monstruo de herencia monolítico malvado y no muy flexible, lo cual no me interesa mucho.

Estoy realmente confundido acerca de dónde ir desde este punto.

¿Tienes más experiencia con los expertos en vudú de codificación de juegos?

Muchas gracias!

Preguntas utiles:

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

¿Por qué MVC y TDD no se emplean más en la arquitectura del juego?

¿Compartimentación como MVC en los juegos?

Para mí, tengo una clase base RenderComponent y luego algunas que heredan de eso (GameSprite, UISprite, o si está haciendo 3d StaticModel, DynamicModel, BillboardModel, etc.) y si el objeto quiere ser renderizado, el objeto envía su RenderComponent miembro del sistema de representación. No es necesario que el sistema de representación sepa qué tipo de objeto envió el componente Render. ¡Simplemente sabe que tiene algo que renderizar y es mejor que lo haga, o de lo contrario!

Manténgalo básico y centrado en la composición en lugar de la herencia. La separación de la lógica, los datos y la representación no es incompatible con un sistema de componentes.

Recomiendo ignorar los componentes para su primer juego porque resuelven algunos tipos de complejidad al agregar más complejidad en otras áreas, y si aún no ha creado un juego, no tiene idea de si esta compensación vale la pena o no.

Sin embargo, en su mayor parte, no te atasques en paradigmas de programación y solo codifica un juego. No hay formas correctas o incorrectas, de lo contrario, nadie tendría que hacer este tipo de preguntas. Trabaja a medida que avanzas.

No usaría un patrón MVC estricto, pero separaría tu renderizado de tu simulación y lo pegaría en otro hilo.

Creo que los componentes son muy útiles en realidad, pero a menudo veo personas que simplemente los ignoran y escriben su código directamente en el componente "principal", sea lo que sea. Debes recordar que los juegos están llenos de trucos porque a menudo se escriben en una fecha límite con la suposición de que el código no se reutilizará.

Estoy un poco confundido sobre por qué piensas que estos enfoques son incompatibles. ¿Qué código de juego has visto?

Personalmente, creo que los juegos requieren un diseño inicial. He visto un par de bases de código que eran pesadillas debido a la mentalidad de "solo codificarlo".

Dicho esto, creo que deberías saltar y codificar un juego. Cometerás tantos errores escribiendo tu primer juego que este tipo de problemas no importará demasiado. Una vez que tenga una mejor comprensión de lo que se requiere, puede regresar y comenzar a mirar la arquitectura y ver cómo resuelve los problemas que encontró.