Digipure's weblog: Sistemas para crear aventuras conversacionales (III) : INFOCOM

Zork I para TRS-80, una de las versiones mas antiguas

Introducción

De entre todas las compañías que se dedicaron a crear aventuras conversacionales en los 80, INFOCOM es seguramente una de las mas antigua y de las mas recordadas en los paises donde llegaron sus juegos. Cuando las aventuras para ordenador no dejaban de ser clones de aventuras de Scott Adams o de una simplicidad similar, INFOCOM introdujo aventuras que eran verdadera ficción interactiva. Textos largos y descriptivos, parser de texto avanzado y complejo y unas herramientas para hacer aventuras cuya influencia aun esta viva hoy en día.

Pero hagamos primero un poco de historia. Y la historia de INFOCOM esta ligada a Zork, una aventura inspirada en la original creada por varios estudiantes de MIT. Esta versión primigenia de Zork esta programando en MDL, un lenguaje basado en LISP,usado para la investigación de varios temas relacionados con inteligencia artificial dentro del MIT. Zork fue portado por un hacker a Fortran y acabo distribuyéndose por todos los main frames de la época. La historia podría haber acabado aquí, como tantas otras aventuras para grandes ordenadores de la época pero sucedió que el grupo de estudiantes que había creado Zork originalmente se decidió por crear una empresa aprovechando el boom de los micro-ordenadores de finales de los 70. Su intención era crear aplicaciones, no juegos, pero al no tener ninguna aplicación pensada, se decidieron por portar Zork a los micros de la época. Y aquí comienza la prolífica historia aventurera de INFOCOM .

Como se hicieron los juegos de INFOCOM

Hecho el prefacio histórico, vamos a centrarnos en como INFOCOM hacia sus juegos. La primera versión, no comercial, de Zork estaba escrita en MDL y el código esta disponible. Pero al ser un lenguaje con muy poca difusión y apenas documentación se hace difícil analizar el código (que es bastante complejo para la época). Mejor que eso nos vamos a centrar en los ports para micro-ordenadores, que guardan relación con el MDL, pero están mucho mejor documentados y por razones que explicare mas adelante es también mucho mas claro.

El primer problema que se encontró INFOCOM para portar Zork a micros fue el mismo que tuvo Scott Adams, la falta de memoria. Pero a diferencia de Adams, INFOCOM decidio centrarse solo en sistemas con disco, lo cual ya les daba bastante soltura en cuanto espacio, pero aun así tuvieron que comprimir bien el texto y implementar su propio sistema de memoria virtual (algo que era casi experimental en ese tiempo) para que Zork cupiera en los micros de primera generación.

Otro problema a solucionar era que, aun centrándose en sistemas con disco, la variedad de micros a finales de los 70 hacia que el mercado estuviera muy disperso, por lo que para maximizar los beneficios los juegos tenían que ser portados a varios sistemas. La solución de INFOCOM es casi obvia hoy en día: diseñaron una maquina virtual, la maquina Z. Con esta solución solo tenían que portar el código de la máquina Z a cada sistema (un programa llamado ZIP), dejando el código de cada juego tal cual. Esta maquina esta, por supuesto, orientada a reproducir aventuras, y esta tan bien diseñada que sigue siendo la base para sistemas de aventuras modernos como Inform.

La máquina Z

Así que la maquina Z implementaba funciones básicas de entrada y salida, memoria virtual y el sistema de compresión dejando todo lo demás (incluido el parser) para ser programado dentro de ella. Lo bueno de que la Z-machine fuera lo mas simple posible es que todo Z-code, el código que interpretaba, no tenia que ser portado. Con lo cual si las partes mas complejas del juego, como el parser, se creaban en código-Z, ya no era necesario re-escribirlo para todos los ordenadores de la época; ganando en potabilidad.

La técnica de memoria virtual (algo muy nuevo en la época) les permitía tener en memoria solo las partes del juego que se estaban usando en ese momento. Cuando se requería algo que no estaba en memoria se cargaba de disco, borrando alguna parte de memoria cuando fuera necesario. Para poder hacer esto, la Z-machine clasificada en dos tipos de bloques de memorias: puros e impuros. Los bloques puros eran información que no se modificaba nunca como las cadenas de texto y las definiciones de objetos (que eran todos estáticos). Los impuros eran a su vez los que si se modificaban, como los flags de los objetos, su posición o las variables globales. Así que cuando fuera necesario mas espacio en memoria del disponible, la maquina-Z solo tenia que borrar cualquier bloque "puro" y reescribirlo con la nueva información. Si volvía a hacer falta el bloque borrado, sabiendo que es invariable, solo habría que re-leerlo del disco. Los bloques impuros debían permanecer siempre en memoria, y es lo que mas limitaba la RAM mínima para ejecutar los juegos. Los primeros juegos apenas requerían RAM, unos 32Kb, pero los últimos juegos, mas avanzados, requerían muchas mas memoria y prácticamente solo funcionaban en maquinas de 16 bits.

La memoria virtual, junto con un inteligente algoritmo de compresión de textos hicieron que los juegos de INFOCOM fueran los mas avanzados, complejos y largos durante años.

El Z-code era de un nivel parecido al ensamblador con algunas instrucciones especiales. Por lo tanto de crear los juegos directamente en Z-Code hubiera sido una tarea completísima. Usando su experiencia con grandes maquinas, decidieron crear un lenguaje especial de alto nivel para crear aventuras que se compilara generando z-code. Este lenguaje no era ni mas ni menos que un MDL (o sea LISP) muy simplificado, quitando cualquier cosa que no hiciera falta para hacer juegos de aventuras y añadiendo cosas que ayudaran al desarrollo.

Mirando por Internet, ninguno de estos compiladores de ZIL (Zork Implementation Language) ha sobrevivido hasta nuestra época, pero si alguna de la documentación para crear juegos, con lo cual podemos saber mas o menos como funcionaba. Y para ser un sistema de finales de los 70-principios de los 80, era toda una maravilla al servicio del creador de aventuras. Probablemente hasta la llegada de los sistemas especializados para PC a mediados de los 90, como TADS o Inform, no hubo mejor entorno para la creación de conversacionales.

El Zork Implementation Language: ZIL

Pero vamos a meternos en materia. La programación se realizada en este pseudo-LISP y la visión desde el punto del programador era bastante orientada a objetos, aunque la Programación Orientada a Objectos aun no se había desarrollado del todo por entonces, así que tiene algunas cosas un poco "raras", vistas hoy en día.

Lo primero vamos a estudiar la definición de una habitación:

<ROOM LIVING-ROOM
  (LOC ROOMS)
  (DESC "Living Room")
  (EAST TO KITCHEN)
  (WEST TO STRANGE-PASSAGE IF CYCLOPS-FLED ELSE "The wooden door is nailed shut.")

  (DOWN PER TRAP-DOOR-EXIT)
  (ACTION LIVING ROOM-F)
  (FLAGS RLANDBIT ONBIT SACREDBIT)
  (GLOBAL STAIRS)
  (THINGS <> NAILS NAILS-PSEUDO)>

Lo primero que salta a la vista es que se usan a la vez los paréntesis típicos de LISP con partes que se señalan con < y >, como las definiciones de habitaciones, objetos y las llamadas a funciones de sistema.

En todo caso, el lenguaje funciona como LISP, de forma que todo son listas de elementos entre paréntesis (o "<" ">"). Asi que una habitación es simplemente una lista con el identificador al principio ("ROOM LIVING-ROOM") seguida de las propiedades de la habitación. El primero "LOC" es el lugar donde esta el objeto, porque en realidad las habitaciones se tratan como objetos, solo que están siempre en el objeto especial ROOMS. Seguidamente tenemos las salidas, incluyendo una salida condicional que es bastante auto explicativa. La salida hacia abajo, mas complicada, en realidad llama a la función TRAP-DOOR-EXIT para decidir si se puede pasar o no.

La siguiente linea, ACTION, define la función que tratara algunos asuntos de la habitación, lo veremos mas adelante. Luego tenemos los objetos globales que están presentes en la habitación y la ultima linea es indescifrable para mi. Como podéis ver es un lenguaje bastante potente para definir cosas (contando en el año que estaban) y que a mi gusto me parece mas claro que lenguajes mas nuevos como Inform.

Habiendo visto una habitación, el código de un objeto es también bastante claro

Aparte de los parámetros ya explicados tenemos diferentes descripciones para cuando se examine o se describa con la habitación, su peso, los flags que indica que da luz y se puede coger junto con los adjetivos y sinónimos que el jugador puede usar.

Las funciones y el parser

Tal vez la parte mas potente de ZIL en si es la capacidad de crear funciones, que se pueden utilizar para crear la interacción con el juego. Se definían así:

Como podéis ver vuelven a aparecer los "<" ">", tanto para definir la rutina como para las función de sistema FCLEAR (pone a cero un flag de un objeto, en este caso el de la habitación tiene luz). Las funciones admiten parámetros, variables locales y hasta parámetros opcionales, en la forma:

< ROUTINE CALLEE (X "OPT" Y "AUX" Z)
<some-stuff>>

Digamos que el lenguaje tenia muchas comodidades que tardarían en llegar años al a programación en general!

Bien, pues estas funciones se utilizaban para interpretar las acciones del usuario. Primero el parser léxico identificaba un verbo, objeto directo y indirecto (si están presentes). Entonces dará la oportunidad a cada uno de estos objetos (o mas bien a su función ACTION) en el orden inverso de resolver el comando o si no dará el típico de "No puedes hacer eso". Para ello utiliza una función COND, que es una lista de pares condiciones - acciones, de las que solo se ejecute la primera que se evalúe a cierto con la forma:

<hacer-algo-1>)

(<predicado-condicion-2>

<hacer-algo-2>)

(<predicado-condicion-3>

<hacer-algo-3>)>

En cada predicado podemos comprobar si el verbo y los objectos cumplen ciertas condiciones o si el estado del juego es el correcto para activar un programa que muestre un mensaje, mueva objetos, etc. Cuando se empiezan a amontonar paréntesis es un poco complicado, pero en realidad es mucho mas fácil de definir y releer condiciones complejas que con otros sistemas de los 80. Por ejemplo, podemos responder una acción así al comer un aguacate envenenado:

Creo que es bastante auto-explicativo, pero SETG cambie el valor de una variable global, en este caso a cierto (T, es decir true), REMOVE quita un objeto (cambiando su propiedad de LOC, en realidad los objetos no se pueden destruir) y TELL muestra un mensaje por pantalla.

Las acciones de habitación, mencionadas al principio, en realidad lo hacen nada con el input del jugador, si no ejecutan ciertas funciones necesarias en cada habitación. Esta función recibe un parámetro en el que se especifica que tiene que hacer, siendo el mas habitual "M-LOOK", para describir la habitación como aquí:

<ROUTINE CAFETERIA-F (RARG)

Esto es especialmente útil para habitaciones que cambian con el tiempo o si hay algún objeto especial dentro. También hay funciones adicionales para cuando el jugador entra, sale o realiza una acción dentro de cada habitación; así que podemos controlar todo lo que ocurre dentro de la habitación.

Aun quedan muchas mas cosas, como crear personajes interactivos, timers, la definición del léxico... pero todo esto se hace de una manera parecida a la que hemos visto, así que si tenéis interés en saber aun mas de las interioridades de ZIL os recomiendo echar un vistazo a la bibliografía.

Conclusiones

Como podéis ver es un lenguaje muy potente, que permite especificar acciones complejas de una manera sencilla. Y todo en una época cuando muchos programadores la herramienta mas elaborada que tenia era un BASIC de 8 bits. Desde luego este sistema de creación de aventuras se tradujo en que las aventuras de INFOCOM fueran las mas depuradas, complejas y avanzadas durante toda su vida. Digamos que ello tenían una sierra mecánica para cortar arboles cuando la competencia usaba una lima de uñas.

Una parte de estas herramientas estaban tan bien diseñadas que sobrevivieron durante años, llegando hasta hoy en día. Me refiero al estándar de Maquina-Z, que esta aun vivo y portado a todos los sistemas existentes gracias a que fue la plataforma que Graham Nelson decidió para que su compilador Inform. Y aun hoy en día se crean aventuras con esta herramienta para las versiones clásicas de la máquina-Z. Desde luego el estándar ha sido extendido para soportar gráficos, sonido y quitar el limite de memoria entre otras cosas; pero hoy en día no hay ningún interprete de aventuras que no soporte el estándar Z.

Por desgracia, mientras que la máquina-Z aun sigue viva hasta hoy, el compilador ZIL se ha perdido en el tiempo y solo nos queda su documentación...

Update 2019

Recientemente se ha liberado el codigo fuente original en ZIL de todos los juegos de Infocom, como el mismo Zork I. No se ha recuperado el compilador original, pero solo con los fuentes podremos aprender nuevas cosas de como trabajaba Infocom.

Bibliografía y links de interés

Post recomendadísimo en "The Digital Antiquarian" sobre las herramientas de INFOCOM .
Documentación interna de INFOCOM sobre ZIL que ha sobrevivido hasta nuestros días.
Entrada en Mobygames de Zork I, de donde he sacado la captura de esta entrada.
Frotz, un interprete moderno y portable de la máquina-Z.
(Nuevo!) Repositorio con todos los sources de Infocom

viernes, diciembre 13, 2013

Sistemas para crear aventuras conversacionales (III) : INFOCOM