Cronicas de un Mundo Gris

http://www.adva.com.ar/foro/index.php?topic=4592.msg27699#msg27699

Supongo que no importa un carajo lo que diga, realmente lo que pone comida en mi plato no son los juegos, más bien algo que me gusta hacer para olvidar los ABMs, pero bueh me toco hacer un videojuego para una materia de la facu y como soy purista, intente diseñar una arquitectura afín. Tal vez lo que hice te sirve de algo. El juego a hacer era un típico arcade de plataformas.

La arquitectura la dividi en dos capas: un nucleo y un frente. El nucleo es el juego en sí (game layer), y el frente es la interfaz humana que podía ser la interfaz del jugador (player layer) o la del editor de niveles (editor layer). La idea era que tanto la aplicación final del juego como la aplicación interna para que el que se encargaba de hacer los niveles compartieran el mismo core, garantizando, en teoría, que el level-designer tuviera una previsualización acorde, y se reutilizara todo el código que era pertinente.

El core, o game layer, lo dividí en 4 subsistemas: Gameplay, Render, Action y World (de ahí que le quedo el nickname de patrón GRAW ).

El subsistema World era la simulación del espacio de juego: como se abstraía un nivel y cada uno de los actores del juego. La emulación de la física de este espacio formaba parte de este subsistema como un componente subordenado al mismo.

El subsistema Render se encargaba de presentar el espacio de juego en forma audio visual. Tomaba el estado actual de World (porque World guardaba dos estados: el estado actual y el estado futuro) y según esto actualizaba el display, y generaba efectos sonoros, o cambiaba la música de fondo.

Además este subsistema exponía interfases a algo que llame “rendering hints”, que se acoplaban a ciertos elementos de World, y servían para añadir información que el render necesitaba pero que no hacía a la abstracción del espacio de juego. Por ejemplo, en ese juego los niveles estaban abstraídos como una grilla de tiles, y un tile podía estar vacío pero tener diferentes motivos decorativos; a la simulación del mundo no le importa si el fondo es una pared o empapelado, pero al render sí porque tiene que mostrar assets diferentes; el asset a usar estaba indicado en los rendering hints.

No importa como lo implementes, lo importante de este punto es que las entidades del subsistema World deben poder acoplar información de Render sin saber realmente de que se trata, ya que es información que ajusta el aspecto visual pero no cambia en nada la simulación del mundo.

En el subsistema Action modele las diferentes interacciones del juego, por ejemplo el hacer caminar en una dirección dada al personaje. Lo importante acá es desacoplar “lo que se puede hacer” del “como se lo indica a través de los dispositivos de entrada”, o sea, en el Action no hay noción de que existe un teclado o un mouse, solo nociones de “hacer mover al personaje”, “activar un objeto”, etc. Como se mapean estas acciones a los dispositivos de teclado y mouse es preocupación de la capa superior.

En el subsistema Gameplay es donde modele la mecánica del juego, las reglas que lo rigen. En el caso particular de ese juego la mecánica era básicamente una máquina de estado, por eso es que World guardaba dos estados, una presente y uno futuro. Gameplay construía el estado futuro a partir del estado presente, observando en Action cuales son las interacciones pendientes.

Además, hacía uso del componente de simulación de física de World para generar el siguiente paso siguiendo las reglas “físicas” que regían la simulación. Salvo que la física juegue un papel importante en la mecánica, me pareció más pertinente que formara parte del subsistema World.

Luego se hacia “avanzar el tiempo” reemplazando el estado presente por el estado futuro.

—-

El sistema funcionaba básicamente de esta manera:

El player layer seteaba el display y lo vinculaba con Render.

En la sincronía con el frame delegaba a Render la tarea del… render, y luego rendereaba el HUD observando World (por ejemplo, observando la vida restante del personaje principal y dibujando la barrita de vida).

Un reloj manejaba el ritmo de juego, el cual delegaba cada “paso” del juego a Gameplay.

La interacción con teclado y mouse era atendida también en el player layer, asociada con una acción pertinente en Action, y, por ejemplo, si acción requería estar asociada a un elemento del juego que fuera marcado por el mouse, se le preguntaba primero a Render que había en dicha posición (ya que Render es el que sabe como se relaciona la presentación con la abstracción).

—-

Al final, en general te puedo decir que ordenarlo así le dió algo de coherencia al código, a grano grueso y a grano fino, así que dentro de todo tuvo sus buenos resultados, pero tal vez con otros tipos de juegos no funcione tan bien…. que se yo. Por lo menos me sirvió para sacarme una muy buena nota para esa materia, aún con un producto no terminado (funcional pero no terminado). Intente usar la arquitectura para otro juego (quise hacer algo para codear banner games) pero estoy hasta las manos de laburo y solo se me complica un montón. A pesar de eso me sirvió para arrancar con algo totalmente nuevo sin arrancar de cero.

Igual estuve pensando como plantear esta arquitectura para otros tipos de juegos y/o con otros conjuntos de features, como por ejemplo ver donde meter la IA (que en realidad puede pisar en diferentes partes de la arquitectura), o como agregar un subsistema adicional Story para juegos que manejen una narrativa muy entrelazada con la mecánica, o un sistema Networking para la sincronización y resolver problemas de juegos multiplayer sobre un enlace de comunicación no fiable, etc, etc.

Igual insisto que lo que más sé es sobre software fuera del ámbito de los videojuegos. Para mí los videojuegos son un hobby (tal vez algún día lo haga una profesión pero será bajo mis propios términos). Así que tomalo con pinzas sabiendo que viene de alguien que te saca ABMs como pizza.