Segundo Proyecto: Data–View-Control En GEL

Siguiendo con la creación de un motor que nos sirva para los siguientes proyectos, voy a definir los elementos básicos del patrón modelo vista controlador a través de tres clases bases que se comunican mediante mensajes.

 

Diagrama de Flujo

 

ControlBase

La clase ControlBase es la clase que usaremos para crear los controladores de los objetos. Esta es la parte relacionada con la inteligencia artificial de nuestra aplicación.

En el diagrama de flujo podéis ver que responde a la notificación NTF_UPDATE, esto provoca que se lance una petición de datos a el objeto data correspondiente con MSG_GET_DATA y se espere respuesta a través de MSG_DATA.

Cuando se recibe MSG_DATA se llaman a las funciones virtuales puras UnpackData para extraer los datos de forma adecuada, OnUpdate para modificar esos datos y nuevamente empaquetarlos con PackData antes de mandar los datos nuevos al objeto data mediante el mensaje MSG_SET_DATA.

Uno de los posibles controles que tendremos que implementar es el control del usuario que responderá a las entradas de teclado, ratón, etc.…

ViewBase

 

La clase ViewBase, es la clase base que usaremos para crear todas las vistas posibles que vayamos necesitando. Esta estará muy relacionada con la parte gráfica de SFML 2.

Como podéis ver en el diagrama de tiempo, esta clase y sus derivadas responden al menos a la notificación NTF_DRAW, que significa que es momento de dibujar todo. El objeto vista pide la información a su objeto de datos i los interpreta para mostrarlo usando los mensajes MSG_GET_DATA y recibiendo MSG_DATA.

Las derivadas de ViewBase tienen que implementar un par de funciones virtuales puras que corresponden a la recepción de los datos (UnpackData) y otra correspondiente a la operación de dibujado (OnDraw).

Las clases derivadas de ViewBase pueden también responder a otras notificaciones, como por ejemplo, recibir las notificaciones NTF_UPDATE dentro de una vista animada para que `ponga el frame adecuado de una animación.

DataBase

 

Esta clase es la mas sencilla de todas ya que es un elemento pasivo que solo responde a los mensajes que recibe de las otras dos partes. Su misión principal es la de mantener los datos de los distintos elementos. Esta clase esta muy relacionada con la aplicación y por lo tanto sus derivadas no podrán ser reutilizadas en otros juegos.

Como veréis en el código esta clase tiene dos funciones virtuales puras que corresponden a UnpackData y PackData para procesar la recogida y envió de los datos.

Otro cometido de esta clase será la de guardar y leer información desde los discos duros para por ejemplo cargar un nivel o para guardar y restaurar una partida guardada.

Conclusión

 

Todo esto a un programador principiante le parecerá una complicación innecesaria, a fin de cuentas queremos hacer un juego de navecitas y punto.

Lo mas sencillo sería usar la aproximación al problema del primer proyecto. Crear las clases de los distintos elementos una clase juego que los coordine y listo.

Sin embargo, quiero que en el futuro todo el trabajo que estamos haciendo ahora sirva para algo mas que solo un juego, el objetivo es conseguir un sistema que nos permita fácilmente crear nuevos juegos sin mucho esfuerzo.

Para poner en perspectiva, y salvando las diferencias, los grandes motores de juegos 3D actuales, como UDK, CryEngine, etc. utilizan un sistema de mensajería como el que estoy programando como núcleo de su sistema. Así que animo y no os desesperéis.

Gracias por vuestro tiempo.