dapmanual

DOCUMENTACIÓN DE DAP

VERSION 5.02

programado por Javier Basilio

(Jaba)

"Mejor compañía aventurera de 1995"

(IV PREMIOS DE LA AVENTURA)

Manual NO revisado por D.Antonio Vaquero

Director de la E.S.I.

Esta versión está dedicada a todos los que dijeron de uno u otro modo

que DAP era pobre visualmente y que Jaba no sabía programar la VGA.

Gracias por picarme.

Algunas cosas que se han dicho de DAP:

"Hace incluso demasiado fácil la creación de aventuras" - Fran Morell,

ex-presidente del Year Zero Club

"¿Qué tiene este parser que no tengan los demás?...lo sencillo que resulta

usarlo" - Daniel Cárdenas, presidente de Spanish Quest, en el fanzine

CAAD.

"Definitive ha matado moscas a cañonazos con la versión 5" - Zona Zero

*********************************************************************

Este manual se divide en tres partes:

Parte I : Presentación y descripción del producto.

Parte II : Conceptos básicos y ejemplos de creación de una

aventura.

Parte III: conceptos avanzados del parser.

*********************************************************************

PARTE I: PRESENTACION DEL PRODUCTO

*********************************************************************

DISTRIBUCION -----------------------------------------------

Hasta la versión 5.01 DAP era un producto Shareware. Sin embargo,

debido al preocupante bajón que ha sufrido el mundo de la Aventura, y

tras escuchar varios consejos y recibir muchos ánimos por parte de

buenos amigos, he decidido pasar la versión 5.02 al Freeware. Esto

quiere decir que este programa es totalmente gratuito; podrás usarlo,

distribuirlo entre tus amigos,etc... sin tener que pagar nada. Incluso

podrás distribuir los juegos que crees completamente gratis, eso sí,

no estás autorizado a hacerlo comercialmente o por Shareware, tus juegos

deberán ser igualmente gratuitos. Si insistes en ganar dinero con tus

aventuras, deberás entrar en contacto conmigo para obtener una licencia

especial. DAP es, a pesar de ser Freeware, un producto registrado, pro-

tegido por la ley, y que debe permanecer inalterado y sin modificaciones.

Puedes contactar conmigo para consultas, dudas, pedidos de nuevas

versiones, insultos, donaciones en metálico o especias, etc... en la

dirección:

Apdo. de correos 166

28922 Alcorcón (Madrid)

ESPAÑA

Por Internet, en sytovos@hotmail.com

Recuerda mi página oficial, con una sección de DAP:

http:://www.oocities.org/siliconvalley/grid/2294

Además me gustaría poder ver cualquier aventura que puedas crear, y

especialmente me gustaría recibir motores gráficos creados por los usua-

rios para incluirlos en DAP.

Si tienes cualquier duda o consejo, o si símplemente te apetece

hablar, ¡ESCRIBEME!

EL AUTOR ---------------------------------------------------

Jaba(Javier Basilio) nace en Madrid, 1978. Desde pequeñito

se agenció un Spectrum y dió la paliza a todo el que le ro-

deaba con sus últimas rutinas en ensamblador. Posteriormen-

te evoluciona al Amstrad CPC y crea un horrible programa

llamado DAP. Años más tarde se une al Year Zero Club como

colaborador, y, posteriormente, como redactor, para acabar

de director y redactor jefe; mientras tanto se dedica a per-

feccionar DAP, y crea algunas aventuras, siendo la más cono-

cida "Colosal Pirámide". Actualmente estudia 4º de Ingeniería

Superior Informática en la UCM y se dedica a jugar al HEXEN2 y

a acudir a conciertos de Heavy Metal, habiendo dejado ligera-

mente de lado las aventuras para buscar retos más reales, como

la exploración en tiempo real de tumbas egipcias; a pesar de

eso sigue mimando su DAP, para completa desgracia de toda la

comunidad informática en general y aventurera en especial.

INTRODUCCION -----------------------------------------------

(= publicidad gratuita de DAP)

"En algún lugar cerca de aquí se encuentra la Caverna Colosal,

donde otros han encontrado fortunas en joyas y tesoros, aunque

algunos de los que entran jamás vuelven a ser vistos. Se dice que la

cueva es mágica [...]"

Así comienza el primer juego conversacional de la historia:

"Adventure", de Woods y Crother. Los juegos conversacionales son

especiales para muchos, han levantado pasiones y han roto cabezas.

Son únicos e inimitables. Son, con toda certeza, el más profundo

juego, el entretenimiento más perfecto, que puedas encontrar en un

ordenador de cualquier clase. Actualmente las grandes compañías nos

acosan intentado vender basura con espectaculares gráficos SVGA y

enormes enemigos, o una especie de intentos de Aventura, esas cosas

llamadas "aventuras gráficas" que insultan nuestra inteligencia y

buen gusto (tengo que excluir de aquí al Monkey Island, si me lo per-

mitís - bueno y algunas más, pero no vamos a estropear lo poético del

párrafo anterior, ¿verdad?). Una gran definición de Aventura es la

que aparecía en el glosario del manual del Amstrad CPC "Una

pasión para unos, un aburrimiento para otros".

Personalmente me encuentro entre los primeros.

Todavía hoy quedamos muchos aventureros que, contra viento y

marea, con el único apoyo de nuestra amistad, nos mantenemos unidos

en el recuerdo de este gran mundo que aun hoy tiene más fuerza que

nunca, al menos entre nosotros.

Si eres uno de esos aventureros incorruptibles, este programa

es lo que necesitas. Representa la culminación de un sueño: el parser

español. Como sabrás, un parser es una utilidad especialmente

diseñada para la generación de juegos de aventura.

La idea de DAP nació cerca de 1988, cuando la aventura se

encontraba en una gloria comercial transitoria (por aquel entonces

atraía las miradas de las grandes empresas) y el mercado estaba

indundado por parsers... en inglés: léase PAWS, GAC, ILUSTRATOR ...

Empero, estos parsers fallaban en un concepto que para mí era

fundamental: eran realmente lenguajes de programación diseñados para

fabricar aventuras. Es ahí donde yo no entendía (ni entiendo) la

postura de sus programadores. Como ejemplo, actualmente existen más

parsers de factoría nacional, pero son compiladores de lenguajes (más

o menos complicados) que se limitan a leer un fichero ASCII con las

instrucciones del programa, siguiendo el clásico modelo del

compilador. ¿Y esto para qué? Para eso puedes coger tu compilador

favorito de "C" o de Pascal y programar una aventura usando

seguramente muchos más recursos de los que te va a ofrecer ese parser

X. Tal vez el lenguaje sea algo más complicado, pero vas a poder

hacer cualquier cosa. Además, aprender "C" es seguramente más

productivo que aprender un parser, porque los conocimientos de "C" te

servirán para programar lo-que-sea, algo que no podemos decir del

parser.

Es en esto donde DAP es esencialmente diferente del resto de

parsers, tanto extranjeros, como españoles. La filosofía de DAP es

radicalmente distinta. DAP consiste en un entorno de desarrollo,

donde, a través de cómodos menús, definimos la base de nuestra

aventura, con pulsaciones y a una velocidad increíble, con un

facilidad extremadamente alta, de tiempo de aprendizaje mínimo. Para

crear tu aventura no necesitas aprender ningún extraño lenguaje de

programación.

Sin embargo,hay puntos donde programar es inevitable. Cuando

queremos expresar al DAP qué queremos que suceda, por ejemplo, si el

jugador introduce la tarjeta en el cajero, es necesario programar una

pequeña subrutina. Pero esta programación se realiza usando un

sencillo lenguaje batch, que, como comprobarás, es de tan escasa

dificultad que aun resulta irrisorio utilizar esa palabra.

Las posibilidades técnicas de DAP son únicas y no se

encuentran en otros programas de este estilo: es el primer parser que

ha sentado la norma de uso del modo TWEAK de la VGA. Es el único con

soporte de música digital y que permite realmente crear una aventura

desde menús y sin programar. Fue pionero en el uso de código de 32

bits especialmente preparado para el procesador 80386. Ahora ha sido

el primero en incorporar los nuevos opcodes del 80486.

Esta versión posee unas características gráficas extremadamente

potentes. Anteriormente DAP había recibido numerosas críticas por ser

un parser en modo texto. Con la versión 5.00 esperamos ahogarlas.

Algunas de las características gráficas de DAP, como la

versatilidad que ofrece el uso de un motor gráfico,eran inéditas

hasta ahora.

GODS OF WAR, FEEL THE POWER OF MY DAP !!!

Jaba

OTROS SISTEMAS ---------------------------------------------

Existen otros parsers españoles actualmente. Que yo sepa,

son CAECHO,SINTAC,CUTRA,PROMETEO y NMP. Cada uno es como to-

do en esta creación; tiene sus virtudes y sus defectos. Lo que

he intentado en DAP es que las virtudes se crezcan sobre los

defectos.

Todos esos parsers, excepto CUTRA, tienen el problema que

ya he mencionado, en algunos, es posible que aprender ensam-

blador sea más fácil que ponerlo en marcha (no mencionaré

cuales para no granjearme enemistades con autores que actual-

mente considero mis amigos :-D ).

CUTRA es un parser cuasi-compatible con el DAP; usa un jue-

go de instrucciones similar e incluso existen conversores de

aventuras entre DAP y CUTRA. Su autor es Alberto Salazar

Palomo. Tiene la particularidad de generar código en PASCAL

en lugar de crear directamente una aventura, lo cual tiene

algunas ventajas evidentes.

Saludos a todos los creadores de parsers. ¡La competencia es

fundamental para aumentar la calidad!

SALUDOS ----------------------------------------------------

- Fran Morell, David Miraut, Daniel Cárdenas, Ramón Fusté,

Alberto Salazar,etc...

- Al Barbutis, a Mike&Ivanof, a Mijelh, al Parleño, a Julitorr,

a David (el c*b**n que me j**d**o la noche del sábado, perro

más que perro), y con especial cariño a LaTete y al Mentor. A

cualquier otro elemento o ser de la Escuela Superior de Infor-

mática de la Universidad Complutense de Madrid, exceptuando

a Lapaca, a quien le envio una amorosa patada en el culo.

- A todos los brothers of true metal que han ardido en el

fuego del verdadero metal. Manowar forever. ¡Hail brothers!

Estamos en el viaje hacia la gloria. Death to the false ones.

REQUERIMIENTOS DE SISTEMA ----------------------------------

- Un ordenador PC basado en 80386 o superior.

- Sistema MS-DOS 5.00 o compatible (OS/2, etc.)

- Tarjeta compatible IBM VGA.

- Al menos 3096K de memoria. Ciertas partes del programa están

escritas en modo protegido y podrían no funcionar con menos memoria.

- Para el sonido, una tarjeta Sound Blaster, o Sound Blaster

Pro para sonido estéreo. Con Sound Blaster 16 y tal, deberás escuchar

la música en modo "Sound Blaster (mono)", pues el modo estéreo de la

Pro no es compatible con las nuevas tarjetas.

PROBLEMAS CONOCIDOS ----------------------------------------

- Algunas tarjetas gráficas, como la S3 VIRGE, dan problemas

con el modo gráfico del ID. Si encuentras algún probema en

la visualización de ID, ejecútalo así:

ID50 -fixvideo

- No funciona con versiones de OS/2 anteriores a WARP.

- Windows 95: en ordenadores 486 DAP no funciona correctamente.

En Pentium, sí que lo hace. Este problema sucede con muchas

aplicaciones DOS extrañas (como Duke Nukem) y no sólo con DAP.

En realidad, la explicación debe buscarse en el modo virtual 86

mejorado del Pentium.

- Windows 3.x: No way!

- Es necesario tener activo el BLOQUEO NUMERICO bajo Id.

(¡esto es importante!)

- Algunas tarjetas CIRRUS bus local Vesa tienen problemas con

la Soundblaster. Esto es debido a un problema que tienen estas

tarjetas CIRRUS, que provoca que se entrometan en las transfe-

rencias DMA a la tarjeta de sonido. Este problema también apa-

rece en muchos programas, no sólo en DAP.

- ¡UNIVESA y DAP parecen no ser buenos amigos! Esto es provo-

cado por la forma en la que DAP modifica a placer todos los

registros de la VGA.

COMPATIBILIDAD CON JUEGOS DE ANTERIORES VERSIONES ----------

Hemos realizado un gran esfuerzo para mantener la

compatibilidad con versiones antiguas, el resultado es que los

ficheros creados con DAP 2.1 y posteriores pueden ser empleados

directamente.

Si usas DAP 1.x o 2.0 , deberás pedirme un adaptador especial.

Este adaptador está también disponible en mi WEB (ver la dirección al

principio de este documento).

DAP podrá leer automáticamente ficheros de versiones 2.10 y

superiores.

Sin embargo, y en lo referente a los PSI, ahora que DAP los

maneja de distinta forma, siento decirte que al abrir un fichero

antiguo se perderá la información de las respuestas de los PSI

(un mal menor, comparado con la potencia del nuevo sistema).

FICHEROS DEL PROGRAMA --------------------------------------

EN EL DIRECTORIO C:\DAP50\ -> programa principal:

ID50.EXE-> es el creador de aventuras, el entorno de

programación.

RT50.EXE-> ejecuta las aventuras y las depura. Sintetiza los

programas de versiones anteriores RT33,DEBUG33 y

NOSB.

CREATE.EXE-> prepara un juego en el directorio GAME para su

distribución comercial.

BAT2EXEC.COM > fichero auxiliar de CREATE, de dominio público.

SHELLVT.EXE -> el reproductor MOD (C) VangeliSTeam.

Dominio público - distribución libre

DTYPE.EXE -> auxiliar de RT40.EXE

SOUNDSET.EXE-> auxiliar de CREATE.EXE

FASTDRI.EXE -> auxiliar de CREATE.EXE

MANUALES.BAT-> para ver los manuales

TEST.EXE-> auxiliar de varios módulos.

DOS4GW.EXE-> auxiliar de varios módulos.

PMINFO.EXE-> informa del rendimiento del ordenador en modo

protegido.

EL EL DIRECTORIO C:\DAP50\DRIUTIL\ -> utilidades para el

trabajo con gráficos DRI

(DAP sólo usa gráficos

DRI)

G2DRIX.EXE -> convierte un fichero GIF 320x200x256 al formato

nativo de DAP, DRI. Permite realizar algunos

efectos durante la conversión (ejecutarlo sin

parámetros para ayuda), como son la conversión

a escalas de grises o inversión de la imagen.

Además, reduce el número de colores del dibujo

de modo que no interfiere con DAP.

Varios ejemplos de gráficos GIF y sus versiones DRI.

EN EL DIRECTORIO C:\DAP50\DOC\-> documentación del paquete

DAP50.DOC-> este archivo.

ID50.DOC -> guía de referencia del lenguaje de programación.

BUG.DOC-> hoja para reportar errores en la versión Beta.

DRI.DOC-> descripción del formato gráfico DRI.

LENDO.COM-> lector de los manuales.

ENGINE.DOC -> especificación 2 de un motor gráfico DAP.

EN EL DIRECTORIO C:\DAP50\DATA\ -> los ficheros TLT y fuentes

de aventuras.

BOSQUE.-> Fuentes del Bosque Maldito

POWER1.-> Fuentes de "Search of the Power I"

BOSQUE.TLT -> Pantalla de carga del Bosque Maldito

POWER1.TLT -> Pantalla de carga de S.O.P. I

EN EL DIRECTORIO C:\DAP50\EXEC\ -> los ficheros .DAP,

aventuras compiladas.

POWER1.DAP -> Search of The Power I

BOSQUE.DAP -> El Bosque Maldito

EN EL DIRECTORIO C:\DAP50\GAME\ -> aquí se generan los juegos

comerciales creados por

CREATE.EXE

EN EL DIRECTORIO C:\DAP50\MUSIC\-> almacena aquí los ficheros

MOD y S3M que uses

EL MOTOR GRAFICO ------------------------------------------

Para comunicarse con tu tarjeta gráfica, DAP utiliza lo que en

Definitive hemos llamado "Motor Gráfico", que no es más que un

programa residente que proporciona una serie de servicios están-

dar para acceder a la tarjeta gráfica (algo así como un driver).

A través del motor gráfico, DAP imprime carácteres, pixels,

realiza cambios de color, etc...

Nosotros te proporcionamos el motor gráfico estándar de Defini-

tive, DEFGK. Este motor está diseñado para el micro 486, con ins-

trucciones específicas de éste, y es extremadamente rápido. So-

porta una resolución de 320*200 puntos y 256 colores. Debes

cargarlo antes de DAP. Está totalmente escrito en código máqui-

na, y optimizado para someter a las unidades de ejecución para-

lelas de Pentium a un bombeo continuo de instrucciones.

El uso de un motor permite a DAP cambiar de tarjeta gráfica

cambiando sólo éste. P.ej, Definitive proporcionará a sus

usuarios en breve un motor gráfico para VESA, que soportará

800*600 puntos y 256 colores. También puedes diseñar tu propio

motor gráfico DAP para tu tarjeta. Las especificaciones que

deben cumplir los motores gráficos de DAP y los servicios

que deben prestar a DAP, así como las convenciones de llamada

están disponibles para quien las desee, de modo que puedes hacer

tu propio motor gráfico ... si crees que el nuestro es lento.

La especificación completa está en ENGINE.DOC. Además, Definitive

dispone de un "Kit de Desarrollo de Motores Gráficos", por si

no te es suficiente. Si necesitas ayuda creando un motor gráfico,

no dudes en escribirnos.

El uso de tu propio motor gráfico permite además modificar la

salida para, por ejemplo, variar las fuentes, o hacer otros efec-

tos tan sólo limitados por tu imaginación.

El orgón CALLENGINE de DAP permite realizar llamadas directas

al motor gráfico, con lo cual resulta sencillo incluir tus

propias funciones para, p.ej, cambiar de fuente de texto. Las

funciones 20-30 del motor gráfico están reservadas para

funciones propias del desarrollador, y no serán ocupadas por

futuras especificaciones del motor gráfico.

Parámeros.- si tienes problemas de niebla (p.ej, en tarjetas

TRIDENT antiguas), ejecuta DEFGK con el parámetro /SLOW.

La lista completa de parámetros está en el documento DEFGK.DOC

Ultima hora.- antes de lanzar la versión final de DAP hemos

incluido un nuevo motor gráfico, 386BIOSGK.COM. Este motor

está en el directorio UTIL. Se ha diseñado para una compa-

tibilidad máxima. Usa instrucciones de 386 en lugar de

opcodes para 486, y las operaciones con la tarjeta gráfica

se realizan a través de la BIOS de la misma en lugar de

directamente. Es bastante más lento pero debe servirle a

cualquiera que tenga algún problema con el DEFGK.COM estándar.

DEMOSTRACION -----------------------------------------------

Se incluye como ejemplo una versión abreviada de la primera

parte de la aventura "Search of The Power". Para compilarla:

Ejecuta CREATE.

Introduce como nombre de aventura POWER1, y como nombre de

fichero de música, AX4.MOD.

Copia los ficheros DEFLOGO.DRI, LOWDUNES.DRI y NAVAJO.DRI al

directorio GAME desde el directorio DRI.

Recuerda cargar un motor gráfico para DAP (normalmente será

DEFGK. Incluso podrías ponerlo en tu AUTOEXEC.BAT, debido a que la

cantidad de memoria que ocupa es insignificante).

El juego está en el directorio GAME. Ejecuta SETUP para confi-

gurar el sonido. Comienza el juego con POWER1.COM

¡Buena suerte!

UN POCO DE HISTORIA ----------------------------------------

(INTO THE GLORY RIDE)

DAP 1.0 --- Primera versión para Amstrad CPC; 90 localidades y

(1988) 19 objetos.

DAP 1.0FX - Versión de lujo del DAP 1.0 para CPC. Se corrigen

(1995) todos los bugs que achacaban a la antigua versión.

DAP 1.1 --- Conversión de la v 1.00 a DOS. Correción de varios

(1991) bugs.

DAP 1.2 --- Nueva orden LOBJ que potencia enormente las

(1992) posibilidades. 13 Bugs arreglados. Inclusión de

pantalla cabecera. Ordenes INFO OBJ e INFO LOC.

Mejora general de la presentación. Inclusión de

ficheros TLT de presentación.

DAP 2.0 --- Aumento enorme de número de objetos y localidades.

(1993) Inclusión de gráficos PCX. Resolución de los

siguientes bugs:

- La orden VAL no funcionaba adecuadamente si no se

invertían los parámetros: solucionado;

- Si existían varios procedimientos con el mismo verbo, los

que no fueran el primero definido no funcionaban

correctamente: solucionado.

Se puede considerar la primera versión seria del DAP.

DAP 2.1 ---- Inclusión de las órdenes VER PAL, LIST PAL y

(1993) CHANGE PAL para editar procedimientos ya creados.

Orden VER INFO. Arreglado el BUG que sólo

permitía usar 3 objetos con el programa. Cambio

de gráficos PCX a gráficos GIF. ¡¡Inclusión de

animaciones FLI!! Juraría que había incluido save

y load en todas las versiones, pero al parecer un

pequeño despiste al adaptar la versión 1.0 a PC

hizo que no aparecieranen las 1.1, 1.2 y 2.0.

Aquí están de nuevo. Alguien se quejó de que 40

mensajes eran pocos. Espero que con 300 os sea

suficiente.Tambien de que 51 instrucciones eran

pocas. Ahora hay 80.

A partir de esta versión el DAP es distribuido

por el Sindicato del Software además de por

shareware.

ADAP 3.0 --- Como vas a ver, esta versión supone la MAYOR

(1994) reestructuración del DAP desde su creación, de

hecho estás ante un parser TOTALMENTE NUEVO.

Se incluyen las ordenes PRINT OBJ y PRINT LOC. El

lenguaje de programación incluye ahora nuevas

ordenes GOTO, SCORE, SHELL, COLOR, PRINT y

CAMTXT. He reparado el bug cuando el jugador

alcanzaba el límite de objetos al intentar coger

otro no fuera advertido de esto, solamente no se

realizaba la acción. Ya funciona bien. Además hay

un reportorio general de mejoras internas.

¡¡Por fin!! Se puden compilar los juegos a un

archivo. Soporte de ficheros MOD SB, SB-Pro, SB-

16, Adlib y DAC. Los ficheros compilados no se

pueden ni ver ni abrir.

Se ha pasado al modo gráfico VGA, preparando el

camino para integrar gráficos con texto. Medidas

de seguridad. Sólo se puede cargar un juego

grabado desde la aventura que lo grabó. ¡Por

fin, soporte de PSIs! Se puede cambiar el color

de la pantalla. Se pueden redefinir las

respuestas básicas y usar librerías de mensajes

en formato .MSG. Se ha mejorado el INPUT de

descripciones y mensajes para mostrar el espacio

disponible y el resultado final, además de

admitir tildes y eñes. Se ha incluido el entorno

prometido de desarrollo bajo menús.

Nueva orden ADDVAL, útil para mantener un

indicador de energía o una puntuación secundaria.

Nuevas órdenes LOCG y OBJG (estas tres para el

lenguaje de programación).

Nuevas órdenes VAADVAL, COPYVAL, COPYTXT, PLAY y

DRAW. ¡Integración de gráficos y texto!

Se admite nuevo parámetro en las órdenes

referentes a localidad de objetos, 998, que

significa en posesión del jugador. Se incluye una

utilidad externa para compilar aventuras.

Arreglado un bug en LOBJ.

Inclusión del debugger. Más órdenes: PSI, LPSI

y... SINOM, que sirve para crear sinónimos.

Creación de aventuras ejecutables .COM. Se pueden

poner ficheros de cabecera de gran longitud, el

DAP va haciendo las pausas necesarias. ¡Se le

pueden quitar objetos al jugador usando la orden

LOBJ! Simplemente haciendo un LOBJ a un objeto

que tenga el jugador a una localidad que no sea

998, éste se esfumará de sus manos (je,je).

Se divide el DAP en módulos (una especie de

Orverlays) para reducir los requerimientos. Gran

parte del código original y varias rutinas nuevas

están reescritas en "C", con lo cual se aceleran

bastante.

Se incluye una opción en el nuevo entorno del ID

para probar las aventuras con el debugger sin

salir de él.

Dentro del debugger se pueden cambiar o ver

valores de flags, etc. Añadido el Control Center

para Windows.

Simplifica el uso de los diferentes módulos y la

integración bajo Windows. Requiere al menos

Windows 3.0 en modo estándar. Añadida grabación

de emergencia en el ID. El ID no se cuelga al

intentar abrir una aventura que no exista.

Incluida orden PAUSE.

ADAP 3.0fx - Incluido el comodín "*" para definir

(1994) procedimientos. ¡Esto es extremadamente

interesante!. Documentada la orden PAUSE.

ADAP 3.10 - Soporte de control horario incluido. Tres nuevas

(1994) órdenes EDAP: PRINTVAL,VALMAYOR y VALMENOR. Cuatro

nuevos flags (tres de ellos de sólo lectura)

incluidos para gestionar el soporte horario.

Incluida la utilidad SOUNDSET, que modifica la

configuración del sonido automáticamente. ADAP se

ejecuta sobre NDOS y 4DOS (la v 3.00 no lo hacía).

Arreglado un bug en las rutinas de grabación y

carga de situaciaciones.

Arreglado un bug en el debugger. Prueba de fuego

para el ADAP: SOMETHING se realizó mientras se

creaba el ADAP 3.10, para corregir los errores del

sistema. El resultado es un increible depurado y

una aventura de infarto.

ADAP 3.10fx - Arreglado WINDAP. Organización en

(1994) subdirectorios. Todo el código se ha reescrito

con instrucciones del juego 286, lo cual supone:

a) mejora del rendimiento, y

b) cese de compatibilidad con los XT :-(

ADAP 3.20 - Mejoras en la presentación.

(1995) Se puede salir al "shell" desde el ID.

El cambio más significativo es el nuevo formato

gráfico DRI (explicado más adelante). Se siguen

soportando ficheros FLI a través de AAPLAY.

Fundidos opcionales al mostrar gráficos.

El entorno clásico ha sido eliminado.

No hay distorsiones en la música con los gráficos.

Preparado para el concurso de IBM.

El proceso de crear ejecutables es más sencillo y

rápido.

Menús para la definición de procedimientos.

Soporte total del MODE X (320x240x256) de la VGA.

Los GIF al convertirse al formato nativo DRI ganan

bastante calidad al aumentar de resolución.

Mejor control de los directorios.

Bugs arreglados.

El ID admite una aventura como parámetro que será

abierta automáticamente.

Scroll integrado.

Sonido al teclado.

Desaparece el módulo de DAP para Windows.

DAP 3.30 -> Versión con instrucciones de 32 bit adaptada

(1995) al procesador 80386. Bastantes mejoras internas y nuevas

opciones.

DAP 4.00 -> Una versión totalemente nueva, con un buen número

(1996) de grandes cambios que aumentan mucho más la

potencia del parser.

¡Ya! Disponibles los "glolo", programas EDAP que

se ejecutan global o localmente.

DEBUG.EXE ya no es necesario. Para depurar una

aventura, ejecutar RT40 con el parámetro -d.

Se ha incorporado un generador de números alea-

torios, accesible mediante dos nuevos flags,105 y

106. Nuevos flags que informan de la versión del

programa y localidad del jugador (hasta 111).

Se ha restructurado la gestión de memoria, y ahora

pueden almacenarse 100 procedimientos de acción

y 40 procedimientos glolo, que deberían ser más

que suficientes en mi opinión.

Nuevo "look" del creador de salidas del ID.

Mejorado el sistema SOUNDSET. Ya no existe el fi-

chero NOSB.

Pueden definirse los colores del juego con gran

facilidad. Gestión de dinero, y flag propio para

cada objeto. La compra/venta de objetos es ges-

tionada automáticamente.

Nuevo sistema de menús.

Se pueden cargar las librerías directamente desde

ID. Ha desaparecido el viejo MSG??.EXE.

Líneas superiores.

Control de dinero integrado. Se puede poner precio

a los objetos para simular la compra de los mismos

en mercados, etc.

Añadido un flag de estado a los objetos. Esto

puede servir para indicar si están llenos,

vacios... sin recurrir a los flags estándar.

El flag 107 indica el dinero que tiene el jugador.

Multitud de nuevos orgones que permiten realizar

al programador casi cualquier cosa que se le

ocurra.

Añadida la pila, una nueva y poderosa estructura

de trabajo con datos numéricos.

Nuevos orgones para trabajo con la pila.

Debugger adaptado para manejar la pila y depurar

errores con facilidad.

Arreglado el bug de paleta en el conversor

GIF->DRI.

DAP 4.00 fx -> Mejoras sustancionales en el ID.

(1996) Arreglado el problema de los colores en las

presentaciones.

Mejora del rendimiento.

DAP 5.00 -> ¡Plena potencia gráfica!

(1997) Total control simultáneo de gráficos y texto.

Posibilidad de texto RGB.

Visualización de DRI en ventanas.

Ventana de texto.

Fundidos.

Ciclos de colores (nuevos orgones).

Comunicación por la tarjeta por motores gráficos.

Nuevas rutinas de Input.

Numerosos detalles incorporados por todas partes.

Al listar un procedimiento EDAP, cuando se hace

referencia a un mensaje también se muestra el

contenido del mensaje, aumentando la legibilidad

y comocidad.

Ahora los PSI en vez de llevar asociadas unas

respuestas ctes., responden a cada frase con

un procedimiento EDAP, haciéndolos infinitamente

más potente, estando el límite sólo en la imagina-

ción.

Posibilidad de llamar a rutinas propias en ensam-

blador desde el DAP.

Arreglado un problema con LPSI.

DAP 5.00fx-> Realmente he solucionado muchos problemas que

31/12/97 aparecieron en la primera versión de DAP 5.00,

pero ... ¡no me acuerdo de ninguno!

DAP 5.01 -> Pequeño "patch" para ID50. En las tarjetas

3/3/1998 gráficas S3 Virge (muy extendidas actualmente)

el modo gráfico que utiliza ID no funciona co-

rrectamente. Si experimentas algún problema,

ejecuta ID50 con la opción -fixvideo

DAP 5.02 -> Primera versión Freeware. No hay más cambios

significativos, excepto una documentación

corregida.

POSIBILIDADES ----------------------------------------------

98 Localidades, 50 Objetos, 10 Personajes, 301 mensajes de

usuario, 100 posibilidades de léxico (verbo+nombre), artículos

castellanos y preposiciones, 111 flags que pueden contener cualquier

valor de 32 bits, lo que lleva a más de 10 millones de situaciones de

juego. Movimientos norte, sur, este y oeste por defecto. Completo

soporte horario de horas,minutos y días, con temporizador controlable

por el usario. Cada personaje tiene 20 respuestas asociadas, a cada

una le corresponde un subprograma que indica la acción a realizar.

40 procedimientos globales/locales.

Cada localidad puede tener asociada un gráfico en formato DRI

Generador de números aleatorios. Gestión automática de dinero y

compras/ventas. Pila. 40 Procedimientos globables/locales.

Sonido en formatos MOD, STM, NST, 669, S3M, etc. de hasta 36

canales. Se soportan SB y SB Pro (Obra de VangelisTeam)

Completo control gráfico. Manejo de la paleta de la VGA.

Autodetección de niebla en pantalla y corrección.

*********************************************************************

PARTE II: LA PRIMERA AVENTURA

*********************************************************************

PRINCIPIOS BASICOS -----------------------------------------

La creación de una aventura debe resumirse en los siguientes

pasos:

1- Planificación

2- Texto

3- Objetos y personajes

4- Vocabulario

5- Procedimientos globales/locales (opcionalmente)

6- Gráficos (opcionalmente)

El módulo ID50.EXE contiene el entorno de programación

integrado. Considerando a "Adventure" como el juego tradicional de

texto, tendremos, según la descripción que Tim Gilberts daba:

Un mundo imaginario. Primero se llama a una rutina que lo

describe. El estado del mundo es el estado del juego. Después se pide

una orden al jugador y, si es posible, se ejecuta. Probablemente el

estado de juego cambie y haya que volver a describirlo. Esta rutina

se divide en dos partes:

- Localidades: Son lugares visitables e inmutables; descritos

con un texto y, opcionalmente, con un gráfico. El texto puede variar

a lo largo de la aventura para reflejar cambios en el estado de las

mismas.

- Objetos: es lo que puede manipular el jugador. Básicamente,

pueden cogerse y dejarse, además de transportarse. Pueden llevar aso-

ciado un precio, en este caso es necesario que el jugador posea la

suficiente cantidad de dinero como para adquirirlo (al cogerlo

se realizará "automáticamente" la compra). Una vez adquirido, el

objeto puede volver a cogerse sin pagar por él.

- Personajes (PSI): un tipo especial de objetos que

representan el papel de otros personajes en el mundo. Puede

conversarse e interactuar con ellos.

Debe existir otro sistema que lea el mandato del jugador y lo

convierta en cambios del estado de juego. Esta rutina es a la aue se

le llama "parser" propiamente dicho ("parse" significa "analizar

sintácticamente", en inglés) y capta una línea de texto.

A las localidades, objetos y PSIs se les asigna un número de

identificación (el número de la localidad donde está el jugador en

este momento es el "here"), y un texto de descripción.

LAS BANDERAS O FLAGS.- Son un grupo de indicadores (111 en el

DAP) que informan sobre el estado de juego. Por ejemplo, el programa

debe saber si el jugador ha tocado un botón en la estancia 9 para que

el ordenador de la estancia (estancia=localidad) 38 esté encendido.

Al pulsar el botón le asignaremos al flag 6 el valor 1, y si se pulsa

muy fuerte, el valor 2 (supongamos que es un botón oxidado).

Conociendo que al resetear todos los flags están a cero, al llegar a

la localidad 38 nuestra aventura comprobará el flag 6. Si vale 0, no

pasa nada, si vale 1, el ordenador hará ruidos y si vale 2, se

encenderá. Los FLAGS del DAP son similares a las variables de

lenguajes de programación más completos, aunque bastante menosv

ersátiles. Recuerda que sólo pueden almacenar números. El DAP tiene

un tipo de variables de texto, los mensajes. Serán descritos con

posterioridad.

El flag 100 indica si el jugador murió y el 99 si acabó con

éxito la aventura. Si modificas durante el juego el valor de alguno

de estos flags para hacerlo diferente de 0, ocurrirá el efecto

descrito.

Merece la pena concretar que al comienzo de la aventura todos

los flags han sido inicializados con un valor de 0, excepto algunos

especiales que contienen valores que informan a las rutinas (ver el

fichero de referencia, IDxx.DOC)

PLANIFICACION ----------------------------------------------

Veamos un ejemplo de planificación de una aventura sencilla,

"El bosque maldito". Puedes encontrar la aventura en el disco ya

creada. De momento trabajaremos con aventuras de texto puras; si

quieres usar gráficos, lee la sección dedicada a ellos.

Se trata de una aventura extremadamente simple que nos servirá

para comprender cómo funciona DAP. Puedes encontrar en el disco otro

ejemplo llamado POWER1 que es la primera parte de la trilogía

comercial "The Search of the Power", íntegramente diseñada bajo el

DAP. En él se ilustran multitud de problemas cotidianos, como

controlar si un contenedor está lleno o vacío (una cantimplora con

agua o sin agua), apertura de puertas con llaves, o laberintos... si

le echas un vistazo podrás sacar muchos puntos interesantes de él.

Lo primero que se plantea es el argumento de nuestro pequeño

juego. Para empezar, probemos éste:

"Has apostado 1000 calas a que entras y sales vivo del famoso

bosque maldito".

Realmente es un argumento patético, pero como primer intento

puede servir muy bien. Y ahora, un desarrollo:

Antes de nada es necesario abrir la puerta del bosque.

Entraremos en el fondo del bosque y hay cuatro salidas:

- Una nos lleva a un barranco donde nos caeremos y ¡plaf!

- Otra al viejo almacen abandonado, cuya puerta abriremos sólo

si tenemos las llaves que se encuentran mirando en el suelo de la

primera localidad.

- Otra al principio.

- Y finalmente, a un río. Cruzándolo está la salida, pero no

podemos hacerlo sin una barca. La barca la encontraremos empujando la

estantería que hay en el almacen.

Es preciso destacar lo deprimente de esta aventura, por varios

motivos, pero es buena para aprender a usar el programa.

Tendremos tres objetos: las llaves (que no son visibles en

principio), la barca (tampoco) y una flor al lado del río, para

despistar. El jugador podrá llevar uno a la vez.

Ademas pondremos un personaje PSI en la localidad 1 llamado

Jacobo (en honor a un profesor mío) que nos puede ayudar.

Seguidamente hacemos el mapa de las 6 localidades del juego,

teniendo en cuenta que el jugador siempre empieza en la primera:

ALMACEN:

Empujando la

estantería,

aparece la

barca 3

Abre puerta con -->+

llaves

ENCRUCIJADA Ã---Â RIO 5

COMIENZO Ã----Â 2 Cruzar Ã--> SALIDA (6)

Mirando el Ð con barca

suelo apa-

recen las ¤

llaves 1 BARRANCO 4 N

Muerte O + E

Objetos:

1 - Llaves (empieza en 99 para ser invisible)

2 - Barca (empieza en 99)

3 - Flor (empieza en 5)

Personajes:

1 - Jaboco (empieza en 1)

(Jacobo es un famoso profesor de física de materiales de

la Facultad de Ciencias Físicas de la Universidad Complutense

de Madrid que me imparte clase en 1º de Ingeniería Superior

Informática, para satisfacer tu curiosidad. Tiene la pecu-

lairidad de que da las clases escribiendo al revés de la pi-

zarra cuando le apetece).

Ahora es necesario crear las descripciones de todos los

escenarios:

1 - Estás en la entrada del bosque maldito. Tu pellejo y tu

apuesta están en juego.

2 - Estás dentro del bosque, en una encrucijada. Aquí está la

entrada al almacen.

3 - Estás en el almacen. Se ve una estantería.

4 - Caes por el enorme precipicio y mueres.

5 - Este río corta el paso a la salida. Imposible cruzarlo sin

barca.

6 - Ésta es la salida.

Lo que hay que hacer si usamos gráficos es poner descripciones

claras y no muy pesadas, como éstas (o tal vez un poco más largas), y

si no los usamos, unas descripciones bellas y grandes serán las más

adecuadas. En este caso, debido a que este programa carecerá de

cualquier gráfico, estas descripciones no se prestan a la tarea, pero

bueno...

LOCALIDADES Y PRIMEROS PASOS -------------------------------

Arranque el creador de aventuras (ID50), y aparecerá el menú

principal.

Navega por los menús y experimenta las opciones. Observa que

hay varios submenús: localidades, objetos, PSI's, mensajes,

procedimientos y ficheros.

También tienes opción de probar la aventura, para seguir el

desarrollo de la misma.

Vete al menú de localidades y elige "Definir localidades".

Esta orden hará que el ordenador te pregunte el número de localidades

de tu aventura. Introduce 6. El número mínimo es 1 y el máximo, 90.

Empezaremos a introducir las descripciones. Al comenzar, el

Here es 1 (también usamos Here para referirnos a la localidad que

estamos tratando). Para introducir la descripción de la localidad

here, en nuestro caso la primera, elige la orden "Descripción".

Puedes variar el HERE con '+' y '-'. Observa que en la parte

baja de la pantalla aparecen las descripciones del HERE para

ahorrarte esfuerzo. Puedes cambiar directamente a un HERE concreto

sin moverte por los demás con la opción "Cambiar Here".

Ahora hemos de informar al compilador de las salidas de cada

localidad. El sistema es complicado, aunque cuando lo domines lo

verás útil, lógico y rápido. Las salidas son definidas por un código

numérico, y cada localidad dispone de un par de códigos: el normal y

el alternativo. Primero explicaremos el diseño del código y después

la diferencia entre el normal y el alternativo.

Al pulsar la opción de "salidas", un dibujo esquemático

representa una habitación. Empezamos introduciendo la salida al

norte. Aquí debemos poner un número que indique la localidad a la que

conduce esta dirección. Si pusiésemos 0 (o simplemente lo dejamos en

blanco), significaría que ahí no hay salida.

Después de introducir las salidas, se nos preguntará por un

juego de salidas alternativo.

El código alternativo es opcional (el código principal es

obligatorio para todas las localidades) y sólo se usa en estancias

cuyas salidas pueden variar, es decir, por ejemplo, abrir una puerta

que lleve al Este.

Supongamos una habitación que conduce, por el sur, a la

localidad 20. Simplemente informamos a DAP de eso. Ahora, hay una

puerta que si la abrimos encontramos una vía al norte, a la estancia

15. El código de salidas debería reflejar esta salida. Es ese código,

con la puerta abierta, el que introducimos como alternativo.

La rutina programada para "abrir puerta" se encargará de hacer

funcionar el código alternativo o el normal, según abramos o no la

puerta.

En el caso de "El Bosque Maldito", la estancia 2 debe tener un

código alternativo que refleja la vía hacia la localidad 3 al norte.

Cuando abramos la puerta, se intercambiarán los códigos. Además, una

salida hacia el norte de 99 significa que el jugador morirá. Una

salida al sur hacia 99 significa que el jugador ganará.

Así pues, la localidad 4 tendrá una salida al norte de 99.

LOS OBJETOS ------------------------------------------------

Los objetos son la pieza más importante de una aventura de

texto. Recordemos los objetos previstos para "El Bosque Maldito":

1 - LLAVES: Sin ellas no podemos abrir la puerta. Como

inicialmente no se ven, y todos los objetos deben empezar en alguna

localidad, tenemos un problema. La solución: situarlos en una

imaginaria localidad 999 a la que el jugador nunca llegará, porque no

existe, y moverlo a la localidad 1 cuando se examine el suelo.

Existen dos localidades especiales para los objetos en DAP:

999 - objeto no visible en ningún sitio, por si ha sido

destruido o todavía no ha aparecido (el caso de las llaves). Consi-

déralo el "limbo" de los objetos.

998 - en poder del jugador , cuando el jugador coge un objeto,

se mueve a la localidad 998. Así , si la localidad de inicio de un

objeto es 998, el jugador lo tendrá en su poder al comenzar. Si mo-

vemos con un procedimiento de orgones (más adelante sabrás lo que es)

a la localidad 998, el jugador adquirirá el objeto.

2 - BARCA: Tres cuartos de lo mismo, pero la moveremos a la 2.

Sirve para cruzar el río.

3 - FLOR: Está en la localidad 3 y nos sirve para despistar al

jugador.

Básicamente, el jugador puede COGER, DEJAR objetos y hacer un

INVENTARIO de los que lleva. Acciones posteriores, como CRUZAR RIO

(con la barca) se definirán exclusivamente para un objeto

determinado.

El jugador debe tener un máximo de objetos que llevar. Si

iguala este máximo, no podrá coger más objetos a no ser que deje uno.

Éste es el objetivo de poner objetos inútiles: no sólo le

desorientarán, sino que contribuirán a llenar su límite de carga.

El menú de objetos controla todo lo referente a éstos.

Para definir los objetos,use la opción correspondiente. Se le

preguntará primero por el número de objetos de la aventura y después

por cuántos objetos podrá llevar el jugador simultaneamente. En

nuestro caso, son 3 objetos, y pongamos un límite de 1, tres objetos

son muy pocos y un límite mayor quitaría emoción, y con la poca que

tenemos, no es plan ...

Para controlar el número de objeto que editamos tenemos algo

similar al Here, el objeto actual (OAC para abreviar). Puedes variar

el OAC con '+' y '-', o con la opción a tal efecto, de forma similar

a las localidades.

Para introducir los datos de un objeto usa la opción "Datos

objeto". Se te preguntará por la descripción y localidad inicial de

un objeto. Por ejemplo, en el caso de la flor:

Descripción: una flor <enter>

Localidad Inicial: 3 <enter>

Hay dos localidades de inicio especiales, como ya he dicho:

999 -> no visible en ninguna estancia (aparecerá, por ejemplo,

al examinar el suelo).

998 -> está en posesión del jugador (en nuestro caso, hará que

el jugador tenga el objeto al comienzo. Una vez jugando, mover un

objeto a 998 hará que el jugador lo adquiera).

También se te preguntará por el precio del objeto. Si ponemos

un precio diferente de 0, el jugador necesitará tener suficiente

dinero (el dinero del jugador está en el flag 107) para poder

comprarlo. Una vez comprado, si el jugador deja el objeto y lo vuelve

a coger, no es necesario volver a pagar por él. El dinero con el que

el jugador empieza puede especificarse en la opción "Parámetros

generales" del menú principal, y puede modificarse durante el juego.

Como en las localidades, hay información del OAC en la

pantalla, y está disponible una opción para obtener información más

detallada.

LOS PERSONAJES ---------------------------------------------

Los controlamos desde el menú "PSIs"

on la opción "DEFINIR PSIs" definimos el número de personajes

(1 en nuestro caso).

Con "DATOS PSI" podemos definir la descripción de cada

personaje y la localidad donde está , aunque aquí no hay un here como

en los objetos y localidades, sino que se nos preguntará el PSI a

modificar cuando elijamos esta opción.

El jugador hablará con los PSIs a través de la orden DECIR o

HABLAR (predefinida).

Con la opción "Respuestas PSI" puedes editar la tabla de

respuestas de un PSI. Cada PSI puede tener 20 respuestas diferentes.

Esta tabla configura la "inteligencia" de nuestro PSI.

Cada respuesta se provoca si se encuentra una de las 20

palabras asociadas a las respuestas. Por ejemplo, si hacemos:

1- hola

El PSI reaccionará de la forma 1 a órdenes tales como:

decir hola

decir hola, ¿cómo te llamas?

decir buenos días y hola

Si la pregunta no tiene respuesta en la tabla se ejecuta en

todo caso la respuesta 20.

Cada respuesta lleva asociado un procedimiento EDAP de orgones,

que indica lo que hará el jugador ante la palabra: desde una simple

contestación a abrirte la cabeza con un hacha, pasando por darte un

objeto. Más adelante hablaremos de los procedimientos EDAP.

Por ejemplo, nuestra tabla puede ser:

1- hola: "PRINT 10" (mensaje 10-hola)

20- cosa: "PRINT 11" (mensaje 20-qué dices)

(el resto de respuestas no han sido definidas)

Ejemplos de respuestas:

Insistamos en que no es necesario programar la orden

"decir/hablar", ya que ha sido predefinida (al igual que los

movimientos, save y load).

GRABACION DE AVENTURAS -------------------------------------

Ya hemos definido nuestra aventura, y sólo falta la parte más

importante: el lenguaje. Antes de meternos con lo más complicado del

diseño, veremos cómo grabar y cargar aventuras. El menú "DISCO"

controla lo referente a estos aspectos.

"Grabar aventura" graba la aventura para su posterior edición

o continuación. Las aventuras grabadas así no pueden ser ejecutadas.

La opción "Cargar aventura" lee aventuras grabadas en formato datos.

Las aventuras en formato datos se graban en el directorio

\DATA y no tienen extensión (para mantener la compatibilidad con las

versiones anteriores a la 3.00 del DAP, en las que sólo existía este

formato).

La opción "Compilar" compila la aventura y genera un fichero

con extensión ".DAP" en el directorio \EXEC. Estos ficheros no pueden

volver a abrirse. Pueden ser ejecutados por el módulo "Run-Time", y

son los que se usan para producir un ejecutable ".COM" del juego.

Para ejecutar las aventuras se usa el programa RT50. Su

sintaxis es:

RT50 -x nombre (sin extensión)

Donde -x puede ser:

-g -> ejecuta la aventura en modo comercial (no debe ser

usado)

-d -> ejecuta la aventura en modo debug. Ver más adelante.

Para ejecutar un módulo ".DAP", simplemente teclea "RT50

nombre". El RT50 buscará el módulo en el directorio \EXEC y lo

ejecutará. Los gráficos serán buscados en el directorio "DRI"

Dentro de RT50, además de los comandos de la aventura, pueden

darse algunas órdenes especiales:

AYUDA -> ayuda del RT50

STATUS -> estado del juego y del programa

END -> sale al DOS inmediatamente.

SAVE -> guarda el juego

LOAD -> recupera un juego guardado

Para generar un ejecutable de la aventura, use el programa

"CREATE". Se te pedirán el nombre del módulo y del fichero de música.

Si vas a ponerla, debe hallarse en el directorio \MUSIC; cuando acabe

todo el proceso tendrás a tu disposición tu aventura en el directorio

\GAME. Todos los ficheros que haya son necesarios. Ahora copia este

directorio a un disco y tendrás tu aventura distribuible.

Existirán dos ejecutables: uno, la aventura ("nombre.com"), y

otro, el programa SETUP.EXE, que permite configurar el sonido al

usuario final.

Lo único que no procesa (por ahora) CREATE son los archivos

gráficos; los archivos gráficos debes moverlos al directorio GAME.

También si ejecutas programas externos desde tu aventura debes

procurar añadirlos al directorio \GAME.

La música que admite el DAP puede estar en los siguientes

formatos digitales: MOD,S3M,STM y NST. El "player" que toca la música

no ha sido creado por Definitive Software, sino por Iguana.

El fichero de compilación externa COMxx.EXE presente en

anteriores ediciones del DAP ha sido eliminado.

Debes recordar a tus usuarios que deben cargar un motor grá-

fico antes de ejecutar el juego. El motor gráfico que incluye DAP,

DEFGK, es de dominio público y puedes incluirlo líbremente.

PARSER -----------------------------------------------------

El parser esla parte deljuego encargada de tomarun INPUT del

jugador y convertirlo encambios del estado del juego, es decir, de

analizar una orden, comprobarla con una tabla de órdenes en memoria,

y si está, ejecutar la rutina asociada a la órden. Si no, devolverá

al jugador el mensaje "No entiendo".

El de el DAP se compone de la forma VERBO+ARTICULO+NOMBRE,

donde artículo y nombre son opcionales. Al crear una orden para la

tabla no es necesario dar el artículo. Si la orden en la tabla es

MIRAR MESA, concordarán tanto un MIRAR MESA del jugador como un MIRAR

LA MESA o MIRAR UNA MESA. O sea, que antes de ser comprobada la orden

se eliminan artículos.

Mientras que el nombre debe ser exactamente igual en el input

que en el de la tabla, el verbo de la tabla sólo debe de estar

contenido en el del input, y esto posibilita un lenguaje mucho más

natural. Me explicaré: si la orden en memoria es MIR MESA, como se

comprueba si el verbo está contenido en el input, valdrían como

Inputs tanto MIRAR LA MESA como MIRA LA MESA o MIRE MESA o MIREMOS

UNA MESA, etc. Algunas órdenes como INVENTARIO no necesitan nombre,

mientras que al definir COGER y DEJAR, el ordenador se encargará del

nombre él solito.

Pero, ¿por qué la complicación de crear nuestro lenguaje,

cuando podía estar definido de serie? Bien. Otros parsers, como el

excelente GACS, de dominio público, optan por esta opción, pero el

precio de no tener un lenguaje custom y prediseñado se paga con una

drástica reducción de la complejidad de los juegos. Tener un lenguaje

custom no sólo significa crear el lenguaje apropiado para cada

aventura, y poder hacer aventuras en todos los idiomas sin necesidad

de nuevas versiones del software, sino programar lo que hará cada

orden mediante un pequeño pero útil lenguaje de programación, con el

que podremos variar todo lo que queramos la aventura, así como

comprobar si el jugador posee objetos, está en una localidad

determinada, etc. Por ejemplo, la orden CRUZ RIO (de cruzar rio)

deberá comprobar si tenemos la barca, si estamos en la localidad 5, y

una vez hecho esto mover al jugador a la localidad 6, imprimiendo un

mensaje que informe de nuestra exitosa navegación. Cada una de estas

acciones es una orden de la rutina asociada a la orden CRUZ RIO.

Por supuesto, tampoco queremos complicar mucho la vida y he

definido las seis famosas órdenes que nunca varían y siempre están

para que te ahorres programarlas: norte (N), sur(S), este (E), oeste

(O), grabar y cargar (para grabar situaciones de juego) y decir (para

hablar con los PSI).

DEFINICION DE PROCEDIMIENTOS -------------------------------

Existe un modo especial del ID para crear el vocabulario que

entenderá el programa. Lo primero que debemos hacer es definir la

palabra y luego crear la rutina que se ejecutará cuando el jugador dé

esa orden. Además, si la orden consta de una sola acción simple y sin

comprobaciones, como dar un inventario, lista de salidas o dejar un

objeto, no hará falta una rutina. Veremos esto más adelante.

Puedes pasar al menú de procedimientos con la opción

"Procedimientos". Hay dos tipos de procedimientos, las acciones del

jugador, que son de los que hemos estado tratando, y los

globales/locales. Elige "Acciones del jugador". Para definir una

nueva acción, usa la opción "Definir palabra". Puedes definir hasta

100 acciones.

Introduce ahora el comando. Por ejemplo, para ABRIR PUERTA,

ABR PUERTA, o para COGER, COG, tal y como explicamos antes.

Existe un nombre especial, y es "*". Si usas, por ejemplo, EX

*, la orden se ejecutará con EX PUERTA, EX RIO, o EX LO_QUE_SEA.

Actúa, pues, como comodín. Esto es útil para repuestas por defecto.

Por ejemplo, supongamos que sólo hemos hecho una descripción para el

chupete (msg.1), y en el msg.2 tenemos una descripción comodín, "No

ves nada especial":

EX CHUPETE -> PRINT 1

RET

EX * -> PRINT 2

RET

(el pseudolenguaje de orgones se explica ahora)

El DAP comprueba en orden secuencial las acciones y cuando

encuentra una correspondencia no sigue buscando, así que las órdenes

de nombre "*" por defecto deben estar después que las de su mismo

verbo.

Ahora introduce la rutina que ejecutará esta acción, con un

máximo de 15 órdenes. La sintaxis del DAP es sencilla, introduce la

orden uno, y cuando acabes, otra orden.

Ejemplo: (tal vez necesites consultar la Guía de referencia en

el fichero IDxx.DOC). Cada instrucción del lenguaje de programación,

llamado EDAP, se denomina orgón.

Orden: usa teletransportador (valdría "usar teletransporta-

dor", "usa el teletransportador", etc.). Un transportador en la

localidad 3 que funciona con una llave (7).

?LOC 3 5

?OBJ 7 2

?CAMSIT 10 18

?RET

(Pulsando <enter> al final de cada línea)

Ahora, si listamos la orden desde el menú:

LOC 3 M5

OBJ 7 M2

CAMSIT 10 M18

RET

Observa las M que han aparecido antes de algunos parámetros.

Estas M son "imaginarias" y sirven para indicarnos que estos

parámetros se refieren a un número de mensaje. Un @ en lugar de la M

indica que nos referimos a un número de flag. Estos valores no DEBEN

introducirse al crear un programa, sólo están para AYUDAR a

depurarlos.

Consulta todos los orgones disponibles en el fichero IDxx.DOC.

Allí se hace una descripción exhaustiva de cada una junto con

ejemplos ilustrativos. De momento, te daré una pequeña descripción de

este pequeño programa:

LOC 3 5 (se introduce por separado)

Comprueba si el jugador está en la localidad 5, y si no está,

imprime el mensaje 5 y acaba el programa.

OBJ 7 2

Hace algo similar, pero comprueba si el jugador tiene el

objeto 7.

CAMSIT 10 18

Cambia el HERE a 10 y escribe el mensaje 18.

RET

Acaba

Imaginemos los mensajes:

18 -> Te teletransportas a otra habitación.

2 -> No tienes la llave

5 -> No hay teletransportadores aquí.

Una vez creada la rutina para una orden, puede verse o

modificarse desde el menú.

Cuando listes, los parámetros que se refieran a un mensaje

irán precidos por M y los que se refieran a una variable por @, para

facilitar su distinción.

Por ejemplo, para definir la palabra "COG" (coger, coge...):

>cog <enter>

1:coger <enter>

2:ret

Otro orgón interesante es PRINT, su parámetro es un número de

mensaje, que será imprimido en pantalla. Cuando se produce un cambio

en el estado del juego, es necesario dar al jugador un mensaje

informándote de dicho cambio. Los mensajes en el DAP son "custom", es

decir, tú los defines. Tienes un máximo de 300 mensajes para definir.

Muchos orgones del microlenguaje necesitan un número de mensaje para

funcionar. Esta orden imprimirá el mensaje asociado al número que des

al compilador. Es muy útil para comandos del tipo"examinar". Por

ejemplo, si el mensaje 29 contiene "es grueso y alto":

Además los mensajes se pueden usar como parámetro de texto

para algunos comandos internos, como SHELL o PLAY.

Los mensajes se pueden modificar y definir en el menú

destinado a ello. Al principio del juego, todos los mensajes

contienen la cadena nula ("").

Nota importante: El mensaje 39 aparece si el jugador muere y

el 40 si acaba su aventura con éxito.

Una serie importante de mensajes son los del 286 al 300. Estos

mensajes son las respuestas básicas del parser a opciones tales como

coger un objeto. Debes crear estos mensajes según tus gustos. La

opción "cargar librería" puede ahorrarte mucho trabajo: su función es

cargar una librería predefinida de mensajes estándar en memoria.

Estos ficheros están en un formato especial. Se incluye una

cabecera y los mensajes, todo en formato ASCII. Puedes crear tus

propios .MSG con tus mensajes habituales, o en tu lengua materna, por

ejemplo, en vasco, sólo sigue el modelo de algunos de los .MSG

incluidos de muestra, y, eso sí, no modifiques la cabecera.

También es muy usado el orgón CAMSIT. Sus parámetros son un

nuevo Here y un número de mensaje a imprimir.

Por ejemplo, supongamos (recordando a "Adventure") que

diciendo la palabra mágica XYZZY seremos teletransportados a un

recolector de tesoros (localidad 10)

Para coger objetos, se usa el orgón COGER. El DAP hará que el

jugador recoja el objeto que haya especificado en el nombre del

mandato. El propio DAP hará las comprobaciones pertinentes e

informará al jugador de si ya tiene el objeto, si no está, etc.

P.ej., creemos la orden TOMAR:

"toma *"

COGER <enter>

RET <enter>

Así, si el jugador da la orden TOMA LA LINTERNA, y el objeto

Linterna está en esa localidad, y eljugador todavía puede coger

objetos, el objeto será cogido. El orgón "dejar" puede resumirse en

lo mismo pero al contrario.

La orden "salidas" informa al jugadorde lassalidas de una

localidad. Las órdenes del jugador que suelen asocairse a este

mandato son SALIDAS y X. Un ejemplo de juego en "El Bosque Maldito",

teniendo esta orden ya definida:

Estás en la entrada del bosque maldito. El suelo es muy

curioso.

>salidas

Las salidas posibles son: ESTE.

"Inventario" informa al jugador de los objetos que posee.

"Redescribir" resdescribe la localidad (util para acciones del

tipo "mira *")

Hay facilidades para editar, ver y trabajar con comandos ya

creados, para más información consulta el IDxx.DOC.

Un tipo especial de programa son los GLOLOS. Estos programas

no se ejecutan ante un mandanto del jugador, sino que se ejecutan

siempre que el jugador esté en una localidad, continuamente. También

pueden asociarse a la localidad 0, con lo que se ejecutan siempre,

durante el juego. El menú "Globales/localeS" permite definirlos.

Así también como ya se ha dicho, cada respuesta de un PSI lleva

también asociado un procedimiento EDAP.

Existen muchos más orgones (unos 60), algunas para tareas extre-

madamente retorcidas; sin embargo, con los orgones que aquí he descrito

será suficiente en el 90% de los casos. La guía completa de referencia

de orgones está en IDxx.DOC.

FICHEROS DE TITULO -----------------------------------------

Cada aventura deberá tener un fichero con su mismo nombre pero

con extensión .TLT. Me explico, si el fichero de la aventura es

BOSQUE (los archivos de aventura no tienen extensión), deberás crear

un fichero BOSQUE.TLT.

Este fichero contendrá una pantalla de presentación para el

juego en ASCII, que puede contener el nombre del autor o las

instrucciones de uso. Se mostrará al jugador mientras se lee la

aventura.

Estos ficheros deben almacenarse en \DATA.

Creando laberintos -----------------------------------------

Lo que parecen milesde localidades son enrealidad cinco o seis

con un pequeño truco en sus salidas. Veamos un ejemplo: si la

localidad 11 fuera un pequeño laberinto (ella sola, ¡sí!), sus

salidas serían:

Norte - 11

Sur - 11

Oeste -11

Este - 12

y todas las salidas menos el este llevarían a la misma,

confundiendo al jugador (ya que si la descripción es: "Estás en un

laberinto", no distinguirá si son diferentes localidades, a no ser

que use un pequeño truco que sólo los grandes expertos en juegos de

texto conocemos). Lo que se hace es crear 5 ó seis localidades con

las salidas así entrelazadas.

ENTRAR Y SALIR, SUBIR Y BAJAR ------------------------------

Supongamos que para salir de una nave hay que teclear SALIR.

Se usa una rutina en micro lenguaje que compruebe si se está en la

salida y luego se usa la orden CAMSIT. Subir, bajar y entrar se hacen

de manera parecida.

Por último, recuerda poner objetos inútiles para confundir al

jugador, y si haces un programa, te ruego que me la mandes por correo

para verla y disfrutarla.

*********************************************************************

PARTE III: TÉCNICAS AVANZADAS

*********************************************************************

USO DE GRAFICOS EN LAS AVENTURAS ---------------------------

Puedes incluir desde tus creaciones hasta digitalizaciones,

con una resolución máxima de 320x200x256. Sólo tienes que tener un

archivo DRI con el dibujo de la localidad (los gráficos se muestran

antes de la descripción). Ahora, convierte la localidad que quieras

dotar de gráfico en here y use la opción "gráfico" del menú

localidad.

El ID te pedirá el nombre del fichero DRI (sin extensión). Si

quieres cambiar el gráfico a una localidad usa esta orden de nuevo.

Si quieres quitar el gráfico teclea "$" como nombre.

Puedes añadir "-f " al principio del nombre del gráfico para

mostrarlo con un elegante fundido.

Y... ¿qué demonios es el formato DRI?

Como ya habrás notado, DAP ha pasado por varios formatos

gráficos durante su historia. Primero, con la versión 2.10, fueron

los ficheros PCX. Pero el control sobre éstos era muy rudimentario.

El Advanced DAP representó una gran mejora con el soporte del forma

to GIF, pero aun así no era suficiente. El DAP no tenía control

absoluto sobre el fichero y los jugadores de las aventuras podían

observar los gráficos con cualquier visor.

Por eso hemos creado nuestro propio formato, el DRI. El DRI es

un nuevo formato gráfico. Dispone de una cabezera estándar con

información para el DAP y soporta trabajos en el fascinante modo X

(320x240x256 colores) - que yo sepa, es el primer formato que puede

almacenar imágenes en modo X.

Te encontrarás el problema de no tener ninguna aplicación que

soporte DRI. Por eso hemos incluido un conversor de GIF estándar de

320x200x256 a DRI.

La pantalla de la aventura, una vez estés jugando, se divide

en dos partes; una ventana de texto donde transcurre la aventura, y

una ventana de gráficos donde se muestran las imágenes DRI que hayas

definido.

El tamaño de la ventana de texto puede elegirse, junto a los

valores rgb de los colores de DAP y el dinero inicial del jugador en

la opción "Valores Generales" del menú principal de ID. En ningún ca-

so el texto se mezclará con los gráficos. "Valores Generales" también

te permite variar los valores RGB de los colores del texto, fondo y

parser.

Cuando se entre en localidades sin gráfico asignado, DAP auto-

máticamente se reajustará para utilizar toda la pantalla para texto.

DAP utiliza una paleta de 256 colores. Cada uno de estos colo-

res tendrá unos valores rgb de 0 a 63. Los colores 0 a 2 están reser-

vados para el uso de DAP, y se utilizan así:

0 - color del fondo

1 - color del texto

2 - color de la entrada del jugador

(DAP hará uso de más colores automáticamente si lo considera oportuno)

Cada color se compone de un parámetro rgb referente al nivel de

rojo,verde y azul.

Si en la aventura quieres cambiar uno de estos colores pue-

des hacerlo con PUTPAL.

Por eso, tus gráficos no deben usar estos colores para no

interferir con DAP. Si aun así intentas convertir a DRI un GIF que

use los colores 0,1 ó 2, el conversor automáticamente los sustituirá

por los colores más parecidos posibles (esto generalmente funciona

bien, pero no siempre ... si no hay ningún color parecido). En caso

de que G2DRIX haga un destrozo a tu pobre gráfico, te queda un úl-

timo recurso (a parte de reducir colores con una utilidad externa):

convertirlo a escala de grises con "-g". En este caso, DAP siempre

encontrará un tono de gris similar al sustituido, de modo que el

cambio prácticamente pasará desapercibido. Generalmente, G2DRIX se

muestra más respetuoso con imágenes en tonos de gris que en color.

(nuestro algoritmo de búsqueda de colores cercanos aún no parece muy

perfeccionado, pero lo mejoraremos).

En cualquier caso, si estás realizando el gráfico, procu-

ra no utilizar ningún color de la paleta por debajo del 3 y no ten-

drás ningún problema.

Unas palabras sobre los ciclos;

Otra novedad en la versión 5 de DAP son los ciclos de colores, que

permiten crear efectos bastante espectaculares. Por ejemplo, imagina

que estás en un submarino en alerta rojo. Podemos crear un ciclo de

colores cuyo efecto sea ir iluminando el fondo hasta ponerlo rojo, y

luego ir apagándolo otra vez, así sucesivamente, simulando la alerta

roja.

Para crear los ciclos se usa el orgón NUEVOCICLO x y z

donde

x - número del color al que se aplicará el ciclo

y - valor rgb al que afectará el ciclo (únicamente a uno)

0 - rojo

1 - verde

2 - azul

(otros valores se ignoran)

z - valor máximo (0<z<=63) que puede alcanzar el color.

Para detener un ciclo, se usa FINCICLO x, donde x es el color.

Sólo puede haber un ciclo por color; esto da un máximo de 256 ciclos

simultáneos, uno para cada color de la paleta.

En nuestro ejemplo, la orden más adecuada sería NUEVOCICLO 0 0 63.

EL DEPURADOR -----------------------------------------------

Está pensado para poder depurar las aventuras y encontrar

los fallos, así como ejecutarlas durante su creación para ir viendo

las repercusiones de nuestros actos en su estructura.

El uso es:

RT50 -d nombre.

Al contrario que en versiones anteriores del parser, la

aventura debe estar compilada. La aventura se coge de \EXEC y los

gráficos de \DRI. El debugger nos proporciona información acerca de

todo lo que sucede dentro de nuestra aventura. Puedes salir del

debugger con "END".

Además, el depurador tiene algunas funciones especiales:

VFLAG x : muestra el valor de la bandera número x.

CFLAG x : pregunta un nuevo valor para la bandera número x.

GO x : va a la localidad x.

VERGLOLOC: muestra los glolos

VER x : muestra los valores rgb del color x

El depurador tambien puede invocarse desde el ID para probar

la aventura que se está editando. Ésta es la forma en la que

normalmente trabajarás.

El depurador también tiene algunas órdenes para trabajar

fácilmente con la pila del sistema. Se explican en el apartado "La

pila". También puede manejar los ciclos (utilizar la propia ayuda del

depurador para más información a este respecto).

CONTROL HORARIO --------------------------------------------

El DAP te permite mantener un completo control horario para

ofrecer un soporte más realista a tus aventuras.

La hora es actualizada automáticamente. Los siguientes datos

horarios se actualizan automáticamente en estos flags:

Flag Descripción

------- -----------------------------------------------

101 Hora del día (00-23)

102 Minuto de la hora (00-59)

103 Temporizador (ver más adelante)

104 Número de día (00-...)

Lógicamente, tu programa puede modificar estas variables, por

ejemplo así

ORDEN: DORMIR *

Mensaje 7: "Duermes profundamente"

ADDVAL 101,5

PRINT 7

RET

Así al DORMIR, el jugador avanzaría cinco horas.

Uso del temporizador

--------------------

El temporizador indica la velocidad del paso del tiempo. Por

defecto es 1 , que es lo más lento. Cuanto más grande sea, más

deprisa pasará el tiempo (un valor de 60 provocará que por cada

acción del jugador pasen 60 minutos, un valor de 15 que pasen 15

minutos, etc.)

RECURSOS Y GESTION DE MEMORIA ------------------------------

El ID indica, en el menú principal, el porcentaje de recursos

del sistema empleados.

Los recursos del sistema empleados se evaluan en base a los

que están empleados actualmente y al máximo permitido por el sistema.

El conjunto de recursos de una aventura comprende los procedimientos,

localidades, objetos y PSI's. El resto de información es ajeno a los

recursos. Los mensajes siempre están definidos y ocupando memoria, así

que da igual si los has introducido o no. Un mensaje en blanco ocupa

igual que uno lleno (256 bytes).

DAP permite que los recursos ocupen un máximo de 64kb en con-

junto.Esto teniendo en cuenta que los orgones se codifican a una pa-

palabra.

NUMEROS ALEATORIOS -----------------------------------------

El DAP dispone de un generador de números aleatorios

disponible al programador a través de los flags 106 y 105.

El flag 105 contiene un número aleatorio que varia cada paso

del programa. Este número es elegido del rango 0 al valor

especificado en el flag 106. La utilidad de este generador, p.ej,

para crear eventos aleatorios, es evidente.

Existen otros flags de propósito especial. En el fichero

ID50.DOC hay una tabla con la utilidad de todos los flags especiales.

LA PILA ----------------------------------------------------

La pila (stack, en inglés) es una nueva y poderosa estructura

de datos que ha sido incluida por primera vez en la versión 4 del

DAP. Esta pila funciona de manera muy similar a la de la CPU del

ordenador y a la de otros parsers como NMP.

Sus principales utilidades serán el almacenamiento de datos

durante procesos EDAP y, especialmente, la comunicación interproceso,

que se puede realizar de forma mucho más eficaz mediante la pila que

mediante flags.

CARACTERISTICAS DE LA PILA.- La pila no es más que un buffer

de tipo FILO (First In Last Out, el primero en entrar, último en

salir).

Si introducimos (empujamos, push) un valor en la pila, la

siguiente orden que pida un valor de ésta (sacar, pop) recuperará

siempre el *último* valor introducido. Una vez hecho el pop, el dato

se desecha.

Los orgones para el control de la pila son:

PUSH a : introduce el valor 'a' en la pila.

PUSHV a : introduce el valor del flag 'a'.

POPV a : saca un valor de la pila hasta el flag 'a'.

FLUSH : vacía la pila.

GETSTACKST a: introduce en el flag 'a' el número de elementos

disponibles en la pila.

STACKMODE a : selecciona el modo de funcionamiento de la pila.

0- modo limitado.

1- modo rotatorio.

La capacidad máxima de la pila es de 50 elementos en esta

versión, lo cual debería ser más que suficiente. El DAP chequea

automáticamente todas las operaciones realizadas en la pila, en caso

de producirse un desbordamiento, el RT50 informará al jugador con el

mensaje:

! Error fatal: Pila reventada.

También se producirá un error fatal si se intentan leer datos

con la pila vacía. En cualquier caso, la aventura seguirá

ejecutándose. Este es el modo de funcionamiento "limitado", el que se

elige por defecto. Con el orgón STACKMODE puede cambiarse al modo 1 ,

"rotatorio", en el que la pila se comporta de una forma distinta. Si

estando la pila saturada, se introduce un valor, éste se mete en el

elemento 1 de la pila. Así, si la pila está vacia (elemento 0) y se

hace un POPV, se tomará el último valor de la pila. De esta forma, la

pila va rotando.

Si se está funcionando en modo "limitado" y se intenta leer un

dato con la pila vacía, se devuelve -1.

Cuando se hace un "FLUSH", únicamente se posiciona el puntero

de la pila al principio de ésta, pero NO SE LIMPIAN LOS VALORES. Esto

no tiene absolutamente ninguna trascendencia en el modo limitado,

pero en el modo rotatorio puede llevarle a más de un aprieto si no lo

tiene en cuenta.

Ejemplos de uso:

programa contenido de la pila contenido del flag 1

-------- --------------------- --------------------

FLUSH 0 ?

PUSH 1111 ?

PUSH 2011, 20 ?

PUSH 1011,20,10 ?

POPV 1 11, 20 10

POPV 1 112 0

PUSHV 111, 20 20

FLUSH 0 20

RET

El debugger ha sido preparado para facilitarle al máximo la

depuración de programas que utilicen la pila (los cuales suelen estar

repletos de pequeños bugs).

Las ordenes especiales son una réplica de los orgones:

PUSH x : introduce 'x' en la pila.

POP : saca una valor de la pila (e imprime su valor)

FLUSH : vacía la pila

VERPILA : muestra la pila entera. Un código de colores

indica los valores 'asignados': en color azul,

valores asignados, en color rosa, valores no

'asignados'.

STACKMODE x: selecciona el modo de la pila.

PARA LA PROXIMA VERSION ------------------------------------

Para la próxima versión tengo previsto incluir el soporte de

alta resolución VESA intrínsecamente, mejorar el soporte de sonido

y soportar más de una ventana de texto en la pantalla. También es

posible que se incluya soporte para distintas fuentes. Quién sabe.

(puedes trabajar en tu propio soporte de fuentes con tu propio mo-

tor gráfico). Además, el texto de formateará automáticamente.

Quizás, algún día, DAP migré a Windows.

CRÉDITOS ---------------------------------------------------

Se reconoce la propiedad de sus respectivas marcas sobre todos

los productos registrados nombrados en este manual. Pero antes, yo

mismo debo perder muchos prejuicios.

--------------------------[ FIN DEL MANUAL ]-------------------------