 |
| 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.
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.")
(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)>
(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
<OBJECT LANTERN
(LOC LIVING-ROOM)
(SYNONYM LAMP LANTERN LIGHT)
(ADJECTIVE BRASS)
(DESC "brass lantern")
(FLAGS TAKEBIT LIGHTBIT)
(ACTION LANTERN-F)
(FDESC "A battery-powered lantern is on the trophy case.")
(LDESC "There is a brass lantern (battery-powered) here.")
(SIZE 15)>
(LOC LIVING-ROOM)
(SYNONYM LAMP LANTERN LIGHT)
(ADJECTIVE BRASS)
(DESC "brass lantern")
(FLAGS TAKEBIT LIGHTBIT)
(ACTION LANTERN-F)
(FDESC "A battery-powered lantern is on the trophy case.")
(LDESC "There is a brass lantern (battery-powered) here.")
(SIZE 15)>
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í:
<ROUTINE TURN-OFF-HOUSE-LIGHTS ()
<FCLEAR ,LIVING-ROOM ,ONBIT>
<FCLEAR ,DINING-ROOM ,ONBIT>
<FCLEAR ,KITCHEN ,ONBIT>>
<FCLEAR ,LIVING-ROOM ,ONBIT>
<FCLEAR ,DINING-ROOM ,ONBIT>
<FCLEAR ,KITCHEN ,ONBIT>>
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>>
<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:
<COND (<predicado-condicion-1>
<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:
<ROUTINE AVOCADO-F ()
<COND (<VERB? EAT>
<COND (<VERB? EAT>
<SETG
PLAYER-POISONED T>
<REMOVE ,AVOCADO>
<TELL "You begin to feel sick.">)>>
<REMOVE ,AVOCADO>
<TELL "You begin to feel sick.">)>>
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)
<COND (<EQUAL? .RARG ,M-LOOK>
<TELL "This is a lunch room, with windows
overlooking a loading dock. ">
<COND (<IN? LUNCH-CROWD
,CAFETERIA>
<TELL "Every table is jammed
with patrons. ">)>
<TELL "The only exit is
north." CR>)>>
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...
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.
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
