Modelo-Vista-Controlador
Uno de los paradigmas de programación de aplicaciones gráficas es el patrón modelo-vista-controlador ( MVC ). Esta forma de organizar e interrelacionar los distintos componentes de la aplicación consiste en dividir el programa en la tres partes siguientes:
- Modelo – Son los datos del programa
- Vista – Es como los datos son presentados al usuario
- Controlador – Como el usuario puede manipular los datos
Ejemplos clásico de esta forma de estructurar un programa es un editor de texto, en donde el texto en memoria o en el disco son el Modelo (Datos), el sistema que recoge las pulsaciones del teclado, modificando los datos, e interpreta las ordenes es el Controlador y la forma en que se muestra en pantalla el texto es la Vista.
Otro ejemplo de MVC en un navegador. El modelo seria el archivo HTML del servidor, el navegador crea una Vista (representación visual) del archivo HTML y además gestiona las entradas del teclado y ratón, es decir el Controlador.
MVC en videojuegos
Como aplicación gráfica que es un videojuego también se puede diseñar para seguir el sistema MCV.
El Modelo de los distintos objetos serian la posición en el mundo, la rotación, el estado del objeto, el inventario del jugador, etc.
La vista serian las distintas representaciones del modelo. Por ejemplo en un juego de rol pueden existir varias vistas del inventario. En la vista normal del juego el personaje puede mostrar las armaduras que portan directamente en el grafico que representa al jugador, y en la vista del inventario mostrar esos mismos datos de forma más esquemática.
Comunicación entre elementos: Mensajes y Notificaciones
En un juego de futbol una de la IA va ha hacer un pase largo a una posición, ¿Cómo se lo dice al resto del equipo?. Un Mago lanza un hechizo sobre un Orco.¿Cómo le dice al Orco que esta muerto?
Estos son algunos problemas que se pueden plantear a la hora de programar un juego o una aplicación compleja. La comunicación entre elementos del juego es fundamental para poder desarrollar IA complejas y añadir riqueza de comportamientos a los niveles.
Principalmente nos encontramos con dos tipos de comunicación, la comunicación uno a uno, y la comunicación por eventos.
La comunicación uno a uno se soluciona con un sistema de mensajería que tenga un directorio de todos los elementos del juego y que a través de un identificador permita mandar mensajes entre los elemento tipo “objeto003 manda ESTAS_MUERTO a objeto010”
La comunicación por eventos se puede solucionar con un sistema de notificaciones. Es el denominado patrón Observador. En este patrón los elementos del juego se registran en un sistema centralizado para que le sea notificado cuando alguien provoca un evento. El elemento que lanza el evento no sabe ni le importa cuantos ni quienes necesitan responder a ese evento, es como una estación de radio, simplemente emite la señal, es el receptor el que decide que hacer con la información.
Un ejemplo de evento puede ser una granada que ha sido lanzada, cuando llega su cuenta atrás lanza un evento tipo “EXPLOSION en posición 100, 271”, los elementos del juego están escuchando el canal de “EXPLOSION” y al recibir la notificación de la posición decide si les afecta y por ejemplo añaden una fuerza a su sistema de física para que los lance por los aires.
Usar mensajes entre Modelo – Controlador y Vista
Si concebimos que nuestro anterior sistema MVC se realiza a través de piezas inconexas que se comunican entre ellas a través del sistema de mensajería obtendremos una estructura que en un principio parece complicarse la vida de forma innecesaria, pero que con vistas al futuro nos puede resultar útil.
La utilidad proviene de los juegos en red, ya sean juego basados en servidores centrales o juegos basado en pares.
En los juegos basados en servidores lo que se hace es que el servidor contiene el Modelo – Controlador de todos los elementos del juego, mientras que la Vista esta en el cliente local de cada jugador. Las acciones del usuario sobre el teclado y ratón se traducen en eventos que se lanzan al servidor a través del sistema de mensajes en red.
Los resultados de posición, rotación, tamaño y animación de cada elemento (las vistas) son actualizadas con los datos del servidor que vienen a través del sistema de mensajes.
Si nuestro sistema de mensajes esta ideado con el sistema de red integrado nos permitirá hacer juego offline y online con suma facilidad añadiendo una mínima complejidad el sistema.
Conclusión
Nuestro motor tendrá como núcleo central un sistema de mensajería y otro de notificaciones que servirá para la comunicación de los elementos tanto offline como online. Como base para todo los elementos del juego se usara un sistema de MVC, teniendo en cuenta que la relación entre Modelo – Controlador y Vista se realizara a través del sistema de mensajería.
En próximas entradas, según desarrollemos nuestro motor, iremos introduciendo mas sistemas fundamentales para tener un motor flexible y reutilizable.
Gracias por vuestro tiempo.
No hay comentarios:
Publicar un comentario