design-nation.blog/es

Por supuesto, el motivo para realizar un motor de estas características, es el hecho de poder crear numerosas aventuras gráficas con el mismo motor, por lo que supuestamente el esfuerzo de programación debe descender exponencialmente a medida que se van realizando aventuras gráficas.

Una vez programado el motor, para cada aventura gráfica, en el departamento de la empresa al que pertenezco, desarrollamos los archivos XML en el que indicamos qué objetos aparecen en cada escena, y lo que ocurre al interactuar con cada uno de ellos ( cambios que se producen en ese y en otros objetos, paso de objetos a inventario, formulación de preguntas, visualización de avisos, requerimiento de objetos de inventario etc... )

Cada cdrom, lleva unos 650 - 700 ficheros flash ( lo que supone unas 2000 animaciones/grafismos diferentes ), y tantos xml de configuración de escenas, como escenas hay en el juego ( aparte de un par de archivos xml de configuración general del juego ).
De lo que estoy más satisfecho es de los siguientes puntos.

1.Ninguno de estos 700 archivos fla/swf lleva una sola línea de programación ( a excepción del stop() final de las animaciones )

2.Debido a esto, cada archivo xml de configuración de una escena está siendo desarrollado por personas que no tienen conocimientos de flash. ( A la hora de empezar a montar las escenas de configuración del primer cdrom, estas personas nunca habían abierto flash, lo que no impide que creen una escena de dificultad media en unos 20 minutos ). Evidentemente estas personas sí tenían una amplia experiencia en desarrollo de aplicaciones que incluían el uso de archivos XML, por lo que trabajar con este tipo de archivos no era ninguna novedad para ellos.

3. El "módulo 3d" que permite que aunque la escena tenga una visualización frontal, o lateral, o dividida en dos pisos... el personaje protagonista de las aventuras pueda pasar por delante y por detrás de los objetos, bien sea objetos situados en primer plano, en el centro de la escena etc... De esto estoy muy satisfecho, pues dada las diferentes posibles formas de visualización había que encontrar un sistema lo suficientemente genérico como para funcionar en todas, y no en una sola ( Habitualmente los juegos de este tipo, se construyen con una perspectiva isométrica, pues la solución al z-sorting es conocida, permite una gran reutilización de objetos gráficos, algoritmos de pathfinder etc.., pero el cliente no quería esto, por lo que teníamos que encontrar la forma de hacerlo funcionar con las especificaciones dadas ).

La aplicación tiene unas 8000 líneas de código ( incluyendo las necesarias para las pantallas intermedias de selección de personje, introducción de datos, almacenamiento de los mismos, gestión de las puntuaciones etc...)

Está construida utilizando un diseño orientado a objetos( unos 65 ficheros entre clases e interfaces ) ( toda la aplicación está construida usando POO y se arranca llamando al método main de la clase base de la aplicación )

Esta clase base, gestiona las comunicaciones entre las demás clases, mediante la emisión y recepción de eventos, aislando así unas de otras, permitiendo la máxima independencia de cada una de ellas, de modo que una clase no se ve afectada por cambios en las demás.

Un ejemplo es la clase "proxy" desarrollada para el almacenamiento de los datos y puntuaciones del usuario. Actualmente, esta salvaguarda de datos se lleva a cabo mediante el uso de sharedObjects en la máquina del usuario. Así cada vez que el jugador llega a una situación en la que hay que mostrarle sus puntuaciones y almacenarlas en disco el proceso es el siguiente.

La clase base, recibe un evento desde otra clase, que le indica que el usuario ha llegado a la situación de mostrar/almacenar puntuaciones. Nuestra clase base indica mediante un evento a la clase encargada de mostrar las puntuaciones, que pinte los valores en pantalla. Cuando esta clase termina de hacerlo, no los almacena, sino que le devuelve un evento a la clase base indicándole que ya ha terminado de pintar los datos y que se puede proceder a grabarlos. Entonces la clase base, le envía un evento a nuestra clase "proxy", que se encargará de guardar los datos. Cuando los datos estén salvados, le enviará un evento a la clase base, indicándole que el proceso de salvaguarda está finalizado. Y una vez recibido este evento, nuestra clase base decidirá lo que hay que hacer, si llevar al usuario a otra pantalla ( emitiendo un evento que será recogido por el controlador de la vista de destino ) o bien cualquier otra acción. -El uso de estas clases "proxy" es muy habitual por mi parte, pues me permiten no tener que modificar nada de la aplicación en sí, si se produce un cambio de tecnología de servidor ( ASP, PHP, JSP que es la utilizada habitualmente en la empresa, ColdFusion, ...)y se pasa de utilizar una a utilizar otra-.

Uno de los requerimientos del cliente era que la aplicación fuese fácilmente portable a web. Cuando llegue el momento, no habrá que hacer más que cambiar los métodos "insertData" y "receiveData" de esta clase para que en lugar de almacenar los datos en un sharedObject, llamen a cualquier tecnología de servidor. ( Extender la clase y sobrescribir la parte necesaria de los métodos implicados, o bien utilizar otra clase que implemente la misma interfaz ).

Cada objeto de la aplicación tiene su propia máquina de estados, y cada objeto puede tener tantos estados y transiciones entre estados, como se le indique desde el archivo xml de configuración de la escena( un estado, dos, ......, n estados ). También desde este archivo, indicamos qué efectos en otros objetos ( cambios de estado en otros objetos ) se producen al interactuar con cada objeto ( en función de cuál sea su estado actual ).

Evidentemente, el primer cdrom fue como un parto para todos los departamentos implicados, pero una vez determinado a partir de esa experiencia el sistema de trabajo más adecuado, los cdroms se van haciendo a gran velocidad a pesar de las numerosas animaciones necesarias para cada uno de ellos. Además, la experiencia que se va adquiriendo con cada cdrom, hace que los departamentos de guión y de animación y grafismo, vayan cada vez exprimiendo más las posibilidades del juego, y sacándolas mayor provecho, haciendo que cada aventura sea más bonita gráficamente y en cuanto a nivel de animación que la anterior, y con unas "tramas" más complejas. Estamos todos muy satisfechos.

¿ Quién dijo que con flash no se podían hacer este tipo de cosas?