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?