« AJAX vs Flash | Inicio | Aplicaciones multiusuario con Unity ( y actionscript y xml ) »

Motor de aventuras gráficas con AS2 y XML ( version 2 )

En una entrada anterior, hablamos del desarrollo de un motor para aventuras gráficas, con ActionScript 2 y gestionado completamente por XML, que permitía una muy rápida generación de aventuras gráficas.

Con aquel motor, y si no me engaña la memoria, fueron 26 los cdroms que se realizaron ( entre castellano, catalán, valenciano y gallego ) en 4 meses.

En el momento de escribir esta entrada, ya son varios los cdroms ( en diferentes lenguas ) que han salido con la "versión 2" del motor.

¿ En qué consiste ?. Repasemos primero lo que ofrecía la versión 1.


  • Todos los textos genéricos del cdrom, estaban en un xml de configuración ( textos como por ejemplo: "Nombre", "Contraseña", "¿Es la primera vez que juegas?", "El nombre o contraseña introducidas no son correctas. Si es la primera vez que juegas regístrate". Es decir, los textos de las pantallas de introducción ( de los botones, etc..) Permitiendo una traducción muy simple de las mismas, con traducir simplemente el xml de configuración.

  • La aventura, está dividida en unidades. En cada unidad hay tantas escenas como se indique en el xml de configuración de la unidad ( sin haber límite numérico ).

  • Cada escena, está controlada por un xml de la escena. En este xml se especifica lo siguiente:

    • Los objetos que aparecen en la escena.

    • El comportamiento de cada uno de los objetos. Cada objeto especifica en el xml su propia máquina de estados, con las acciones a realizar en cada uno de los estados.

    • La forma de interactuar con cada objeto, si es por hacer click sobre el o si es porque el personaje de la aventura "toca" o colisiona en pantalla con el objeto.

    • La posición ( o posibles posiciones ) en la que ha de estar el personaje controlado por el usuario en pantalla para que la actuación sobre el objeto tenga efecto ( en caso de no estar en una de estas posiciones, aparece un mensaje en pantalla pidiendo al usuario que se acerque más al objeto )

    • El resultado de interactuar con cada objeto en cada uno de los estados de la máquina de estados de dicho objeto. Es decir, por defecto, cada objeto tiene 7 posibles estados ( mas un número indeterminado de estados ficticios ). Estos estados son "visible", "activo", "invisible" etc..Cuando interactuamos con un objeto que está en uno de estos estados, podemos indicarle que o bien permanezca en el mismo estado, o bien que transite hacia otro estado ( lo que viene acompañado de un cambio gráfico pues la película del objeto se mueve hasta el fotograma asociado a cada estado, donde habitualmente hay un movieclip con una animación ).
      Además, la actuación sobre un objeto, puede modificar el estado de otros objetos, haciendo que cambien su estado ( y su representación gráfica por tanto )

    • En el xml se especifica también que la interacción con un objeto puede dar lugar al paso del mismo a un inventario.

    • En el xml se especifica también que en los objetos en los que se indique, para poder interactuar con ellos, es necesario utilizar alguno de los objetos que tenemos en el inventario.

    • Se especifica la posición inicial del personaje en pantalla.

    • Se especifican los textos que aparecen en los avisos que surgen en la escena

    • Los cdroms son didácticos ( acompañan a libros de texto ) y por tanto su finalidad es hacer preguntas al alumno sobre las materias. En el xml de la escena se indica dónde ( al interactuar con que objeto(s)) aparecen las preguntas.

    • La perspectiva utilizada. Hay varias perspectivas posibles. En función de lo indicado en el xml, el personaje aparecerá en pantalla más o menos grande, y su tamaño se reducirá o ampliará más o menos cuando se acerca al fondo o al comienzo de la pantalla.


  • En el xml de configuración de cada unidad, además de indicar las escenas, también se indica el xml con el repositorio de preguntas para cada unidad ( tantos xml de preguntas como unidades ).

  • Cada xml de preguntas de unidad, consta de un número determinado de preguntas ( 15 ). En dicho xml se especifica por cada pregunta:


    • El tipo de pregunta ( hay varios tipos de preguntas, de selección simple, de selección múltiple ) etc.. el motor interpreta este atributo y presenta en pantalla la pregunta con uno u otro grafismo según sea el valor del mismo.

    • Las posibles opciones de respuesta y cual ( o cuales pues puede haber selección múltiple ) son las correctas.


  • Por supuesto, y aunque no está realizado en perspectiva isométrica, el personaje puede pasar por delante y por detrás de los objetos. Esto fue especialmente complejo, pues a priori, y dado que el número de objetos que aparecen en pantalla viene dado por el xml, nunca se sabe cuantos objetos habrá ( ni donde estarán situados )

  • Cada cdrom podía tener unos 600 objetos, es decir unos 600 swf. Ninguno tenía dentro ni una sola línea de código ( excepto los stops de las animaciones ) pues su comportamiento está definido en los xmls.


La conclusión es que, con este motor se podía trabajar-y se trabajaba- ( sin tener que escribir ni una sola linea de código ) en varios cdroms a la vez con un equipo de guionistas, animadores y personas escribiendo archivos xml de configuración de escenas por cada cd.

Todo esto está muy bien, pero.. ¿ se podía mejorar ?. Sí, y eso es lo que se hizo en la versión 2 del motor, en la que se añadieron:

  • Más perspectivas del personaje. Permitiendo ( dada la habilidad de los animadores ), diferentes tipos de escenas, con mayor o menor sensación de amplitud, pues en algunas la línea del horizonte está más baja, lo que unido a un factor de escala del personaje determinado, proporciona perspectivas muy variadas.
  • Comunicación con el usuario mediante el uso de una "PDA". Al usuario se le muestran avisos de texto o se le mandan preguntas ( recordamos, cdroms didácticos ) mediante un interface gráfico en forma de PDA.
  • Añadimos que desde el xml de configuración de la sala, no solo indicamos donde salen preguntas, sino cuántas salen cada vez ( permitiendo así, las baterías de preguntas )
  • A los 5 tipos de preguntas existentes, se añaden otros 6, llegando a 11 tipos diferentes de preguntas. Añadiendo preguntas de unir mediante flechas, o de arrastrar y soltar. Como decimos todo indicado mediante atributos xml.
  • Diálogos. Elaboración de un motor de diálogos que permite conversaciones de alto nivel de anidamiento y varios posibles finales. Por cada diálogo tendremos un xml de configuración del diálogo, donde indicaremos cada línea de diálogo tanto del usuario como del objeto con el que interactúa. Es decir, en función de la selección realizada por el usuario, en cada "turno" de palabra, el diálogo será diferente. En caso de llegar al final del árbol del diálogo por alguna de las ramas que no llevan a una de las frases indicadas como finales en el xml, el diálogo comenzará de nuevo. Cada vez que elegimos una frase, el personaje cambiará su estado para presentar una animación del mismo hablando. Cuando el turno es del objeto con el que interactuamos ( que obviamente, de normal representa a una persona ), será dicho objeto el que se pondrá gráficamente a hablar y nuestro personaje se pondrá en posición de escucha. Estos dos estados, de hablar y de escuchar, son dos de los estados que tienen todos los objetos en su máquina de estados ( que luego, habrá objetos que los usen y objetos que no ).
  • Inventario múltiple. Se "extiende" la funcionalidad de inventario, para tener varios objetos en el mismo. Esto implica que cada vez que interactuemos con un objeto, que necesita ( porque así lo hemos indicado en el xml ) que se haga uso de un objeto del inventario, tendremos que comprobar que se está usando el objeto correcto.
  • Mientras en el primer motor, cada unidad lleva asociada un temario, y siempre el mismo ( por ejemplo, unidad 1 del cd de matemáticas, los números primos. Unidad dos la división, etc.. ) la versión actual del motor, permite una asociación dinámica entre las escenas del juego y las preguntas de las unidades de cada asignatura. De este modo, la historia de la aventura gráfica será siempre la misma y mantendrá el mismo orden consecutivo en el argumento ( se jugará secuencialmente y siempre en el mismo orden las etapas ), pero las preguntas de cada unidad didáctica podrán plantearse indistintamente en cada etapa. Cada vez que se comience una aventura con un usuario nuevo, existirá la posibilidad de realizar una asociación distinta entre las etapas y las preguntas.

Con este motor, y gracias a los divertidos guiones realizados por el departamento de guión, a las fabulosas animaciones realizadas por el departamento de animación, los grafismos del departamento de diseño, y la elaboración de los xml de configuración de escenas por tecnología, se han podido realizar ( y se siguen realizando ) numerosos cdroms, en diferentes idiomas, y trabajando en tres o cuatro a la vez ( dado que no es necesario tirar una sola línea de código ). Y a los niños, les gusta el juego ( aunque haya preguntas de matemáticas, o de lengua ).


Y sí, realizar el motor, .... ha sido difícil. Pero ha quedado chulo. Podéis ver el resultado a partir de septiembre, cuando empiece el curso escolar y distribuyan los discos ( creo que se los entregan a los profesores y estos los instalan en los ordenadores de los colegios, pero no estoy seguro ). Y podréis seguir las aventuras de los agentes secretos "Zeta" y "Hache".

( Por cierto, ya hay una versión tres del motor, que permite lo que todas las buenas aventuras gráficas, una navegación no lineal, pudiendo volver a escenas ya pasadas en donde, mediante el uso de mementos, se recuerda el estado de las mismas, y un montón de novedades más que ya contaré )

Comentarios

comoandas càpo