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

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

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

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:

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

               <SETG PLAYER-POISONED T>
               <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...

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

Entradas anteriores

• Sistemas para crear aventuras conersacionales (I)
• Sistemas para crear aventuras conversacionales (II) : Scott Adams

Vamos a jugar al Space Quest IV (parte 2)

Continuamos con las aventuras de Roger Wilco en Space Quest IV dentro de Space Quest XII, repitiendo una parte que nos habíamos dejado y viajando atrás en el tiempo hasta Space Quest X.

Vamos a jugar al Space Quest IV (parte 1)

A principios de los 90 vivía feliz con mi Spectrum +2 y mi flamante Amstrad CPC+ recién adquirido de un saldo del Continente. En aquella época mi principal fuente de información videojueguil provenía de la Microhobby, que ademas me proveía de una buena ración de demos y juegos completos. Pero un día de 1992, no llego a recordar si porque ya no había Microhobby, decidí atreverme con esa gran revista que era la Micromania. Y lo de grande lo digo porque por aquel entonces era tamaño que mas que periódico parecía una manta.

Y esa compra fue un shock para mi. Yo vivía tan feliz con mis juegos de 8 bits; pero esta revista me abrió los ojos a un nuevo e incipiente mundo: los 16 bits. Jamas olvidare la juegos como Future Wars o Heart of China, junto con la solucion del juego que hoy nos trae aquí, Space Quest IV. Yo era gran fan de las aventuras conversacionales, y devoraba todo lo que AD sacaba, pero este nuevo mundo de color, ratón e iconos me parecía la evolución natural del genero y me quede prendado de las nuevas aventuras gráficas.

Paso mucho tiempo hasta que tuve un PC, y aun mas hasta que pude jugar finalmente al Space Quest IV, cuando ya era casi un juego pasado de moda, pero esta aventura tiene un rincón muy especial en mis recuerdos sobre el ocio electrónico.

No me la acabe en su tiempo, y apenas recuerdo nada quitando la parte del principio, pero espero pasármelo, aunque tenga que echar un vistazo de vez en cuando a la solución.

P.D.: Curioso es que buscando una solución en internet, encontré esta en Meristation, fechada en nada mas y nada menos que en 1993, antes incluso que existiera la revista electrónica como tal.

Aventuras conversacionales japonesas: Kimagure Orange Road para MSX2

La serie de Kimagure Orange Road es uno de esos animes que abrió los ojos a muchos futuros otakus al mundo del manga y la animación japonesa. Y eso a pesar de los cambios de nombre, horarios variables y censuras varias. Seguramente a la calidad de la animación y de su diseño de personajes, la genial banda sonora que acompaña y engancha y una historia romántica poco vista hasta entonces por estos lares influyeron en el nacimiento de una generación de frikis.

Muy buenos gráficos en 8 bits, pero pocas cosas que hacer.

Bueno, dejando momentos nostálgicos aparte, en 1988, cuando KOR ya estaba dando sus últimos coletazos, Microcabin produjo un videojuego para los 8 bits de la época  incluyendo el popular PC-88 y el estándar MSX2, versión con la que me he podido hacer. El juego es una aventura conversacional, pero a diferencia de las otras dos que comente, esta ya da el paso a ser controlada totalmente por menús, con descripciones gráficas y textuales.  La historia nos sitúa en un verano en que Madoka se ha ido de vacaciones la extranjero y Kyosuke se ha quedado solo y aburrido en la ciudad. Y a partir de aquí tienes libertad para moverte por la ciudad.

El mítico Abcb. Solo por visitar estos lugares merece la penar probar este juego.

Al igual que en la aventura de Gundam, los gráficos son de gran calidad, reflejando muchos de los escenarios y personajes de la saga con un estilo muy parecido al anime. Eso si, todo a costa de continuas cargas de disco para hacer casi cualquier cosa (pero no tan soporíferas como las del Gundam).

Podemos ir hasta los vestuarios del Abcb!

La interacción por menús es muy sencilla, y es muy fácil jugarlo hoy en día (si sabes japonés claro, aunque no es muy complicado). Ademas el juego esta escrito de manera "normal", usando kanjis, hiragana y katakana cuando toca, con lo que no tienes que dejarte los ojos leyendo en katakana o buscando la separación en hiragana.

Después de jugarlo un buen rato, la verdad, no he conseguido hacer nada mas que visitar los lugares típicos del anime y hablar con algunos personajes. La mayoría de las acciones devuelven un "no hay nada importante" y cosas así; con lo que la interactividad es un poco limitada. Ademas, las conexiones entre lugares son un poco raras (después de salir de la casa Kyosuke no conseguí volver a entrar...).

Kyosuke vagueando en su habitación

Durante el juego no hay música  pero en  el Abcb tienes una jukebox en las que puedes seleccionar varias canciones de la serie, que suenan espectacularmente bien en MSX.

En definitiva, me parece un juego dirigido a los fans, por la cantidad de referencias que reconocerán  Los gráficos son impresionantes para 8 bits pero la jugabilidad se resiente al ser tan lento y tener tan poca interactividad. Eso si, hubiera matado por tenerlo en su época (^__-).

El comienzo del juego es el típico sueño de Kyosuke.

El juego cuenta con todos los personajes de la serie.

Otras aventuras japonesas en mi blog

• Aventuras conversacionales japonesas: Mobile Suite Gundam Part 1
• Aventuras conversacionales japonesas: Southern Cross

Lo que te puede pasar cuando juegas al Demon Gaze

Como ya conte hace un tiempo, Demon Gaze es un dungeon crawler con personajes estilo anime para la Ps Vita. El protagonista, que ha perdido la memoria, vive en una pension llena de aventureros y caza-tesoros.

Pues eso que en uno de los eventos del juego el protagonista tiene que ir a la habitación de la casera, a comprobar si pone huevos o no (!?), o en otras palabras, a comprobar si es humana. 

Si no la crees se empezará a desnudar...

Quedando en ropa interior, que después de todo es un juego de Vita.

Y si aun eliges que no estas convencido de que sea humana, te dira que le toques los pechos para comprobarlo (!?).

Cosa que puedes hacer, pero solo con un texto, que sigue siendo un juego de consola.

En fin, parece que el personaje tiene algún secreto respecto a su "humanidad", porque enseguida te cuentan que no es la primera vez que alguien hace esta "comprobación".

Recordad que Demon Gaze es un juego estilo Wizardry de exploración de mazmorras en el que es muy facil morir, pero parece que Sony esta optando por dejar "enseñar carne" para atraer jugadores a su portátil (aunque con estos eventos da cosa jugarlo en el metro XD).

P.D.: A otro personaje le da por pasearse en ropa interior por la pension...

Sistemas para crear aventuras conversacionales (II) : Scott Adams

Adventureland, la primera aventura de Scott Adams

En la anterior entrada esta serie hablábamos de dos sistemas de aventuras conversacionales que funcionaban en los grandes y caros mainframes de universidades o empresas. Esta vez vamos a hablar de un sistema diseñado especialmente para el recién nacido mercado de micros de finales de los '70.

Se trata del mítico sistema ideado por Scott Adams, que a parte de crear o publicar una gran cantidad de aventuras para multitud de plataformas, es también uno de los iniciadores del mercado de los videojuegos para ordenador como tal.

La historia ha sido contada por él mismo y en cualquier articulo que hable de las conversacionales se le nombra, ya que fue muy importante, no solo por sus juegos, si no porque su sistema influencio a multitud de imitadores en los años iniciales de los micro-ordenadores. Así que, resumiendo un poco, Scott Adams disfruto de la Aventura Original en un mainframe de su trabajo y decidio buscar una manera de portarla a su micro. Aunque ese micro fuera un TRS-80 de 16Kb y cassette  Tarea titánica donde las haya, ya que, recordemos, la Aventura Original funcionaba en disco y solo el juego ocupaba mas de 200Kb.

Scott Addams uso su ingenio para crear un sistema de aventuras re-utilizable que cupiera en 16Kb y programado en BASIC. Por supuesto, no recreo toda la aventura original, pero consiguió crear juegos muy entretenidos con tan poca memoria. Vamos a ver como se las arreglo.

Primero, simplifico las descripciones a una linea, que siempre empezaban por "Estoy en", con el consiguiente ahorro de memoria. Los "objectos" con los que se puede interactuar aparecen a continuation de un "Tambien puedo ver", en forma de lista y después de las salidas. El parser era sencillo, soportando solo frases del tipo "verbo objeto", pero mas que suficiente para interactuar con el mundo virtual de la aventura. Y, ademas, este sistema de juego con textos simplificados venia muy bien para los jovenes españoles que como yo, aun habiendo aprendido solo un poco de ingles, queria sumergirse en el mundo de las conversacionales ^__^.

El principio de Pirate Adventure

El primer juego que lanzo fue Adventureland, una version de la Original, y a continuacion Pirate Adventure. Esta aventura, en BASIC, fue publicada en el especial de la revista BYTE sobre aventuras, por lo que se puede ver como esta hecha, o al menos su interprete. La aventura esta dividida en un programa que graba los datos de la aventura en casette y luego el interprete en si. Según el mismo articulo el juego original no usaba este cargador, sino que Addams tenia otro programa editor de aventuras (que por desgracia no llegó a publicar).

El motor es realmente sencillo, los objetos, localidades, conexiones, mensajes y demás información están organizados en arrays, usando matrices en algunos casos (como para la salidas, cada localidad tiene 6 definidas en el array RM). El tamaño de los arrays es dinamico y es leido al principio del juego en variables acabadas en L (RL seria Room Length, imagino).

Los verbos y nombres están recortados a las 3 primeras letras, haciendo que sean difíciles de reconocer en el código del juego. Las respuestas a las acciones del jugador, si vemos el código fuente son una serie de números sin sentido aparente.  Gracias a interpretes y compiladores modernos del formato de Scott Addams podemos darles un poco de claridad a esta tira numerica.

En realidad utiliza un formato que se haría muy popular en juegos posteriores de establecer un esquema de condición-acción para cada entrada de "verbo nombre" definida en una lista de vocabulario (el vocabulario en el array NV$, las condiciones-acciones en el array CA, las abreviaciones son casi obvias). Así que cada bloque de 7 de esta lista corresponde a una lista de condiciones o acciones, identificadas con números para reducir espacio, indexada por una entrada en NV$ que contiene un verbo y un nombre (o solo un verbo).

Entre las condiciones tenemos las típicas de comprobar la localidad actual, si hay algún objeto presente o lo tiene el jugador, etc. Tambien contamos con unas cuantas flags (el juego que mas usa tiene unas 32) de verdadero/falso, 16 contadores y 16 registros para salvar números de localidad (aunque solo se usan en juegos mas avanzados). Luego tenemos las acciones, que tambien son las típicas de mostrar un mensaje, mover un objeto o al jugador de sitio, modificar los marcadores anteriores etc. Si cualquier condición falla, el interprete para de ejecutar ese bloque. Tenemos un máximo de 7 condiciones-acciones por bloque en la tabla, pero hay una acción especial que permite continuar en la siguiente para crear respuestas mas largas.

The Count, otro juego de Scott Adams

Por supuesto no hay que definirlo todo con estas condiciones-acciones, el engine incluye funcionalidades básicas para movernos por el escenario y los típicos mensajes de "no te entiendo" o "no puedes hacer eso".

Como veis una estructura muy sencilla y muy adaptada a lo que se puede hacer en Basic, haciendo un uso extensivo de los arrays de dos dimensiones. Aunque el código esta escrito casi sin espacios para ahorrar memoria, parece ser que mucha gente destripo esta estructura y lo uso de base para otros juegos conversacionales. No puedo confirmar es si la famosa estructura de condiciones-acciones (que luego veríamos en el Quill y el PAWS) en vez de usar IFs tiene su origen en estas primeras aventuras, pero desde luego Scott Adams consiguió crear un sistema re-utilizable para crear aventuras con unos recursos limitadísimos. Lo que daría por ver la herramienta que utilizaba para crear aventuras y seguir haciendo arqueología aventurera ^^.

En la linea 1270 del interprete se DIMensionan todos los arrays/matrices importantes

Por ultimo comentar que las versiones mas populares que vimos en Europa para Spectrum y compañía eran ya versiones "re-masterizadas" programadas en código máquina y que incluían en muchos casos gráficos para las localidades.

Mas información

• Compilador moderno para el formato de Scott Adams.
• Scans de la revista Byte de 1982 con el articulo de Scott Adams.
• El mismo scan para leer online.

Mas entradas en esta serie

• Sistemas para crear aventuras conersacionales (I) : Adventure y el A-Code

Las captura de pantalla de este articulo son de Mobygames.

Recuerdos de la Aventura Original

En esta pantalla empezaba todo.

Todo esto son recuerdos de cosas que pasaron hace ya bastante tiempo, cuando hacia muy poco que habíamos actualizado nuestro Spectrum por un flamante Amstrad CPC 464+ (que ya estaba de saldo, pero venia de perlas al tener monitor propio). Por aquel entonces cayo en manos de mi hermano y mías un pack de varios juegos de Dinamic llamado Metal Action. No me sonaba ningún juego del pack, tal vez por que por aquel entonces solo reconocía títulos de recreativas o de películas  pero quedamos sorprendido por la calidad de muchos de los juegos incluidos (la rapidez y el colorido de AMC son de lo mejorcito que se puede ver en un CPC).

Entre todos estos juegos de acción habia uno diferente. Una aventura de texto. Aunque conocia el genero de oidas ("esos juegos que tienes que escribir comandos para hacer cosas"), nunca habiamos jugado a ninguno. A priori parecia una oferta bastante aburrida comparada con el resto de titulos de accion como After the War o Satan; y tal vez por eso quedo prácticamente como el último titulo a probar.

Y sin embargo acabo siendo el juego al que le dedicamos más tiempo, y creo que el único del pack que pudimos finalizar. Es dificil de explicar, pero creo que esta Aventura Original me abrio los ojos que los videojuegos eran algo mas que tiros y peleas, que podian describir una historia e incluso un mundo virtual con el que podias interactuar. Con muchas limitaciones, es cierto, pero incluso con eso la variedad de cosas que podias hacer daba una nueva profundidad a los videojuegos que conocia. Era como entrar en un mundo nuevo y complejo que otros videojuegos no podian proporcionar.

La portada del pack Metal Action que incluía la Aventura Original (imagen de amstrad.es)

Ademas, el estilo de Andres Samudio era perfecto para la edad que teniamos, unos 11-12 años. Sin ser ni demasiado infantil, ni demasiado adulto y con los toques de un humor muy particular hacia que esta aventura fuera bastante accesible para todo el mundo. Y bueno, a partir de aquí emepezo mi aficcion por las aventuras de texto.  Dado que ya estaban un poco pasadas de moda comercialmente, tuve que buscar y rebuscar, pero llegue a tener casi todas las editadas en español, incluidas todas las de AD (Chichen Itza la acabe jugando en PC). Y de ahí pase a las aventuras gráficas, RPGs y hasta hoy en día me siguen gustando esos juegos que te meten en su mundo propio y te dejan atrapado.

En fin, ¿a que viene todo este texto? Pues que el creador de esta Aventura Original, Andres Samudio (también conocido como el Viejo Archivero por su sección en Microhobby), esta realizando una novelización de sus aventuras, empezando por esta Original, y ahora esta en proceso una campaña de crowdfounding en Verkami para recaudar fondos para su publicación en formato físico. Así que ya sabéis  si sois como yo y vivisteis esa época de oro de las aventuras conversacionales en castellano, no lo dejéis escapar!

Supongo que si no conocéis las aventuras conversacionales de la época de 8 bits muchas cosas de este articulo os sonaran a chino, en ese caso echad un vistazo a la web del CAAD, igual os abre las ventanas a un nuevo mundo.

Mas información

Web del Viejo Archivero.

Web del proyecto en Verkami.

Pagina del CAAD sobre la Aventura Original.

Libros de programación de videojuegos japoneses

Si hay algo que le gusta a los japoneses es leer. Tokyo esta lleno de enormes librerías que abren hasta altas horas de la noche, en algunos sitios hasta la madrugada, vendiendo todo tipo de literatura, desde revistas a libros muy especializados.

Como programar juegos de aventura

Con el interés que tienen también los japoneses en los videojuegos y lo desarrollado de su industria no es de extrañar que los libros de creación de videojuegos sean muy abundantes, tanto traducciones de autores americanos como de originales de autores japoneses.

De los primeros que me llamaron la atención son esta serie de libros que explican como crear videojuegos de diferentes géneros  En realidad, la mayor parte, son reediciones de libros que se habían editado por separado, así que el estilo de cada libro es bastante diferente.

Como programar RPGs

Buscando en tiendas de segunda mano he conseguido que estos tres caigan en mis manos. El primero es "Como programar juegos de aventuras". Y como aventura se entiende en el estilo japonés, en el que la base son diálogos con personajes y alguna elección de vez en cuando. Prácticamente casi todo el libro se dedica a explicar como implementar una maquina virtual y un lenguaje de script para crear este tipo de historias, junto con algunos efectos visuales.

El segundo es "Como programar juegos de RPG", mas concretamente en este caso de estrategia por turnos. Describe un sistema sistema en vista isométrica con una IA, pero todo extremadamente simple. A parte, este libro vuelve a incluir otra maquina virtual y un sistema de scripts para las escenas entre combates, aunque no es tan complejo como el primero.

Estos dos primeros libros son muy sencillos y ideales para principiantes. El problema es que la parte gráfica esta anticuada. Bueno, anticuadísima. Ni siquiera llegan a usar DirectX, todas las tareas gráficas se realizan directamente con la API de Windows. Quitando esta parte, creo que son una muy buena introducción de como funcionan este tipo de juegos por dentro.

Como programar shooters

El tercer libro es mucho mas moderno y mas practico. Se trata de "Como crear tu propio shooter" (entiendase por shooter lo que ahora llamamos shump) y, a parte de usar las DirectX, explica bastante bien como hacer un juego que requiere procesar muchas cosas rápido desde cero. El tipo de juego que describen son del estilo de la saga Toho o los de Cave, con toda la pantalla llena de balas con movimientos en varias formas. Este libro es incluso la base para dos libros mas del mismo autor que profundizan exclusivamente en algoritmos para las balas.

En fin, menos el tercero, los dos primeros son solo recomendables si sois principiantes o os gusta leer material de este tipo como a mi ^^. La serie tiene aun mas libros (juegos de puzzle, plataformas y lucha) pero aun no me hecho con ellos.

Aventuras conversacionales japonesas: Mobile Suite Gundam Part 1

La portada del juego

Cuando empezaba en esto del manga uno de los primeros libros de ilustraciones que compre fue el "Haruhiko Mikimoto Illustrations". A parte de encantarme el autor por los diseños de Macross, el libro era bastante barato, y lleva incluso los textos traducidos al ingles. Eran los principios de los 90, sin Internet y apenas con la información de un par de fanzines, así que la variedad de ilustraciones de animes y mangas del libro que yo no conocía me dejo abrumado.

"Puedes ver un Zak" suena algo raro

Con el tiempo fui conociendo muchas de estas series (como Gundam 0080, Orguss y otras tantas), pero unas ilustraciones muy trabajadas sobre unos videojuegos de Gundam seguían siendo un misterio. Ni con la llegada de internet llegue a encontrar demasiada información, así que estos juegos tenían para mi un halo de misterio y curiosidad.

Pues bien, pasado aun más tiempo descubría que se trataba de mas ni menos que de aventuras conversacionales con unos pocos detalles arcade. El titulo completo era ""機動戦士ガンダム PART1 ～ガンダム大地に立つ！！～" o Kidou Senshi Gundam Part 1, Gundam daichi ni tatsu!" (Gundam se levanta sobre la tierra). El juego fue lanzado en 1984 para los ordenadores personales de los 80 en Japón, como el FM-7 o al PC-88 en dos cintas de cassette. A primera vista nos recordara a las aventuras conversacionales de sierra antes de King Quest, como mucho espacio para la imagen y poco para el texto.

Pilotando el Gundam

La aventura esta totalmente en ingles, con alguna parte en japanglish (ya explique hace un tiempo que muchas conversacionales japonesas se hicieron en ingles). Narra mas o menos el famoso principio de la serie en que Amuro se sube al Gundam por primera vez y como sale en la White Base. Aunque la interacción es por comandos de texto, el juego basa su fuerza en las ilustraciones, algunas muy bien realizadas para la época (en realidad se crearon primero las ilustraciones y luego el guión del juego). Es curioso por que también "pilotamos" el Gundam con comandos de texto y hasta podemos leer el "manual" de control.

El ingles es un poco ortopédico

A veces hasta parece una aventura normal

Solo hay un puñado de localidades (o situaciones), todas con ilustraciones buenas para la época. A parte de los comandos de movimiento, el juego solo entiende los comandos exactos para la solución. En realidad en todo el juego solo hay 30 mensajes! También hay una parte arcade, en la que deberemos disparar con el Gundam, pero es bastante cutre.

Este juego es la primera parte, llego a salir una continuación que no he tenido oportunidad de probarla, pero tiene todo el aspecto de ser mas de lo mismo. En conjunto es un juego bastante raro, tanto por estar en ingles, como por la cutrez del engine comparada con la calidad de las ilustraciones (sobre todo la porta del maestro Mikimoto). Desde luego parece un juego hecho para aprovechar esas buenas ilustraciones y la fama que empezaba a tener Gundam por esas fechas.

El juego tiene muchas situaciones famosas

Creo que no podemos estrujarla...

Links

• Web con la solicion.
• Otro articulo en japones.
• Un video del juego:

Dungeon Builder : the Graphic Adventure Writer

Seguiendo el éxito del Quill, el primer sistema integrado para crear conversacionales en el Spectrum, aparecieron unos cuantos programas que intentaban entrar en el mercado rellenando alguna de las carencias que tenia el sistema de Gilsoft. Dungeon Builder es uno de ellos y, aunque nunca logro destacar demasiado, vamos a ver como era.

Pantalla principal

Como principal ventaja sobre el Quill es que cuenta con gráficos, que se pueden dibujar con vectores y rellenos, como es usual en las aventuras de 8 bits. El mapeado, las conexiones entre estancias, se crean con una rejilla octogonal en la que se "desbloquean" las conexiones, tanto normales como condicionales usando un cursor. Si nos colocamos en un borde modificaremos las conexiones, si nos colocamos en el centro podremos modificar la descripción de la estancia y añadir objetos.

Un ejemplo de los juegos que se pueden hacer

Para expresar condiciones y para programar las acciones del usuario creamos una serie de acciones encadenadas, bastante sencillas (mostrar un texto, mover un objeto, mover al jugador y similares), seleccionadas desde un menú. También tenemos una serie de objetos con sus propiedades. Algo novedoso es que cada objeto lleva asociado un estado: podemos mostrar una descripción diferente por estado y usarla para las condiciones (por ejemplo, una puerta abierta o cerrada).

Descripción del Dungeon Builder

Las acciones y condiciones que tenemos son bastante limitadas comparadas con las del Quill, pero al ser elegibles desde menu pueden ser  mucho mas claras para los no programadores. El problema es que no podemos verlas en conjunto una vez programadas, sino que tenemos que pasar la lista una por una, y ademas editarla para poder ver el contenido, lo cual hace muy complejo revisar cualquier respuesta.

El juego deja libre 10Kb para nuestra aventura mas otros 10Kb que guardan la descripcion de las estancias (son fijas por la rejilla) y objetos. Segun el manual también incluye un compresor que nos da hasta un 1.5 veces mas de espacio. El manual es bastante completo, con ejemplos de como usar cada función  del soft para sobrepasar sus limitaciones.

La pantalla principal del editor

Lo cierto que este creador tiene muchas menos posibilidades que un Quill o un Gac, pero con buenas ideas como la rejilla para el mapeado o los estados. Ojalá hubieran mostrado visualmente también las acciones y hubieran añadido mas control sobre la aventura. En definitiva, un sistema sencillo, con el que solo podremos crear aventuras poco ambiciosas, similares a la original.

Mas info

• Entrada en el World of Spectrum

Mas imagenes

Una guía de la pantalla principal

Una captura del manual

Comparandolo con el GAC