Miguel Angel Pescador Santirso © 2009/2010.

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

Miguel Angel Pescador Santirso © 2009/2010.

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:

http://es.wikipedia.org/wiki/Licencia_de_documentaci%C3%B3n_libre_de_GNU

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

Miguel Angel Pescador Santirso © 2009/2010.

Indice

1.-Definición del paquete de aventura.

1.1.-Estructura del paquete.
1.2.-Sistema de Compresión.
1.3.-Acceso a datos.
2.-Definición del Lenguaje de Script.
2.1.-Bloques.
2.2.-Procedimientos.
2.3.-Variables.
2.4.-Operadores.
2.5.-Funciones.
3.-Implementación del motor de Script.
3.1.-Pre-procesador.
3.2.-Sistema.
3.3.-Cuarto.
3.4.-Elemento.
3.5.-Verbo.
3.6.-Acción.
3.7.-Expresión.
3.8.-Inventario.
3.9.-Animación.
4.-Pruebas del motor de Script.
4.1.-Presentación Interactiva.
4.2.-Aventura Gráfica.
5.-Más allá de este documento.

3/13 LSAGPI- Documentación Preliminar del Proyecto

Miguel Angel Pescador Santirso © 2009/2010.

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.

1.1.-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

Miguel Angel Pescador Santirso © 2009/2010.

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).

1.2.-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).

1.3.-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

Miguel Angel Pescador Santirso © 2009/2010.

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

Miguel Angel Pescador Santirso © 2009/2010.

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.

2.1.-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

Miguel Angel Pescador Santirso © 2009/2010.

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
2.2.- 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

Miguel Angel Pescador Santirso © 2009/2010.

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.

3.1.-Pre-procesador.

Dado que el archivo fuente debe admitir comentarios nuestro pre-

procesador 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

Miguel Angel Pescador Santirso © 2009/2010.

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.

3.3.-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.

3.4.-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.

3.5.-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

Miguel Angel Pescador Santirso © 2009/2010.

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.

3.7.-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.

3.8.-Inventario.

La clase inventario define un vector de Elementos y los mantiene

actualizados durante todo el desarrollo del juego/presentación.

3.9.-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

Miguel Angel Pescador Santirso © 2009/2010.

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.

4.1.-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.

4.2.-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

Miguel Angel Pescador Santirso © 2009/2010.

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