 |  |  | Una introducción a Glulx Inform |
Una introducción a Glulx Inform
Las aventuras conversacionales, o AC (Interactive Fiction en inglés),
son un tipo de relato en el cual
el oyente (lector) es un participante activo. Una aventura
conversacional (generalmente llamada un "juego", incluso si no hay
nada similar a un juego en ella) comienza típicamente presentando al
jugador un breve escenario ("Aqui hay un estrecho callejón sin
salida, con muros que se elevan opresivamente altos en tres
direcciones. Una puerta de metal liso se enfrenta a tí al este, cerca
del final del callejón. Está firmemente cerrada.") Entonces, el
jugador decide qué quiere que el personaje a quien encarna en el juego
haga - abandonar el callejón, quizás, o llamar a la puerta. Se entera
de lo que pasa, dice qué hacer después, y así sigue este toma y daca
hasta que el juego llega a su fin (a menudo con una horrible muerte
del personaje). ¡Es divertido!
Si el autor estuviera realmente ahí, como el master de un juego de
rol, el jugador podría decirle qué quiere hacer, y el autor podría
pensar sobre ello un rato, quizás lanzando algunos dados, y
responderle cuál fue el resultado. Pero si los cientos de personas que
visitan regularmente el IF-archive (depósito de aventuras inglesas)
necesitaran que los autores fueran a sus casas para poder jugar los
juegos, seguro que tendrían para una larga espera. Por suerte, el
medio no es tan dependiente de un contacto cara a cara. En lugar de
ello, el autor codifica el juego de antemano - cada descripción de
cada localidad, cada posible respuesta a cada petición del jugador -
en un fichero. Los jugadores copian el fichero a su propio ordenador,
leen el texto que fluye en sus pantallas, esperan a que aparezca un
prompt (normalmente un ">"), escriben su orden, leen la
respuesta, obtienen otro prompt, escriben otra orden, etcétera.
El apartado siguiente detalla el proceso por el cual una AC va desde
la cabeza del autor hasta la pantalla del computador del jugador.
Tras jugar algunas aventuras, mucha gente decide que le gustaría
intentar escribir la suya propia. El primer paso es traducir tus
ideas en código fuente. El código fuente es un conjunto de
instrucciones, escritas en un lenguaje de computador, que definen
cosas como qué objetos hay en el juego, qué hacen, cómo reaccionan si
el jugador intenta hacerles cosas, etc. Hay muchos lenguajes de
computador diseñados específicamente para escribir aventuras
(de ahora en adelante ACs), como TADS,
Hugo o ALAN. Pero el lenguaje para IF más ampliamente usado, en el
momento de escribir esto, es el llamado Inform.
Inform es un lenguaje de bastante alto nivel, lo que significa que
está más cerca de la forma en que los humanos procesamos la
información ("Si el jugador intenta alejar la galletita del loro,
el loro debe morderle") de la forma en la que lo hacen los
computadores ("001001101110010"). Un fragmento del código Inform
que representaría el ejemplo del loro sería este:
Object loro "el loro Polly"
with nombre 'loro' 'pajaro' 'polly',
antes [;
DejarSalir:
if (uno == galletita)
"Polly te muerde la mano cuando intentas mangarle la
galletita ~¡Groook! ¡Esa maano!~ declara.";
],
has animado propio;
|
Incluso si no sabes Inform, puedes hacerte una buena idea de lo que
hace el código anterior sólo mirándolo. Ciertamente es mucho más
fácil convertir las ideas a esta forma, que directamente a una
secuencia de números. (Y si quieres aprender Inform - lo que
necesitarás hacer antes de entrar en la sección dos - un buen sitio
para comenzar es la , mantenida por el
creador del lenguaje, Graham Nelson.)
Algunas piezas de un juego Inform, serán específicas para ese juego
(no todos los juegos tienen un loro, por ejemplo). Pero un buen
número de piezas serán bastante similares de un juego a otro. Por
ejemplo, prácticamente todas las ACs necesitan un parser, la
parte del juego que lee complejas frases como "PON TODO EXCEPTO LA
GALLETITA EN LA JAULA DEL LORO", y lo rompe en una lista de
acciones más sencilla de manejar para el programa ("ejeuta la acción
Insertar con los objetos loro, alpiste y periodico, pero no con el
objeto galletita, y con la jaula como destino"). Escribir un
parser desde cero es extremadamente complejo - la mayoría de los
parsers "cocidos en casa" (y unos pocos que suelen aparecer en cada
competición de ACs) son terribles. También es una pérdida de tiempo:
si una persona ha codificado un parser realmente bueno, y tú quieres
que tu parser haga prácticamente lo mismo ¿por qué no puedes usar el
código de esa otra persona? Respuesta: sí puedes. El parser, así como
al sistema de manejo de objetos y prácticamente cada uno de los
elementos típicos de las ACs que reaparecen de un juego a otro, están
incluidos en la librería InformATE.
Una librería es un grupo de ficheros, escritos en el mismo lenguaje
en que tú estás programando, que pueden ser incluídos en tu programa
para realizar algunas funciones, sin que tengas que codificarlas por
tí mismo. En inform, la cosa es tan fácil como escribir:
Include "EParser";
Include "Acciones";
Include "Gramatica";
|
Programa los objetos y rutinas específicos de tu juego, añade esas
tres líneas en los lugares adecuados, y tu programa está completo.
Sin embargo, ningún ordenador puede ejecutar código fuente Inform
directamente: el código fuente debe ser traducido a código máquina.
En el corazón de cada ordenador, está la unidad central de proceso, o
CPU. El trabajo de la CPU es ejecutar instrucciones, que le llegan en
código máquina, que simplemente es una secuencia de dígitos binarios.
Por ejemplo, "1101011010010001" nota1.html puede
significar "vete a la posición de memoria número 106 y súmale 1 al
número que encuentres allí". ¿Cómo sabe la CPU lo que significa esa
secuencia de dígitos? Porque los chips de silicio de los que está
hecha, están construidos de tal forma que al enviarles una secuencia
de impulsos que representan ese número, producen el efecto
deseado. ¿Cómo sabes tú, el programador, lo que esa secuencia de
dígitos significa? A menos que estés trabajando con un lenguaje de muy
bajo nivel, no necesitas saberlo. Para eso están los compiladores.
Un compilador es un programa que toma el código fuente escrito en un
lenguaje de alto nivel, asequible a las personas (como Inform), y lo
convierte en código máquina. Sin embargo, aquí aparece un problema.
Cada tipo de máquina es diferente. Una secuencia de bits que para una
máquina (como un Pentium) signfique "suma estos dos números", puede
significar algo completamente diferente - o no significar nada de
nada - para un computador Apple. Una solución a este problema sería
coger tu código fuente, buscar una máquina que ejecute Windows, y
compilarlo para obtener un fichero ejecutable para Windows - esto es,
un programa que puede ejecutarse por si solo, como cualquier otro
programa que puedas usar. Después, buscar un Mac y compilar un
ejecutable para el Mac. Después pillar una Palm Pilot y compilar
una versión para ella. Y después otra para el Acorn, y otra para el
Amiga, y después otra cada vez que aparezca un nuevo tipo de
ordenador... es fácil ver por qué esta no es realmente la mejor
solución, si quieres que gente con diferentes tipos de máquina puedan
jugar tu juego.
En cambio, la solución usada por la comunidad de ACs, es compilar sus
programas para máquinas virtuales. En lugar de compilar para el Mac, o
el DOS, los usuarios de TADS compilan para la "máquina virtual
TADS". Los usuarios de Hugo compilan para la "máquina virtual
Hugo", y los usuarios de Inform compilan para la "máquina Z". Los
documentos con la especificación de la máquina Z son como los
documentos que especifican cualquier otra máquina real: explican a los
creadores de compiladores cómo es el código máquina que la máquina Z
es capaz de comprender. La única diferencia es que nunca se han
construido realmente máquinas Z: ninguna fábrica conecta chipZ de
ZiliZio a una placa baZe, y no encontrarás portatileZ en venta en las
tiendas de ordenadores. Pero aún así, puedes compilar programas para
ella.
Así que has tenido una idea para un juego, has aprendido Inform, has
escrito el código fuente, y lo has compilado. Lo que tienes ahora es
un fichero con el juego, diseñado para ser ejecutado en una máquina
que no existe. ¿Dónde está la gracia? Sigue leyendo.
Puede que te sea familiar el concepto de emulador. Un
emulador es un programa que te permite ejecutar programas compilados
para un ordenador diferente del tuyo, mediante la traducción del
código máquina extranjero en el código máquina nativo de tu ordenador.
Muchos usuarios de Mac tienen un emulador llamado "Virtual PC" que
les permite ejecutar Microsoft Windows, por ejemplo. Las ACs (sobre
todo las inglesas) hacen un intenso uso de este concepto: cada máquina
virtual, tiene una serie de intérpretes asociados, que son
programas que permiten que los ficheros compilados para esa máquina
virtual puedan ser jugados en un tipo concreto de ordenador. MaxTADS,
por ejemplo, es un intérprete que toma los juegos hechos para la
máquina virtual TADS y los ejecuta en el Macintosh. WinFrotz es un
intérprete que toma juegos en código para la máquina Z y los ejecuta
en máquinas Windows. La máquina Z en particular tiene intérpretes para
un asombroso número de plataformas, incluyendo la GameBoy (!). Así
que, aunque algunos juegos para máquina Z se distribuyan en forma de
ejecutables (usando un programa como JZEXE que junta el fichero del
juego con un intérprete específico para una plataforma), la forma más
habitual de jugar ACs es bajarse por separado el fichero con el juego
que quieres jugar, y el intérprete que puede ejecutarlo en tu máquina,
arrancar el intérprete, cargar el juego en él, y empezar a jugar. Y
así es como el juego llega desde la cabeza del autor a tu pantalla.
Puede que te preguntes ¿pero el paso intermedio de especificar una
máquina virtual, no ocasiona simplemente un trabajo extra? Cierto,
significa que no tendrás que compilar tu juego para docenas de
plataformas diferentes - pero tienes que compilar intérpretes para
todas estas plataformas diferentes, de modo que ¿es esto más
eficiente? La respuesta es: no lo es, si sólo se va a escribir un
juego para la máquina virtual en cuestión. Pero tan pronto como
escribas un segundo juego, resulta obvio que usar una máquina virtual
merece la pena: compilas tu nuevo juego para la máquina virtual, y el
fichero resultante puede ser jugado en todos los intérpretes que ya
habían sido creados. Así que si haces un juego con Inform, no
necesitas molestarte en compilarlo para Windows, para Macs, para
Acorns y para GameBoys - simplemente lo compilas para la máquina Z, y
toda la gente con Windows y Mac y Acorn y GameBoy pueden
instantáneamente jugarlo, a través de sus intérpretes escritos hace
años.
Y hasta hace poco, esto habría sido el final del cuento. Pero
recientemente, ha sido introducido un nuevo elemento para ahorrar
esfuerzos, que recibió el muy denigrado nombre de Glk.
| | | Una introducción a Glulx Inform |