¿Cómo manejar la representación gráfica de objetos en el juego MVC 2D?

Question

Estoy haciendo un juego en 2D en Java usando el patrón MVC y después de leer y buscar mi trasero todavía no he encontrado una respuesta satisfactoria a cómo se supone que debo manejar la representación gráfica de los objetos.

¿Debo dividir cada objeto, por ejemplo Player en PlayerModel (almacenado en Model) y PlayerView (almacenado en View)?

Eso parece un poco desordenado porque entonces tendría que hacer un seguimiento de qué objeto de representación grafical, es decir, "ScaryMonsterEnemyView" está conectado a qué objeto de representación lógica, "ScaryMonsterEnemyModel". ¿Es así como se supone que debo hacerlo de acuerdo con MVC? Si es así, ¿dónde debe almacenarse esta conexión? En la vista?

Sé que esto podría ser un problema tonto para atascarse, pero quiero obtener todo lo que pueda desde el principio. Gracias por ayudar :)

Answer 1

Si no me equivoco, básicamente estás preguntando cómo dividir un juego en el paradigma Modelo-Vista-Controlador.

En pocas palabras, el modelo es el estado de tu juego. En términos O-O, puedes pensar en el Modelo como todos los objetos en tu juego.

El Controlador es el conjunto de reglas que se aplican al estado de su juego (en este caso, todos sus objetos de juego) en cada ciclo de actualización. Esto se puede implementar como un método llamado update() en todos sus objetos, o puede ser una función llamada en su bucle de juego que sistemáticamente pasa por todos los objetos que necesitan actualización y, bueno, los actualiza. También puede pensar en el Controlador como el bucle del juego. Llama a todo para actualizar, y luego lo dibuja en la pantalla y lo repite, a menos que se cumplan algunas condiciones, luego le dice al programa que haga algo más. De esta forma, casi tienes dos estructuras MVC anidadas. Uno que controla el flujo del programa a través de menús y tal, y uno dedicado al juego en sí.

The View es simplemente la representación gráfica de su juego. Esto puede ser tan simple como el texto en una pantalla, pero en su caso son gráficos en 2D. Para implementar esto, podría hacer que cada objeto también contenga su estado gráfico, ya sea directamente o mediante encapsulación. La Vista haría poco más que consultar todos los objetos por su estado gráfico y luego desviarlo a la pantalla. Nuevamente, esto puede implementarse por objeto, como un método llamado draw(), u otra función sistemática para ser invocada directamente desde el bucle del juego. Una práctica común es crear un objeto llamado 'Sptite' o algo similar para mantener la información gráfica, y hacer que cada objeto del juego que se dibuje tenga una instancia personal. También tenga en cuenta que la vista no tiene por qué ser un objeto en sí mismo. Una mera función llamada en un bucle de juego será suficiente, aunque a veces es necesario almacenar información que afecte directamente la operación de la Vista (como el tamaño de la ventana), en cuyo caso la Vista puede ser un objeto. Lo mismo aplica para el controlador.

También tenga en cuenta que estas divisiones se pueden dividir aún más para hacer la vida más simple. Por ejemplo: el controlador se puede dividir en procesamiento AI, actualización de movimientos y verificación de colisión. La Vista se puede separar en la pantalla de objetos del juego y el HUD, y el Modelo puede ser todos los objetos + todo el estado independiente de los objetos del juego (como la configuración de juegos para resolución, tamaño de ventana, configuración de tecla y demás).

Sé que esto podría ser un poco exagerado, y probablemente tenga información adicional, pero con suerte responde su pregunta y le da ideas sobre dónde empezar.

Answer 2

El modelo y la vista son dos colecciones/categorías/dominios de objetos.

El controlador proporciona un conjunto de interfaces para realizar algunas funciones en los objetos del modelo. Y si es necesario, la vista puede hablar directamente con los objetos del modelo con respecto a su información de estado.

Tradicionalmente, el dominio Ver corresponde a las GUI, con conceptos tales como Botones, Formularios, Windows, etc. En un entorno de escritorio.

Su dominio de visualización (o uno de ellos) corresponderá a un entorno 3D que usted construirá. (Árboles, casas, persona, etc.). Esto incluye detalles de colisión y su física. Ambos requieren la geometría relacionada con su entorno 3D.

Puede ser muy raro en un juego que alguno de estos objetos tenga que colaborar con un objeto en otro dominio. Pero un ejemplo, considera un teléfono. El objeto existirá en su entorno 3D, pero también colaborará con otro dominio que describa "llamadas a medias", "canales", "interruptores", etc. Estos objetos no pertenecen a su dominio de visualización, sino a un dominio de modelo separado.

Un ejemplo más relevante puede ser algún tipo de sistema de puntuación, como las estadísticas de RPG, que pertenecerían a un dominio de modelo.