Arquitectura

[bnl]

Buenas

¿Soleis utilizar alguna arquitectura en concreto al desarrollar los videojuegos? ¿Cual pensais que es el mas indicado?

Un patron de arquitectura que creo que se adapta bien al desarrollo de videjuegos es el Modelo-Vista-Controlador

[TrOnTxU]

mmmm, patrones ... este puede ser un tema "delicado". Voy a intentar dar mi opinión, justificandola, lo más brevemente posible y intentando no provocar :P

Si te refieres a implementar el patrom mvc, con su clase para cada parte, de la forma más "estricta", lo hice en un par de proyectos hace tiempo. Pero era hace mucho, y eran proyectos más sencillos.

En proyectos más complejos, para mi, la idea de separar el acceso a las partes "low-engine" así tiene sentido:
+ Modelo: Content, GameState, ...
Vista: Renderer, AudioEngine, User Input, Rumble or feedback controller, ...
Controlador: IA, EventSystem, ScriptSystem, Fisicas, ... ?

Aunque reconozco que nunca he sido muy bueno en esto de la abstracción.
En teoria esto te permite poder, por ejemplo, cambiar la "vista" sin que afecte a la "jugabilidad".
Pero mi primera pregunta es: ¿realmente lo vas a hacer?

Si lo que tienes es un "Renderer" OGL, y quieres hacer otro DX9, por ejemplo, tienes varias opciones:
1) Te creas la clase vista, como una capa de abstracción sobre el renderer, y ahi cambias las llamadas al nuevo Renderer.
2) Creas el nuevo Renderer y susutiuyes todas las llamadas a mano
3) Derivas de una interfaz el renderer y asi puedes elegir el renderer en runtime.
4) Lo anterior pero con un par de "trucos" con los #defines para fijar un Renderer en compile-time y "saltarte los virtuales".
5) ...

Pero como ves, en mi opinión la distribucion mvc en juegos/engines es más "conceptual" que "real".

Para mi, el "patrón" que funciona son los Managers. Dividir el juego/engine en tantos sub-sistemas "autonomos" como necesites, y crear capas por encima para atarlos.

En la capa más abstracta de jugabilidad no se puede "generalizar" ya que cada juego se implementa mejor de una manera. Aqui podriamos hablar de "controlador" por ejemplo.
Aun así uno bastante "generico" seria tener un GameWorldManager que tiene la lista de "entidades", que a su vez tiene "referencias" a objetos de los diferentes subsistemas (render, audio, fisicas, ...).
Aunque, por ejemplo, un juego de cartas, con una "entidad para cada carta" puede que igual no seria lo más apropiado (en mi ponión ... aunque poder, se puede hacer).

Lo importante en esta "distribución", es tener un buen subsistema de paso de mensajes y/o eventos entre los diferentes subsistemas. Esto te permite "abstraer" el contenido de los mensajes, y permitir que sistemas que "no se conocen" (por decirlo de alguna manera) intercambien mensajes entre ellos.
Esto si que, en mi opinión, permite un "verdadero decoupling" de las partes/sistemas, y una posible mayor "reusabilidad", e "independencia entre los subsistemas".

Hablando del "modelo":
- Hay que tener en cuenta que el Content cambia, pero es mejor que sea "data-drive", sino imprescindible. El código deberia centrarse en un ContentManager, y los Resources o Assets que maneja.
- El GameState es importante tenerlo "separado", o "listo para serializar", independientemente del "código de control o lógica de juego". Ya que muchas veces es lo necesario para: grabar partida, network-replication, repeticiones, juegar con el tiempo (como el prince of persia), etc, etc, etc


Además pienso, que (a nivel de juegos) es mejor pensar en datos y transformaciones, antes que en "patrones de diseño OOP". Pero es mi opinión.

Buenol al final lo de breve parece que ha sido anecdótico  :-[
Un saludo.

[bnl]

Muchas gracias por la respuesta tan extensa.

Cuando empece a programar en Android me puse a revisar viejos juegos que habia hecho para J2ME a ver si podia reutilizar algo o adaptarlo con facilidad y me encontre con que estaba todo muy acoplado ya que lo desarrolle sobre la marcha, sin plantear primero una buena arquitectura y hacer la adaptacion a android no era directo.

Lo de dividir el juego en managers lo estoy haciendo a nivel de infraestructura: un gestor ficheros, gestor graficos, gestor sonidos/musica, etc De esta forma el juego solo hace uso de estos gestores y en el futuro se podrian sustituir facilmente por otros. Y evidentemente estos gestores son reutilizables en otros juegos por lo que ya tienes gran parte del trabajo hecho.
Otra clave para desacoplar es trabajar contra interfaces, cosa que de momento no estoy haciendo y que deberia hacer.