Lenguaje de Script para Aventuras Gráficas y Presentaciones Interactivas.

Transcripción

1 Lenguaje de Script para Aventuras Gráficas y Presentaciones Interactivas. (Documentación Preliminar) 5º Concurso Universitario de Software Libre Miguel Angel Pescador Santirso 1/13 LSAGPI- Documentación Preliminar del Proyecto

2 Introducción y Licencia de esta Documentación Esta documentación tiene únicamente carácter orientativo y su función es la de dar una idea preliminar de proceso de desarrollo de este software. No debe tomarse al pie de la letra puesto que es una versión temprana y no se contemplan muchos casos de uso que pueden aparecer a lo largo del desarrollo. Este documento se distribuye bajo licencia GFDL: La distribución, difusión y explotación comercial están permitidos en los términos de dicha licencia, la modificación deberá mantener el nombre del autor principal reconociendo su autoría. 2/13 LSAGPI- Documentación Preliminar del Proyecto

3 Indice 1.-Definición del paquete de aventura Estructura del paquete Sistema de Compresión Acceso a datos. 2.-Definición del Lenguaje de Script Bloques Procedimientos Variables Operadores Funciones. 3.-Implementación del motor de Script Pre-procesador Sistema Cuarto Elemento Verbo Acción Expresión Inventario Animación. 4.-Pruebas del motor de Script Presentación Interactiva Aventura Gráfica. 5.-Más allá de este documento. 3/13 LSAGPI- Documentación Preliminar del Proyecto

4 1.-Definición del paquete de aventura. Al ser este un motor de Script todo archivo de código fuente es interpretado. Lógicamente al hablar de una aventura gráfica (o presentación interactiva) además del propio código fuente tendremos gráficos, sonido, voces y otros contenidos multimedia. Para facilitar su distribución lo que haremos sera un solo paquete para toda la aventura gráfica (o presentación interactiva) en el que estarán contenidos tanto el código fuente como el contenido multimedia. Dicho paquete será leído por el interprete. Dicho paquete debe de tener algún sistema de seguridad que permita la protección de los datos de la aventura ya que, aunque nuestro desarrollo es 100% código libre, la/s persona/s empresa/s que lo utilicen para desarrollar sus aplicaciones no tienen porque liberar el código de Script ni los contenidos gráficos que son de su propiedad Estructura del paquete. El paquete de datos tendrá la siguiente estructura: / - [archivos fuente del script] [archivo de metadatos] /[directorio de gráficos] /[directorio de sonidos] /[directorio de sistema] Detalladamente el/los archivos fuente del script se colocaran en la raiz del paquete junto al archivo de metadatos que definirá el paquete principal por que que se empezará la aventura/presentación una vez iniciada ya no será necesaria puesto que todos los archivos fuente se procesarán a la vez, la división será únicamente para claridad del código y del programador. 4/13 LSAGPI- Documentación Preliminar del Proyecto

5 Se barajan los nombres metafile.md obligatorio para el archivo de metadatos y la extensión advs para los archivos fuente de aventura gráficas y pis para las presentaciones interactivas. Téngase en cuenta que es un documento preliminar y podríamos optar por cambiar alguna de las extensiones o incluso suprimir una. En el directorio de sonido (posiblemente snd) se incluirán todos los archivos de sonido que se necesiten así como en el de gráficos (posiblemente gr) se incluirán todos los gráficos. En el directorio de sistema (posiblemente sis) se incluirán los archivos de sistema que serán gráficos, imágenes y sonidos no esenciales para la aventura/presentación pero si para la presentación del entorno de ejecución (ventana de ejecución) Sistema de Compresión. Para la compresión de archivos se utilizara un formato zip empaquetado (compresión 0) con clave en el caso de ser necesaria que servirá para proteger el formato, al usar el sistema se podrá optar por incluir la clave en el código fuente del motor o solicitar la clave mediante ventana emergente dependiendo de si va a ser explotación comercial (ventana emergente) o simplemente protección de los archivos fuente (incluido en el motor) Acceso a datos. El acceso a datos lo gestionará el propio motor, permitiendo salvar posiciones del juego (savegames, archivos posiblemente con extensión sav). El acceso a gráficos y sonido se efectuará según el siguiente algoritmo: 1. Lectura del recurso a leer. 2. Descompresión del recurso en memoria. 3. Uso del recurso. 5/13 LSAGPI- Documentación Preliminar del Proyecto

6 En ningún caso se extraerá el recurso solicitado a ningún dispositivo de memoria secundaria. El recurso pasará del zip a memoria para evitar la copia de estos en ejecución. Con una clave adecuada este sistema de seguridad se considera suficiente para distribución comercial del producto final el cual NO es el objetivo de este proyecto ya que este proyecto únicamente tiene como objetivo el motor de script no los desarrollos realizados sobre el. 6/13 LSAGPI- Documentación Preliminar del Proyecto

7 2.-Definición del Lenguaje de Script. El lenguaje de script esta inspirado en el sistema indyjava si bien son notables las diferencias de instrucciones y funcionamiento interno si bien la sintaxis es muy similar Bloques. El lenguaje de script se basa en bloques, entendiendo como bloques principales el CUARTO y el SISTEMA. El resto de bloques estan contenidos en estos dos. El SISTEMA se ocupa de la representación de la pantalla (resolución, colores de tinta y fondo, fps, fuente de texto inicial, cursor,etc...), ademas también incluye la definición de los verbos, selección del personaje principal y cuarto de inicio. El CUARTO contiene la definición de cuarto (si es el inicial ademas la definición del personaje principal, salvo que el inicial sea un presentación interactiva), contiene los bloques de ACCION, ELEMENTOS del cuarto, PROCEDIMIENTOS y FUNCIONES necesarios para la acción y los disparadores de EVENTOS. /*Aquí ira la descripción detallada de cada bloque*/ 2.2.-Procedimientos. Son secuencias de intrucciónes seguidas secuencial mente y controladas mediante instrucciones de control de flujo. Son la base de las presentaciones interactivas ya que podemos crearlas únicamente usando procedimientos. Su aplicación en las aventuras gráficas es mayormente para transiciones aunque puede usarse para ciertas acciones. /*Aquí ira la descripción detallada de los procedimientos predefinidos*/ 7/13 LSAGPI- Documentación Preliminar del Proyecto

8 2.3.-Variables. Solo se reconocerán dos tipos de variables, numéricas o de cadena de caracteres. Las primeras típicamente usadas para el control de flujo, las segundas para textos de los personajes, conversaciones, etc... /*Aquí ira la descripción detallada de uso de variables y variables del sistema*/ 2.4.-Operadores. Se reconocerán los operadores lógicos (Y, O, NO). Ademas de los procedimientos predefinidos de operadores numéricos y de cadenas (ver Procedimientos). Así como las funciones de comparación de ambos (ver 2.5.-Funciones). /*Aquí ira la descripción detallada de cada operador*/ 2.5.-Funciones. Las funciones básicas que se reconocerán serán las de colisión, comparación, y estado del juego (por ejemplo, si un personaje se encuentra en una habitación, si ya tenemos un objeto en el inventario, etc...). /*Aquí ira la descripción detallada de cada Función*/ 8/13 LSAGPI- Documentación Preliminar del Proyecto

9 3.-Implementación del motor de Script. Para la implementación del motor, utilizaremos metodología orientada a objetos y un lenguaje que lo acepte, en primer termino usaremos java OpenJDK para las versiones Win32/Linux/OSX. En el momento en que esta implementación este completa y para portarlo a dispositivos empotrados optaremos por una implementación en C/C++ cuando no se pueda usar Java (por ejemplo, en plataformas Android y Blackberry es posible usar Java, pero en Iphone/Ipod/Ipad esto no es posible y debe ser usado Objetive C, en Symbian C++ o C#, en WebOS, C/C++, etc...). El objetivo del desarrollo es que pueda correr en plataformas empotradas además de las tradicionales, cuantas mas plataformas mejor. Una vez definido el objetivo pasemos a la parte practica de nuestro motor Pre-procesador. Dado que el archivo fuente debe admitir comentarios nuestro preprocesador debe ser capaz de quitar dichos comentarios para que no influyan en el procesamiento del archivo fuente. En una primera fase es la única labor del pre-procesador, quitar comentarios. El pre-procesador recibe el código fuente, quita los comentarios y envía dicho código al motor. Por supuesto se le irán añadiendo características como comprobación preliminar de la sintaxis antes de pasarlo al motor y detección temprana de errores. Pero todo eso se realizará en una fase mas avanzada del proyecto, en la primera fase todo lo que interesa es que realice la labor, la eficiencia y características superfluas a esta labor se realizarán en fase alpha. 9/13 LSAGPI- Documentación Preliminar del Proyecto

10 3.2.-Sistema. El objeto Sistema tratará los bloques de sistema del archivo, es decir, definirá el tamaño de la ventana, los colores de fondo, el cuarto inicial, etc... y cualesquiera bloques añadidos antes o despues en el curso del desarrollo del proyecto Cuarto. Este objeto procesará de definición de un cuarto, imagen de fondo, área caminable, eventos, elementos contenidos, etc... posicionandolos en pantalla y definiendo los eventos y transiciones de cada cuarto Elemento. El Elemento es el objeto base del desarrollo, los elementos son los objetos y personajes dentro del cuarto. Un elemento puede contener a su ver mas elementos y puede contener acciones o modificaciones de comportamiento de bloques de sistema para un área concreta. Esta clase se encarga de almacenar los elementos en memoria y mantenerlos actualizados a lo largo del juego/presentación Verbo. Así como el Elemento es la base del desarrollo de objetos el Verbo es la base del desarrollo de acciones, el verbo dispara los eventos y las acciones. Su posición típica esta dentro del bloque de sistema aunque su comportamiento puede ser modificado en cada cuarto o para cada elemento. Esta clase se encarga de leer la definición de los verbos y mantenerlos actualizados durante todo el juego/presentación. 10/13 LSAGPI- Documentación Preliminar del Proyecto

11 3.6.-Acción. Las acciones son secuencias de procedimientos o funciones que se activan cuando un verbo lanza un evento, o bien cuando se declara un procedimiento secuencial (ejemplo, transición animada, presentación no interactiva, etc...) Esta clase se encarga de gestionar dichas acciones Expresión. Denominamos expresiones a las operaciones lógicas de evaluación que dan como resultado un valor booleano. Dichas expresiones deben evaluarse para seguir un camino de acción u otro según sea la expresión verdadera o falsa. Esta clase y las dependientes de ella como EvaluarExpresion leerán las definiciones de las expresiones en código fuente y las valoraran en tiempo de ejecución cuando se soliciten Inventario. La clase inventario define un vector de Elementos y los mantiene actualizados durante todo el desarrollo del juego/presentación Animación. Esta clase se ocupa de generar las animaciones a partir de los frames de los elementos. Los detalles de dichas animaciones están definidos en la clase de Sistema, pero las imágenes así como la carga de ellas y la actualización de posición del personaje las lleva a cabo esta clase. 11/13 LSAGPI- Documentación Preliminar del Proyecto

12 4.-Pruebas del motor de Script. Una vez desarrollado el motor hasta un estado de tipo alpha se desarrollará un cargador que dibuje en una ventana lo que defina el motor. Debemos tener muy claro que el motor será el mismo para todas las implementaciones independientemente del lenguaje usado pero el cargador, necesariamente debe cambiar ya que no es lo mismo una ventana en Win32/Linux/OSX, que en Android/Blackberry/Webos o en modo Applet o en J2ME, aunque el concepto es el mismo el contenedor es necesariamente diferente Presentación Interactiva. Las pruebas en modo presentación interactiva constarán de un código fuente que defina una serie de acciones en modo presentación. La presentación de prueba versará sobre el motor de script y servirá así mismo como documentación complementaria para el usuario final del motor Aventura Gráfica. Para las pruebas de aventura gráfica, se portarán 3 cuartos de alguna aventura gráfica libre aún por definir, para evaluar su desempeño en esta tarea. Debemos tener claro que, si bien es posible terminar a tiempo y con un alto grado de estabilidad la parte de presentaciones interactivas, no es seguro que esta parte tenga la estabilidad y madurez suficiente en el periodo de concurso y requiera mayor trabajo a posteriori. 12/13 LSAGPI- Documentación Preliminar del Proyecto

13 5.-Más allá de este documento. Dentro de este proyecto esta planificado un Entorno de Desarrollo Integrado (IDE) para minimizar la posibilidad de errores de codificación y agilizar el trabajo con el motor de script. Este motor, aunque será multiplataforma, no podrá usarse en dispositivos empotrados ya que no considero práctico ni útil su uso en teléfonos móviles, pda o videoconsolas. Se realizarán versiones para Win32/Linux/OSX (y plataformas OpenJDK). Pero este asunto no entra en principio dentro del ámbito del proyecto básico por razones de tiempo. No obstante, si hay tiempo se añadirá el IDE al proyecto cuando este en fase beta. 13/13 LSAGPI- Documentación Preliminar del Proyecto