Glk
Hay una tremenda cantidad de lenguajes para ACs, cada uno con su propia
máquina virtual, y aún más están siendo creados. Hay también un buen
montón de plataformas ahí afuera, y nuevo hardware y nuevos sistemas
operativos están apareciendo también a un ritmo nada desdeñable. Esto
ha traido un problema que debería sonar bastante familiar si has leído
los apartados previos. Cada vez que un nuevo sistema para ACs aparece,
es necesario escribir un intérprete para cada una de las plataformas
en las que se quieran jugar los juegos creados con ese sistema:
Windows, DOS, Mac, Acorn, Amiga, BeOS, Unix, y muchos muchos más. Y
cada vez que una nueva plataforma en la que podrían jugarse ACs
aparece -digamos que la gente quiere jugarlas desde dentro de un MUD,
o a través de un teléfono móvil conectado a Internet- la nueva
plataforma necesita un intérprete Z, y un íntérprete TADS, y un
intérprete Hugo, y un intérprete ALAN, y así seguiríamos.
Más aún, una buena parte del trabajo necesario para escribir un
intérprete, es esfuerzo malgastado. Mira, un intérprete tiene que
hacer dos cosas más o menos independientes: procesar datos - parsear,
mantener el estado de los objetos del juego, cosas así - y
entrada/salida (abreviado como E/S, o en inglés I/O), que se ocupa de
cómo debe mostrarse el texto que el programa ordena imprimir. Y salvo
pocas excepciones (de las que nos ocuparemos en breve), la parte de
proceso de datos no se preocupa de la parte de E/S. Simplemente la
dirá a la parte de E/S "eh, imprime estas tres frases" (bueno, se lo
dirá en código máquina), pero a la parte que procesa datos no le
importa si esas frases aparecen con un tipo de letra caprichoso en una
ventana gráfica con barras de scroll. De igual forma, la parte que se
ocupa de la E/S sólo debe preocuparse de mostrar el material que le
han ordenado mostrar. No le interesan los algoritmos por los que la
parte de proceso de datos ha llegado a su decisión de qué
imprimir. Sólo se interesa de imprimirlo realmente. Esto significa
que, mientras que la parte de proceso de datos de todos los
intérpretes de máquina Z será prácticamente idéntica, la parte de E/S
variará drásticamente: el Frotz de DOS, diseñado para ser usado en un
entorno en el que no hay posibilidad de varios tipos de letra,
requiere unas rutinas para imprimir texto muy diferentes de las de
WinFrotz. Y de forma similar, mientras que la parte de proceso de
datos de diferentes intérpretes para Mac será bastante diferente -
TADS e Inform y AGT y otros, simplemente no manejan los datos de la
misma forma - en cambio la parte del intérprete que maneja el "look
and feel", es decir la E/S, será muy similar, con independencia de
qué máquina virtual esté siendo usada. Pero ya que hay que crear cada
posible par, el trabajo acaba siendo repetido muchas veces.
Permitanme presentarles Glk. Glk es un intento de hacer todo este
trabajo más eficiente, separando las dos funciones del intérprete de
ACs tradicional. Lo hace definiendo unas cuantas rutinas, escritas en
el lenguaje C de programación, y recopiladas en la librería Glk. Los
programadores familiarizados con el C pueden escribir
aplicaciones Glk, que hagan sus cálculos y proceso de datos,
y generen sus resultados en una forma que Glk pueda comprender, y
librerías Glk (también llamadas "implementaciones de Glk")
que adapten las funciones Glk para una plataforma concreta: WinGlk,
XGkl, MacGlk, etc. El escritor de intérpretes ve reducido su trabajo a
juntar las aplicaciones con las librerías.
Si no está aún clara la utilidad de todo esto, miralo de esta otra
forma. Digamos que en lugar de intentar llevar los lenguajes de ACs a
las diferentes plataformas, lo que estamos intentando construir es un
sistema ferroviario para llevar gente desde varios lugares de la costa
oeste de los Estados Unidos - Seattle, Portland, San Francisco, Los
Angeles, etc. - a ciudades en la costa este: Boston, Nueva York,
Filadelfia, Washington, etc. El método anterior a Glk de líneas
directas significaría construir vías desde Seattle a Boston, de
Seattle a Nueva York, de Seattle a Filadelfia, etc. y después de
Portland a Boston, de Portland a Nueva York, etc. Si quisieramos
añadir una nueva ciudad de partida, sería necesario construir un
conjunto nuevo de vias: San Diego a Boston, San Diego a Nueva York,
etc. Y lo mismo ocurriría si añadimos un destino nuevo: tendríamos que
construir de Seattle a Miami, de Portland a Miami, de San Francisco a
Miami, etc. Lo que hace Glk es crear un centro. En nuestro ejemplo,
digamos que es Omaha (Nebraska). Así, en lugar de construir vías
directamente desde cada origen a cada destino, construimos de Seattle
a Omaha, Portland a Omaha, San Franciso a Omaha, etc. y después de
Omaha a Boston, Omaha a Nueva York, etc. Esto reduce drásticamente el
número de vías que tenemos que construir. Y si aparece una nueva
ciudad de origen, sólo tenemos que construir una vía: San Diego a
Omaha. ¿Un nuevo destino? Una vía: Omaha a Miami. Y la gente que venga
desde San Diego, hará transbordo en Omaha y llegará a cualquier
destino, y la gente que venga desde cualquier origen en la costa
oeste, puede hacer transbordo en Omaha y llegar a Miami.
Así que pongamos que alguien escribe un nuevo lenguaje para hacer ACs,
llamado ABC. No se necesita escribir intérpretes para ABC-Windows,
ABC-Mac, ABC-Palm; en lugar de esto, simplemente escribe un intérprete
ABC-Glk y todo el mundo en todas las plataformas para las que existan
librerías Glk, podrán jugar juegos ABC. De forma análoga, si Toaster
Technologias construyera el Cybertoaster, basta escribir una librería
Glk-para-Cybertoaster, y ya tenemos instantáneamente al Cybertoaster
preparado para jugar juegos Inform, TADS, Hugo o juegos de cualquier
otro sistema para el cual exista un intérprete basado en Glk. Todo lo
que los usuarios de Cybertoaster necesitan hacer es enlazar esos
intérpretes con las librerías Glk para Cybertoaster.
Puede que te preguntes: los intérpretes basados en Glk, toman la
salida de las máquinas virtuales y la conviertene en algo que Glk
pueda comprender. ¿Hay alguna máquina virtual cuya salida ya esté
preparada para Glk sin requerir conversiones? La respuesta: puedes
apostar que sí. Eso es Glulx.
