| # LOS CREADORES DE AVENTURAS (II)

## Iniciamos en la anterior entrega el estudio comparativo de las dos utilidades más potentes usadas para crear una aventura, hoy continuamos profundizando en ellas y pasamos al estudio de su facilidad para probar y corregir la aventura ya terminada, así como en detalles más técnicos de su lógica interna.

Supongamos que todo ha ido bien y tenemos nuestra aventura terminada; lo más probable es que, sin que nos hayamos dado cuenta, se nos hayan colado algunos errores y deseemos ponerla a prueba mientras todavía se halla unida a su creador y así corregirlos en el mismo momento en que los encontremos.

Este proceso es fundamental en todo juego, que debe ser probado y requeteprobado tanto como sea posible; primero por el propio autor y luego por otras personas que no estén muy al corriente de cómo funciona y sean capaces de introducir variaciones que al escritor, conocedor del tema, no se le han ni ocurrido.

Para ello ambas utilidades, tanto GAC como PAW, tienen opciones muy potentes que permiten controlar y examinar cómo están sus banderas (luego explicaremos a fondo en qué consisten y cómo se usan)y otros contadores fundamentales para el juego.

PAW permite, a los usuarios ya experimentados, cambiar manualmente el valor de sus banderas mientras se está probando el juego. Esto es de gran importancia porque permite comprobar cómo se comportan y cómo se comportarían si sus valores fueran diferentes.

GAC tienen 265 de estos marcadores que pueden estar ON/OFF y otras 128 variables, que pueden tener valores desde 0 hasta 255; PAW sólo tiene 256 de estas últimas variables, aunque algunas controlan procesos específicos y no son alterables.

Naturalmente, todas las facilidades normales, como son las de SAVE, LOAD y VERIFY una base de datos, SAVE y VERIFY una aventura entera, el chequeo de la memoria que queda, etc., están presentes en ambas utilidades.

Además, PAW tiene un excelente compresor de textos que funciona reemplazando las más comunes combinaciones de letras por un solo byte en la memoria, y que es capaz de dar hasta un 40 por 100 más de espacio extra para el texto. Muy eficaz para los problemas de producción de juegos de 48k.

En las versiones inglesas que hemos manejado esta compresión no parece funcionar del todo bien con el castellano.

Calculamos que sólo dan una compresión del 20 por 100 y ello se debe a que están preparadas para buscar los grupos de letras que son más comunes en inglés; pero ese problema está obviado en la versión traducida donde se les ha dotado de una compresión específica para castellano que trabaja a tope.

Para lograr esta conversión necesitaban los programadores ingleses grandes cantidades de texto para alimentar sus analizadores y así buscar las combinaciones de letras más frecuentes en castellano; nos sentimos muy orgullosos de anunciar que el texto usado para este menester fue... ¡dos disquetes conteniendo todo lo que se ha ido publicando en esta serie desde el número 146 de MICROHOBBY, así como lo de la serie hermana del viejo archivero!

O sea, que los compresores deben funcionar cosa fina.

### CONDICIONES PARA ACTUAR

El corazón de una aventura está formado por una serie de tablas de instrucciones y de comandos que tienen en cuenta todos los inputs y acciones que el jugador pueda teclear. Aquí es donde el escritor se la juega y donde se convierte en una especie de programador en el lenguaje específico del parser.

Y es que no todo puede ser hecho por la utilidad y aunque sería maravilloso que sólo hubiera que teclear una serie de descripciones convincentes y una serie de respuestas adecuadas para cada input del jugador y obtener un juego que funcione, esto no es posible.

También es aquí donde se nota si un programa está bien concebido o es sólo una "cáscara vacia" sin ningún interés. Es la parte más difícil pero también la más agradecida si se sabe dominar y la que hace que el crear aventuras sea una tarea, en nuestra opinión, tan interesante como el jugarlas.

El mecanismo básico es sencillo: se trata de una serie de acciones que sólo se ejecutan si se cumplen ciertas condiciones.

Pero en la práctica las variaciones son casi infinitas y, a medida que el juego va progresando, se van complicando y entrelazándose unas con otras hasta que, si no se tiene el cuidado de tenerlo todo muy claro, llegan a ser un verdadero rompecabezas.

Las complicaciones aumentan si se está tratando de dar vida a personajes pseudointeligentes, es decir, que se mueven por el juego con una cierta independencia que simula una personalidad propia y que hacen un uso exhaustivo de condiciones-acciones.

Veámos qué es exáctamente una condición: puesto que en una aventura el jugador tiene la libertad de teclear lo que le dé la gana y sólo una insignificante minoría de todas las cosas tecleables tienen significado para el juego, debe usarse algún metodo para decirle al intérprete cuáles son y cómo manejarlas.

Cada orden que el jugador teclea y que sea capaz de causar una acción debe tener una condición de algún tipo, puesto que son las condiciones las que causan que se haga la acción. No siempre es necesario tener una condición específica para cada orden, puesto que con frecuencia un grupo de acciones similares pueden ser juntadas en una condición "comodín" que sirve para todas, tal es el caso de las órdenes COGER, DEJAR, EXAMINAR, etc.

Pero recuerda: sin condición, no hay acción.

El esquema de una condición sería:

IF (condiciones) (acciones) END.

Lo que significaría "SI (lo que esté entre comillas es todo cierto) entonces (y sólo entonces) ejecuta todas las acciones que se encuentren entre el final de las comillas y el comando END"

Es cierto que la parte condicional "SI (...)" puede omitirse del todo, siempre que se intente que la acción se ejecute en cada turno. Pero entonces sería una condición de alta prioridad para el GAC y de proceso tipo uno del PAW (no te preocupes si todo te parece un poco enredado, al ir progresando verás que no lo es).

Cuando sí se usa la parte condicional, lo que se hace es probar para ver si lo que el jugador tecleó, o cualquier otra información, es verdadero. Entonces, si todo lo que está entre comillas es verdadero, todas las acciones se ejecutarán. Si algo de lo de entre comillas no es verdadero, ninguna de las acciones situadas después de las comillas se ejecuta, luego la condición será ignorada.

Así continúa la búsqueda a través de todas las condiciones hasta que se encuentre una que sea verdadera y produzca una acción; o no se encuentre ninguna, en cuyo caso no habrá acción y se informa al jugador de ello y se le requiere para hacer otro intento.

Es importante que asimiles etos conceptos básicos antes de ver cómo maneja estos asuntos cada parser.

### DENTRO DEL GAC

El GAC ofrece para estos manejos cuatro tipos diferentes de condiciones:

1. Conexiones.
2. Locales.
3. De baja prioridad.
4. De alta prioridad.

Y el orden en que actúa el sistema es el siguiente:

1. La posición actual del jugador se imprime en pantalla.
2. Se ejecuta una acción según condición de alta prioridad.
3. Se pide al aventurero que teclee la siguiente orden.
4. Si teclea una dirección válida (conexiones), se cambia la localidad.
5. Si no, se ejcuta una acción según las condiciones locales.
6. Se ejecuta una acción según las condiciones de baja prioridad.

Cada condición es examinada en cada turno y ejecutada, si es apropiada, hasta que aparezca un comando que ordene el cese de la búsqueda en las condiciones locales o de baja prioridad (por ejemplo WAIT u OKAY al final de una condición verdadera, lo que causará un salto al comienzo de la tabla de alta prioridad), o hasta que todas las condiciones hayan sido chequeadas y se pregunte al jugador por su próxima orden o input.

El orden en que se chequean las condiciones está predeterminado y es muy importante.

1. Conexiones: sólo ajustables en el sentido de con qué movimiento se cambia de localidad. Cualquier orden del jugador que coincida con una conexión válida para la habitación donde se encuentra producirá una acción: lo movera a la hbitación indicada. Inmediatamente después serán chequeadas las condiciones de alta prioridad y se actuará si coinciden. Luego el mensaje pidiendo otra orden se imprimirá: ¿algo más?... ¡Pero sin haber chequeado ni las condiciones locales ni las de baja prioridad!

Por tanto, si quieres que haya una condición (una llave) para poder moverse a otra localidad, no debes entrar esa posibilidad en la tabla de conexiones, sino en la tabla de condiciones locales.

2.Condiciones Locales: son las específicas para cada localidad; es decir, no actuarán si estás en otra parte. Supongamos que tenemos dos monedas. En una localidad hay una máquina expendedora de pipas y en otra una de cigarrillos. Las condiciones locales serían las encargadas de que en una localidad al meter la monedaésta desapareciese y se creara una bolsa de pipas y en la otra localidad se creara un paquete de cigarrillos. Si no están bien diferenciadas, el jugador podría obtener cigarrillos de una máquina de pipas y viceversa.

Cuando se encuentra una condición local verdadera se produce la acción correspondiente y si durante ella se encuentra un WAIT o un OKAY, se hace un salto a las de alta prioridad y luego al próximo input del jugador. Si no se encuentra ninguna verdadera o se encuentra una que no lleva el WAIT ni el OKAY dentro de su acción, continúa la búsqueda u sólo cuando todas las condiciones locales hayan sido chequeadas, se pasará a las de baja prioridad.

3.Condiciones de baja prioridad: se usan para acciones que pueden ejecutarse en cualquier sitio y que producen el mismo efecto, sin importar en dónde estés; por ejemplo, encender una lámpara o coger y dejar un objeto. Comprenderás que sería extremadamente tedioso tener que poner esas condiciones en cada una de las habitaciones.

Suponiendo que no se ha causado un salto a alta prioridad, las condiciones bajas son chequeadas todas en busca de la acción a ajecutar.

4.Condiciones de alta prioridad: son chequeadas justo antes de pedir al jugador su próximo INPUT. Por ello son ideales para controlar ciclos de tiempo, eventos fuera de control para el jugador, muertes por falta de aire o por caídas, etc. La idea es que se encargan de todo aquello que no depende de las órdenes dadas por el jugador.

Se chequean y se ejecuta su acción, si son verdaderas, en cada turno, no importa que se haya ejecutado otro tipo de condición antes. También cualquier WAIT u OKAY que haya en las locales o en las bajas saltará al principio de la tabla de las altas, después de incrementar en uno el contador de turnos tomados.

Después de haber sido chequeadas todas, el mensaje ¿algo más?, que pide al jugador un nuevo INPUT se imprime (si el jugador todavía está vivo).

Resumiendo:

Conexiones: sólo usadas para movimientos incondicionales entre localidades.

Locales: usadas sólo en acciones que tengan lugar en una localidad específica.

Bajas: usadas en acciones que pueden tener lugar en cualquier parte.

Altas: usadas para chequear la fuerza, vida, ciclos, etc.

Teniendo lo anterior claro y el uso de marcadores y banderas, que explicaremos más adelante, el resto consiste en aprenderse el "lenguaje"; es decir, las 26 condiciones y las 34 acciones de que dispone el GAC y ¡a por ellos!

En la parte positiva, GAC es muy flexible; permite el reemplazo de cualquier número con una bandera y tiene la valiosa orden CONN, similar al MOVE del PAW.

Supongamos ahora que tienes una idea de los comandos del GAC, te dejaremos con un interesante problema para ver si tienes asimilado lo fundamental:

Supongamos que has tenido la brillante idea de suscribirte a la revista MICROHOBBY, pero pagando con un talón. Para ello debes tener un talonario a mano y dinero en el banco.

¿Cómo enfocarías tan importante situación en el GAC de forma que cubriese todas las posibilidades?

Pondrias en el vocabulario el verbo suscribir y el nombre MICROHOBBY y ahora tendrías que poner las condiciones para actuar en el caso de que teclees: suscribirme a MICROHOBBY.

¿Cómo lo harías?

La explicación detallada en el próximo número.

Andrés R. Samudio.