¿Pero cómo quieres que vendamos esto? ¡Si en pantalla sólo sale texto! ¡No hay gráficos! ¿Pero qué clase de videojuego no tiene video?
Así recordaba Neil Harris, un programador de la pionera Adventure International, la experiencia de mostrar al personal de ventas una nueva serie de juegos que pretendían introducir al mercado. Correría el año 1980 y, poco después, esos extraños «videojuegos sin video» pasarían a dominar las listas de ventas de los microordenadores VIC-20, ante la estupefacción de esos mismos vendedores. Adventure International llegó a contratar a 50 personas y a publicar cientos de juegos de todo tipo y género, antes de caer víctima del crash del 83 (un crash que, por cierto, nunca fue tal: en todo caso fue el crash de Atari o, como mucho, del crash del mercado norteamericano; pero esa es otra historia y será contada en otra ocasión).
Estos juegos de éxito eran aventuras de texto. Adventure International te proponía explorar mágicas cavernas, remotos planetas, la guarida de un pirata, o enfrentarte al conde Drácula en su propio castillo. En comparación, los juegos «de video» y su tosca presentación basada en sprites de baja resolución y gráficos de bloques no estaban a la altura.
Este concepto de escapismo, esa promesa transportarte a otro mundo y explorarlo e interactuar con él libremente, ha sido siempre un fuerte reclamo en el mundo del videojuego. La misma ambición la han venido compartiendo desde las primitivas aventuras del VIC-20 hasta los juegos de mundo abierto o RPG de hoy en día. Pero en los 80, cuando las grandes capacidades gráficas no eran ni un sueño lejano, la única opción realista que podía satisfacer de algún modo esa promesa de zambullirse en una fantasía era la aventura de texto. Y la magia que lo hacía posible era el parser.
¿Qué es un parser?
Estrictamente, un parser (del inglés to parse, o analizar) es la parte de un programa que averigua cuál es el significado de un texto. En el mundo de la aventura, el término se suele usar de forma más amplia, entendiéndose que el parser es todo el código genérico que puede reutilizarse en varios juegos diferentes. En pocas palabras, el «motor» del juego. Hoy día el término es popular gracias a motores comerciales como Unreal o Unity, pero las aventuras de texto fueron pioneras en su concepción.
A veces, un parser es un simple conjunto de librerías utilizadas internamente por una compañía. En otras ocasiones, se trata de un producto cerrado, independiente de los juegos, quizá comercial, que puede venir acompañado de herramientas para poder llevar a la práctica los juegos usando lenguajes de programación simplificados o incluso visuales.
Aunque hoy día la idea de separar de un juego aquellas partes que pueden considerarse genéricas y hacer con ellas un motor reutilizable parezca obvia, en su momento supuso una innovación importante. ¿Y de dónde salió?
Orígenes del parser
Retrocedamos. El origen del concepto en sí, es decir, de la idea de recoger e interpretar una entrada de texto genérico del usuario (la mera acción de parsear), se encuentra en los intérpretes de comandos: las llamadas shells. El nombre viene de principios de los 60, de la mano de un pionero de las ciencias de la información: el francés Louis Pouzin, miembro por entonces del MIT, el Instituto de Tecnología de Massachusets. Sin embargo, ¡el concepto es incluso anterior! Ya los gigantes de los años 50, monstruos de válvulas de vacío y tambores magnéticos, contaban con algún tipo de programa monitor residente que interpretaba algunos comandos básicos del usuario.
Estos intérpretes ofrecen al operador la capacidad de introducir un texto libre, escrito en alfabeto corriente (originalmente, en tarjetas perforadas, y posteriormente a través de teletipos y terminales) que la máquina analizará e interpretará como una orden a ejecutar.
En general, se espera que la primera palabra consista en el nombre de un programa (o, a veces, alguna acción predeterminada comprendida por la propia shell), y las siguientes sirvan de parámetros cuyo significado depende de la acción especificada. La cantidad de acciones disponibles varía, y de hecho aumenta a medida que el usuario instala nuevos programas. Inspiradas más por los lenguajes de programación que por el lenguaje natural, la influencia de las shells es tan tremenda que ha pasado más de medio siglo y siguen siendo una herramienta de uso diario por administradores de sistemas y programadores.
El intérprete de comandos introduce conceptos como el prompt, una marca o cursor que indica que el sistema está preparado para recibir una nueva entrada, y el bucle interactivo de comandos (lo que podríamos entender como modo «conversacional»), en el que el usuario escribe una acción, el ordenador responde con un mensaje informando del éxito o error en la misma, a continuación aparece un nuevo prompt, y vuelta a empezar, como si de un diálogo entre dos personas se tratase.
La primera aventura
En estas estábamos, cuando William Crowther, espeleólogo aficionado, pionero programador y jugador ocasional de Dungeons & Dragons, subió un juego que había estado desarrollando en su tiempo libre a la ARPANET, la famosa red del Departamento de Defensa de los Estados Unidos que acabaría fundando las bases de la actual Internet. Colossal Cave Adventure, creada sobre teletipos de los mainframes PDP-10 acabaría siendo el origen de una afición y uno de los juegos más influyentes de la historia. Su interfaz de uso recuerda el de una shell, con importantes diferencias: Crowther acababa de sufrir un divorcio traumático y quería un juego amigable, que pudiera ser disfrutado por sus hijas, lejos de esotéricos comandos y abreviaturas.
Adventure funciona con un particular sistema de comandos basado en escribir una o dos palabras simples en inglés: el nombre de un lugar o cosa que forme parte del mundo de juego y, opcionalmente, una acción a realizar. Omitir uno de los dos componentes es aceptado y el juego completa la orden usando la lógica (si escribes el nombre de un lugar, se asume GO como verbo; si escribes EAT y hay comida presente, se asume como sujeto). Si el programa no puede resolver la omisión de un componente, pregunta al usuario de forma interactiva.
Adventure no presenta al jugador el abanico completo de verbos disponibles: se espera que éste averigüe, por sí mismo, la existencia de ciertas acciones (como agitar la varita) sin otra información que el hecho de que tienen lógica en el contexto del mundo de juego. Esta particularidad es una seña de identidad de las aventuras de texto y representa uno de los aspectos más interesantes del parser como interfaz de uso: los límites de la interactividad con el mundo de juego no son claros, intencionadamente.
Y es que, idealmente, los problemas en una aventura de texto no se resuelven buscando la manera en la que combinar unas acciones (unas «piezas») predefinidas, sino abstrayéndose al mundo de juego para imaginar qué solución tiene sentido en esa situación (por ese motivo «problema» es una palabra más acertada que «puzle» para un obstáculo en una aventura). Por supuesto, este sistema dista de ser perfecto. En primer lugar, la solución a un problema puede no ser lógica (o, si nos ponemos gafapastas, el modelo mental del mundo que se plantea el jugador difiere del que tenía el autor en su cabeza, sea porque le falta información o porque interpretó detalles de la situación de forma diferente) o, aunque la solución sea simple, la forma que el autor ha previsto en la que hay que expresarla es otra.
El parser de Adventure tiene particularidades muy interesantes. Para empezar, reserva una parte sorprendentemente grande en resolver acciones de movimiento. Para desplazarse, es posible interactuar con el entorno (entrar en la casa), ir directamente a un lugar remoto (ir al bosque) o desplazarse posicionalmente empleando una dirección (arriba o abajo) incluyendo puntos cardinales (norte, sur…). Pocas aventuras posteriores mantuvieron la opción de movimiento directo a localidades, dadas las dificultades inherentes (¿qué ocurre si el camino al destino especificado atraviesa una zona potencialmente peligrosa, una puerta que hay que abrir, etc.?), pero el uso directo de puntos cardinales como verbos, así como el concepto de «localidad» (lugares conectados por estas acciones de movimiento) pasaron a ser una señal de identidad de las aventuras de texto.
Notablemente, Adventure ya contiene una base de datos separada del código del juego, aunque su intérprete está muy integrado con el juego (la lógica específica de los problemas está hardcodeada) y no sería fácilmente reutilizable. El fichero de datos contiene el vocabulario del juego, la descripción de todas las localidades, el estado y posición de todos los objetos, y los mensajes de texto que se muestran en pantalla.
La primera versión del juego era mucho más pequeña que la que se popularizó más tarde, pues el propio Crowther había perdido el interés en el desarrollo del juego tras obtener una primera versión ya funcional. Don Woods, un estudiante de Stanford entusiasmado con el juego, recogió el revelo tras lograr contactar con Crowther enviando correos a todas las direcciones de e-mail que encontró en ARPANET. Su versión amplió el mapeado a más del doble de tamaño y, además, se distribuyó con el código fuente incluído. La disponibilidad de éste y la cultura hacker predominante en los entornos académicos y empresariales de los 70 originaron un complejo legado de versiones ampliadas y modificadas del juego. Una versión especialmente notable fue la de Dave Platt, de 550 puntos, escrita en 1979 y que movía la lógica de juego fuera del parser, utilizando un lenguaje de scripting inventado por el autor, muy similar a los lenguajes de «condiciones/acciones» de parsers comerciales que veremos más adelante. La base de datos de esta versión de Adventure era totalmente independiente del juego, siendo el intérprete un programa aparte.
Infocom y la Z-Machine
Zork nació dentro de esta cultura, inspirado directamente en Adventure. Buena parte de la razón de ser del juego era la voluntad de sus autores de soportar interacciones mucho más complejas de las que ofrecía este último: el sueño es poder interpretar, directamente, el lenguaje natural (bueno, el inglés). Zork soporta acciones con varios parámetros, preposiciones, adverbios, adjetivos, y distingue entre distintos tipos de complementos. Reconoce listas de objetos para acciones comunes como coger o dejar, y también el uso de ALL para acciones tales como TAKE ALL o incluso TAKE ALL FROM TABLE. Pero es que la interpretación del lenguaje natural en Zork va más allá de ejecutar acciones sofisticadas en imperativo: es posible formularle preguntas como WHERE IS THE MAILBOX? o WHAT IS THE ZORKMID?. Soporta también comunicarse usando frases entrecomilladas SAY ‘HELLO’ y dar órdenes a otros personajes con una sintaxis específica: JOEL, TAKE THE SWORD.
La resolución de órdenes ambiguas o incompletas alcanza un nivel de sofisticación sorprendente. Zork reconoce la palabra IT y la sustituye por el último objeto referenciado por la aventura y no por el jugador; por ejemplo, tras abrir el buzón, el juego responde que en su interior hay un folleto, y en ese momento TAKE IT permite cogerlo, aunque el jugador nunca ha hecho referencia al mismo. Ante un sujeto omitido, Zork completa la frase con el objeto que considere más lógico (LIGHT se interpreta LIGHT THE LANTERN) informando al usuario de la sustitución y, ante múltiples opciones válidas, ofrece una lista y pregunta cuál es la opción correcta. Al igual que ocurría en Adventure, cuando el parser pregunta algo, esta pregunta es interactiva, y la siguiente entrada por parte del usuario puede ser una breve respuesta, o una acción normal en todo caso.
Zork reconoce los puntos cardinales, y la interacción con el entorno presente GO THROUGH WINDOW, pero no permite ir directamente a una localidad remota previamente visitada. En general, las opciones de movimiento mediante puntos cardinales y direcciones quedan asentadas como parte del lenguaje fundamental de las aventuras de texto.
Su vocabulario es extenso (unas 600 palabras) pero ante cualquier palabra que no se encuentre en el mismo, abortará la interpretación con un error informando de la palabra desconocida, dando al jugador la oportunidad de reconocer las limitaciones del parser.
No cabe duda de que los pioneros Infocom hicieron un trabajo increíble, que en muchos aspectos supera parsers nacidos décadas más tarde. Su interpretación sofisticada del lenguaje natural aspiraba a ofrecer a un usuario novel la capacidad de usar el programa sin aprender un lenguaje de comandos.
Los esfuerzos fueron loables. Sin embargo, a pesar de todas las innovaciones, un usuario que desconozca las particularidades del género y se siente delante de Zork poniéndose a escribir lo que se le ocurra, ignorante de los límites de la máquina, chocará con muchas barreras de comprensión por parte del juego. Y es que, al final del día, el parser sólo comprende instrucciones establecidas de antemano, un subconjunto del lenguaje natural. Si me apuran, un dialecto (en círculos aventureros anglosajones a este dialecto informita le llaman informese). Sin experiencia previa o un manual, es difícil saber que el programa reconoce listas de objetos o conceptos como ALL o IT, pues muchos otros intentos de sofisticación similar o menor caen en saco roto.
Hubo otra gran innovación introducida en Zork, no en la versión original sino en las comerciales: implementar el motor de juego como una máquina virtual. Los microordenadores de la época se caracterizan por ser totalmente incompatibles entre sí, por lo que portar un juego a múltiples máquinas era un proceso caro y laborioso (y, en el caso de juegos con componentes gráficos, aún más complicado dadas las diferentes capacidades de cada máquina). Infocom abordó el problema con la invención de un ordenador virtual, una máquina inexistente pero lo bastante sencilla como para poder escribir «emuladores» sobre estos micros. Una máquina, además, especialmente diseñada para ejecutar aventuras de texto y que permitiría almacenarlas de forma compacta. La Z-Machine definió a la compañía y sirvió de base a todos sus juegos futuros.
El mundo del micro
Adventure era un programa de 300K de tamaño, y Zork (Dungeon en su concepción original) llegaba al megabyte. Ordenadores de esta capacidad, a finales de los 70, sólo estaban al alcance de grandes compañías e instituciones.
Pero ocurre que, a la vez, estaba arrancando el mercado de ordenadores domésticos, con máquinas mucho más modestas. Con ellas, nacieron un número de compañías dispuestas a explotar la nueva oportunidad con aventuras de texto de menor tamaño.
Uno de los primeros fue Scott Adams, con la mencionada compañía Adventure International y su Adventureland, inspirado en Adventure pero muchísimo más simplificado. El programa original estaba escrito en BASIC para el microordenador TRS-80 y separaba de forma precisa el parser de la base de datos que contenía las localidades, objetos y mensajes del juego. Poco después, el mismo «motor» repetiría presencia en su segundo juego, Pirate Adventure, diseñado por Alexis, su esposa (quien, por cierto, no se había tomado a bien la enfermiza obsesión de Scott durante el desarrollo de Adventureland y llegó a esconderle los discos de trabajo por casa o meterlos en el horno; felizmente acabó aceptando su ilusión e incluso colaborando con él).
Como ocurría en Adventure, las aventuras iniciales de Scott solo comprenden comandos de una o dos palabras, pero aquí el vocabulario era más pequeño (¡unas 100 palabras!), y los textos, dadas las limitaciones de memoria, terriblemente escuetos. Para paliar un poco el efecto, los objetos interactivos se muestran en mayúsculas en pantalla para diferenciarlos. Lejos quedarían la resolución de ambigüedades, las preguntas interactivas, o el sofisticado sistema de movimiento, por no hablar de las ricas descripciones inspiradas en la experiencia espeleológica de Crowther.
Este esquema (aventuras simples, algunas escritas incluso en BASIC, con un parser parco) era de desarrollo relativamente sencillo, así que pronto veríamos docenas de aventuras cortas disponibles comercialmente (con productos como la saga de Artic en Spectrum), y listados type-in en las revistas.
La historia de la aventura de texto, y de los parsers en estos microordenadores es la historia de un precario equilibrio entre el consumo de memoria, las características disponibles (como gráficos), y la complejidad de la aventura y del propio parser. Algunos, como Scott, optaron por juegos simples de poco tamaño, que podían portarse a los ordenadores más modestos, incluso con solo 16K de RAM disponible. Pero también hubo ejemplos sofisticados. Infocom se introdujo en este mundo portando su completo parser, pero aún así tuvo que dividir Zork en tres partes, sin gráficos, y sólo para microordenadores relativamente potentes, basados en disco para poder cargar secciones de su base de datos a medida que fueran requeridas.
Mención aparte merece The Hobbit, de Melbourne House. A pesar de desarrollarse inicialmente para ZX Spectrum y estar limitado a los 48K de memoria de la máquina, su parser bebe mucho más de Infocom que de las modestas aventuras que hemos mencionado. The Hobbit comprende frases complejas con preposiciones, artículos y adjetivos, soporta la desambiguación interactiva de frases, permite omitir el sujeto y lo rellena con el objeto más lógico, comprende el IT (aunque no lo sustituye por el último objeto mencionado por la aventura, sino por el último objeto escrito por el jugador) e, incluso, soporta listas de objetos y secuencias de múltiples instrucciones hasta el punto de ofrecer la capacidad de ordenar a otros personajes series de comandos que éstos ejecutarán uno a uno (capacidad incluso utilizada en el diseño de la aventura como parte de la solución de alguno de los puzles).
Parsers comerciales
Infocom y Adventure International fueron pioneros en la reutilización de código entre aventuras, pero la idea de comercializar el parser en sí, como herramienta independiente para que usuarios independientes pudiesen desarrollar sus propias aventuras, llegó desde fuera.
Graeme Yeandle fue pionero de esta práctica con The Quill. Graeme se introdujo en el mundo de las aventuras de texto con títulos de Spectrum como la saga de Artic y, confiado en su capacidad de desarrollo, ofreció sus servicios a diferentes compañías para escribir una aventura. Gilsoft, ubicada en su ciudad natal, accedió, y de esta colaboración surgió su aventura de texto Timeline. Yeandle optó por separar el motor de juego y su base de datos, una idea que ya había encontrado eco en varias revistas. El engorro de tener que modificar manualmente dichos datos le llevó a escribir una herramienta de edición. La idea de comercializar esta herramienta surgió poco después.
The Quill utiliza una estructura de comandos de una/dos palabras, como las primeras aventuras de Scott Adams. Ni siquiera reconoce palabras por su tipo ni distingue verbos de nombres. Sólo examina las cuatro primeras letras de cada palabra, por lo que no distingue entre NORTH y NORTHEAST.
Su base de datos incluye la capacidad de ejecutar acciones dinámicas mediante un ingenioso sistema de condiciones y acciones (condacts), que asocia órdenes escritas por el usuario (recordemos, de una o dos palabras) con listas de acciones a ejecutar condicionalmente. Por ejemplo, ante las palabras TAKE APPLE, la tabla de eventos podría listar las acciones GET 2 y OK, que se encargan respectivamente de mover el objeto número 2 al inventario del jugador y mostrar el mensaje «Ok» en pantalla, dando por válida la orden.
Este sistema es, en realidad, un lenguaje de programación muy simplificado. Cuenta con un número de flags: valores numéricos que pueden modificarse y comprobarse como condición, y acciones diseñadas para implementar las instrucciones más habituales de las aventuras. Tan sencillo es el lenguaje, que no soporta conceptos como bucles, saltos, variables o tablas de datos.
Esta sencillez impone serias limitaciones, pero a su vez pone la creación de aventuras de texto al alcance de aquellos que no tendrían la disposición o el tiempo de aprender un lenguaje de programación completo como 
podría ser el BASIC. Graeme se había curtido en aventuras simples que no habían sido construidas sobre sistemas genéricos de objetos y propiedades, lejos de The Hobbit o las aventuras de Infocom. Hay que reconocer cierta genialidad en identificar que un sistema tan sencillo como esas flags son suficientes para implementar gran variedad de problemas y puzles.
Con el tiempo, aparecerían productos más sofisticados. GAC (Graphic Adventure Creator) permitía comandos más completos, secuencias de múltiples órdenes, diferenciaría nombres y verbos, reconocía adverbios y adjetivos, y listas de objetos (interpretadas como órdenes independientes). Su base de datos contenía un sistema de condiciones y acciones muy similar al de The Quill, pero con una sintaxis más parecida a un lenguaje de programación. Y, por supuesto, el PAWS (Professional Adventure Writing System), sucesor directo de The Quill, soportaba diferentes tipos de palabra como adjetivos y adverbios, frases entrecomilladas, secuencias de múltiples órdenes, y el uso de IT. Al margen de las mejoras en la interpretación de frases (el «dialecto» que el parser comprende), los tres operarían bajo principios similares.
Lo que vino después
Como hemos visto, a mediados de los 80 la aventura de texto había seguido dos líneas de progreso diferenciadas. Por una parte teníamos la herencia de los mainframes, con sistemas de objetos sofisticados, lenguajes de programación complejos, y un parser ambicioso. Por otra parte, el mundo del microordenador había crecido a partir de aventuras simples con comandos de dos palabras, respuestas predefinidas y una implementación sencilla alrededor de una base de datos y algún sistema de scripting. Ambas líneas convergían. Los PAWSlike mejoraban sus capacidades acercándose al Zork original, mientras las aventuras de Infocom se consolidaron acerca de su particular dialecto, apostando por la familiaridad de los usuarios con un conjunto de capacidades establecidas, sin tratar de aumentar la capacidad comprensiva del parser. La aparición del lenguaje open source Inform fundó una larga tradición de aventuras creadas sobre la Z-Machine, que mantienen el mismo parser pero crecen en tamaño y complejidad. Con el tiempo aparecerían mejoras mecánicas y literarias, pero la interfaz y lo que entiende se mantendría estable. Inform 7 introdujo un exótico lenguaje de programación experimental basado en el lenguaje natural, pero las aventuras creadas con el mismo son indistinguibles de las originales de Infocom.
Comercialmente, las compañías por aparecer diseñaron parsers basados en el mercado existente, sin innovaciones notables: desarrolladoras como Level 9 o Magnetic Scrolls buscarían competir en otros aspectos. Representantes de Legend Entertainment, la última compañía comercial del mercado anglosajón, afirmarían que su parser era «tan bueno como el de Infocom». El informese se había convertido en el objetivo final y suficiente para los aventureros.
En el terreno de los PAWSlike, DAAD no introdujo apenas mejoras en la fórmula, concentrándose en la portabilidad entre un amplio abanico de ordenadores. En el ámbito de habla hispana, los años 90 y los 2000 vieron surgir diversas herramientas, pero pocos títulos hechos con ellas, con parsers como NMP, SINTAC o CAECHO?. Este último era particularmente interesante al ofrecer un lenguaje estructurado completo, cuando el resto implementaron sistemas de condacts similares a PAWS o Quill, aunque incrementando enormemente la cantidad de acciones y condiciones disponibles.
El mago tras la cortina
¿Cómo funciona un parser? Interpretar el significado de cualquier frase arbitraria en lenguaje natural siempre ha sido un problema inabarcable computacionalmente, incluso hoy en día, bien entrados en la era de las IAs. Y es que sería arriesgado afirmar que un modelo de IA comprende realmente nuestras palabras. Estos modelos rellenan sus «respuestas» encadenando palabras que saben, por su experiencia analizando miles de millones de casos, que es muy probable que aparezcan en su posición y el texto mantenga su coherencia. Sin embargo, no existe una interpretación racional del significado del texto por detrás, así que la solidez de la integración de estas tecnologías en un mundo simulado entraña serias dificultades. Pero esa también es otra historia, y será contada en otra ocasión.
El caso es que, a pesar de que interpretar el significado de un texto libre es un problema difícil, las aventuras de texto lo vienen hacendo hasta cierto punto desde hace décadas. Veamos…
Ya desde el principio, podemos hablar de dos acercamientos diferentes al problema de entender lo que dice un texto. Una idea consiste en construir una lista prefijada de comandos (con sintaxis predefinida) y comprender sólo lo que encaja dentro de esa lista. Este parser resulta entonces similar a una shell. Ante una entrada inesperada (una palabra desconocida, un artículo fuera de sitio, una frase sin verbo) un sistema así devolvería un error. Esta fue la aproximación escogida por la mayoría de aventuras en sus orígenes, incluyendo Adventure y Zork. Aunque el parser de Zork es mucho más sofisticado y soporta frases muy complejas y diferentes, todas las posibilidades están programadas de antemano (obviamente, con numerosas concesiones por comodidad, como poder omitir artículos), y ante una palabra desconocida, en general el parser aborta su acción. Al final, ambos juegos utilizan, en cierto modo, un sistema de comandos.
La segunda opción es aceptar cualquier cosa y tratar de inferir el significado del texto a partir de la presencia de palabras clave predefinidas, ignorando (en general) la estructura general del texto así como cualquier elemento auxiliar desconocido para el parser. Así funcionaban los programas de chat primitivos tipo Eliza, que a veces lograban sorprender al interlocutor con respuestas inesperadamente acertadas, aunque los espejismos y juegos malabares tienen un límite. El programa erraba a menudo (por ejemplo, una frase y su negación podían generar la misma respuesta, al contener ambas la palabra clave de interés) y a menudo respondía con respuestas vagas o redundantes intentando ocultar que, en realidad, no entendía nada de lo que se le decía.
Evidentemente un sistema tipo Eliza sin más no es válido para una aventura, pues la pobre comprensión real de la intención del jugador llevaría a muchas respuestas erróneas. Casi nunca ha sido usado en aventuras de texto, con algunas honrosas excepciones, como por ejemplo la serie de aventuras de Robert Lafore que, bajo el sello Interactive Fiction, publicó Adventure International entre 1979 y 1982. Estas aventuras carecen de un parser tradicional y combinan la elección de opciones a través de menús con secciones de diálogo donde el jugador escribe libremente y un buscador de patrones tipo Eliza determina la respuesta que recibe.
Lo que sí se hizo popular, especialmente en el mundo micro, es una aproximación híbrida al problema, donde el parser espera recibir en la frase de entrada ciertas palabras clave obligatoriamente (como mínimo un verbo), pero por otra parte ignora cualquier palabra desconocida. Tan limitada era la memoria disponible, que poder ignorar directamente palabras comunes como artículos o preposiciones, reduciendo así la memoria ocupada por el vocabulario, era una opción muy interesante.
Así funcionan en general los PAWSlike, incluso los más modernos. Esta práctica de ignorar directamente cualquier palabra desconocida tiene curiosas consecuencias. Imaginemos un juego donde la descripción de una localidad menciona una mesa, pero tal objeto no existe como tal y MESA no está en el vocabulario. En este caso el parser no distingue entre EXAMINAR LA MESA y EXAMINAR, pero responder al primero con un «¿examinar qué?» no sería deseable. Para paliarlo, es práctica habitual en estos parsers responder a instrucciones donde falta información asumiendo que el usuario puede haber mencionado un objeto accesorio no interactivo. En otras palabras, la respuesta suele ser vaga, algo del estilo «no ves nada especial» o similar.
Una vez el parser ha examinado las palabras escritas por el usuario y determinado su naturaleza según el vocabulario del programa, el siguiente eslabón de la cadena es enlazar esta combinación de palabras con una acción concreta. La forma obvia de hacer esto es prever y codificar de antemano todas las posibles acciones que el jugador pueda hacer, y preparar una respuesta acorde a cada una de ellas. Por ejemplo, asociando el comando ESPERAR a una respuesta tipo «el tiempo pasa». Una aventura muy simple, entonces, puede entenderse como una lista de textos de respuesta que el autor ha escrito de antemano para cada comando reconocido.
Pero claro, la misma acción a veces devolverá resultados diferentes. ENTRAR no debería devolver el mismo resultado si la puerta está cerrada que si está abierta, así que el parser necesitará saber más sobre el estado del mundo y de los objetos que lo componen. Como mínimo, habrán variables almacenadas que contengan la información mínima que pueda hacer variar alguna respuesta (¿está la puerta abierta o cerrada?). Algunas acciones modificarán estas variables, haciendo realidad la interactividad del mundo.
Veamos un ejemplo. ¿Cómo responde una aventura al comando DEJAR BOLSA? Una opción es codificar DEJAR como una acción general que puede aplicarse sobre cualquier objeto: si el objeto en cuestión está en el inventario del jugador, lo movemos a la localidad actual e imprimimos un mensaje afirmativo. La alternativa sería codificar la acción DEJAR BOLSA explícitamente para desplazar un objeto concreto (la bolsa) a la localidad actual, si se encuentra en el inventario. Si hacemos esto último, ¡habrá que escribir una acción para cada objeto manipulable en el juego! The Quill, en sus primeras versiones, no incluía facilidades para coger o dejar objetos de forma genérica, así que esta era la única opción.
Simulación y emergencia
Este concepto de hacer que el parser interprete órdenes genéricas puede llegar mucho más lejos. Imaginemos que tenemos en nuestra aventura un objeto frágil, un huevo, y queremos que se rompa cuando el jugador lo deja caer sin más, como parte de un puzle de nuestra invención. La forma habitual de implementar esto, en cualquier tipo de parser, es incluir una excepción, una respuesta específica al comando DEJAR HUEVO que lo rompe en lugar de dejarlo en el suelo. Pero, ¡atención! Algo así también puede implementarse de forma más genérica. Pongamos que en nuestro mundo de juego existen un número de objetos que tienen la cualidad «frágil». Cuando un objeto frágil se deja caer, resulta destruído y se pierde. Esta forma de construir el mundo, común en parsers que derivan más hacia un lenguaje de programación complejo como Inform o TADS, tiene ciertas ventajas. Una vez añadido el soporte para esta cualidad, implementar el puzle del huevo es tan sencillo como marcar el objeto como frágil. A partir de entonces, es posible crear tantos objetos frágiles como queramos, de manera que todos ellos se rompan al dejarse caer, y también es fácil reutilizar esta funcionalidad en otras aventuras futuras.
Los inconvenientes de hacerlo todo genérico no son fáciles de ver, y tienen que ver con la complejidad creciente del mundo simulado y la forma en la que un número elevado de propiedades interactúan entre ellas. Por ejemplo, si en nuestra aventura tenemos tesoros y queremos que la puntuación del jugador aumente cuando dejamos un tesoro en cierta localidad, debemos andar con cuidado porque estas dos acciones pueden colisionar entre ellas de forma indeseada. La complejidad de implementar la aventura, y la posibilidad de encontrar colisiones indeseadas entre capacidades genéricas, aumenta cuantas más propiedades genéricas se simulan, y es más fácil introducir bugs no deseados.
La programación genérica tiene una consecuencia interesante. Se dice que un juego cuenta con un diseño «emergente» cuando el carácter genérico de sus mecánicas permiten a los jugadores experimentar con combinaciones imprevistas y obtener resultados no prediseñados, pero igualmente válidos en el mundo de juego. El ejemplo clásico es el de montar pilas de cajas en juegos que implementan un motor de física para utilizarlas como soporte o escalera y salvar así obstáculos que en un principio vedarían nuestro acceso a ciertas localizaciones.
Al margen de los peligros y complejidades de una aproximación genérica al desarrollo de aventuras, hay que recalcar que hasta los parsers más simples implementan, en su mínima expresión, conceptos generales. Un ejemplo simple es otorgar a cada objeto del juego un peso, introduciendo puzles que obligan al jugador a cargar con un peso limitado, o actuando en función del peso total de objetos en el inventario o en otro sitio.
¿Qué depara el futuro?
La realidad que vivimos es que el progreso del parser alcanzó, estrictamente, su máxima expresión con Infocom y no hemos observado avances sustanciales desde entonces, al menos dentro del mundo de la aventura de texto.
Es posible que el género deba evolucionar primero en otros aspectos. La simulación siempre ha sido una dirección de progreso interesante. Los intentos por desarrollar hacia el diseño emergente y la implementación de reglas generales en lugar de respuestas específicas son tan antiguos como el Hobbit de Melbourne House, y tuvieron una fuerte influencia en TADS e Inform. Sin embargo, la complejidad extra introduce problemas de escalabilidad y dificultades a la hora de implementar narrativas y puzles. En mi humilde opinión, a la hora de la verdad la sensación de jugar estas aventuras difiere poco de las desarrolladas por métodos mucho más simples.
También puede ocurrir que, simplemente, el progreso del parser no sea necesario. Hace al menos 30 años que las limitaciones de memoria no son un factor, y puede darse el caso de que, contando con un vocabulario gigantesco y tablas de respuestas realmente extensas, la sensación de juego mejorase radicalmente. Algunas compañías de finales de los 80 y principios de los 90 estuvieron en posición de trabajar en esta línea, pero quizá la inversión estaba mejor empleada en otros factores. El público jugador de aventuras ya estaba, a fin de cuentas, familiarizado con las limitaciones y diseño de los parsers existentes.
Y, por supuesto, pasada la era comercial, la aventura de parser es un nicho. Lejos quedan los tiempos en los que un juego de Adventure International lideraba las listas de ventas del VIC-20. Un aspecto fundamental de la afición presente es el fuerte componente retro, más interesado en revivir viejas memorias que en tentar al futuro. Existe un sector más vanguardista, pero suele enfocar su interés en aspectos narrativos por encima de la jugabilidad o interactividad.
Y sin embargo, el futuro de la interacción de texto es sin duda brillante, pues nadie duda que tendremos, muy pronto, experiencias similares a una aventura de texto dirigidas por una IA. El uso de estas IAs como directores de juego para partidas de rol o, básicamente, para jugar aventuras de texto, es inminente. Ya hay varias ofertas comerciales (por ahora resultan decepcionantes, pero con la velocidad a la que progresa esta tecnología, pueden ser viables en meses). Sin embargo, incluso ahí hay preguntas abiertas. El punto hasta el cual se podrá restringir la IA para que se limite a escenarios, puzles y narrativas predefinidas sin que eso entorpezca su acción o limite la fiabilidad de sus respuestas resulta una incógnita hoy en día. Pero es un futuro que llegará.
Mientras tanto, siempre nos queda volver a Zork, una de las pocas aventuras que reconoce preguntas directas, y decirle: ¿dónde sigue la aventura?
Por José Luis Cebrián ( @jlcebrian)
