Glk

C'è una grande quantità di linguaggi per IF, ognuno con la propria virtual machine, e molti altri se ne stanno scrivendo. Ci sono anche un sacco di piattaforme differenti là fuori, e nuovi computer e sistemi operativi stanno vedendo la luce. Questo ha portato ad un problema che dovrebbe suonarvi familiare se avete letto le sezioni precedenti. Ogni volta che arriva un nuovo sistema per la programmazione di IF, le persone hanno la necessità di scrivere un interprete per ogni piattaforma su cui vogliono essere in grado di far girare i giochi del vostro sistema: Windows, DOS, Mac, Acorn, Amiga, BeOS, Unix, e moltissime altre. Ed ogni volta che una piattaforma su cui sia possibile giocare con l'IF arriva -- ad esempio delle persone che voglio giocare su un MUD, o su un telefono cellulare abilitato ad Internet -- le nuove piattaforme hanno bisogno di un interprete Z-code ed un interprete TADS ed un interprete Hugo ed un interprete Alan e così via.

Inoltre molto del lavoro che riguarda la scrittura di un interprete è fatica sprecata. Vedete, un interprete deve fare due cose più o meno indipendenti: il trattamento dei dati -- interpretazione dei comandi (parsing), tenere traccia degli oggetti nel gioco, e cose così -- e l'input/output (abbreviato in I/O per semplicità), che ha a che fare con l'esattezza con cui le cose il programma dice di stampare vengono visualizzate. E con qualche limitata eccezione (di cui ci occuperemo tra breve), la parte di trattamento dati non si preoccupa di ciò che fa la parte di I/O. Dice alla porzione di I/O l'equivalente in codice macchina di "Scrivi queste tre frasi", ma alla parte di trattamento dati non interessa se queste frasi appaiono in testo piano su una shell Unix o se appaiono con un bel font in una finestra grafica con delle barre di scorrimento. La stessa cosa per la parte di I/O, che si preoccupa solo di mostrare le cose che gli è stato detto di mostrare. Non si preoccupa di tutti gli algoritmi che la parte di trattamento dati ha usato per arrivare alla decisione di cosa stampare. Si preoccupa solamente di fare la visualizzazione. Questo significa che mentre la porzione di trattamento dati di tutti gli interpreti Z-machine è vicina ad essere identica, la porzione di I/O differisce drasticamente: DOS Frotz, progettato per essere usato in un ambiente senza supporto per font differenti, richiede delle routine di stampa del testo molto differenti da quelle usate in WinFrotz. Allo stesso modo, mentre la parte di trattamento dei dati dei vari interpreti Mac può essere piuttosto diversa -- TADS e Inform e AGT ed altri semplicemente non macinano i numeri allo stesso modo -- la parte dell'interprete che ha a che fare con il look and feel, l'I/O, può essere più o meno la stessa indipendentemente dalla VM che si sta usando. Ma visto che ogni potenziale coppia deve essere messa insieme, il lavoro finisce per essere rifatto tutte le volte.

Inizia Glk. Glk è il tentativo di rendere tutto questo processo più efficiente separando le due funzioni degli interpreti IF tradizionali. Lo fà definendo una serie di routine, scritte nel linguaggio per computer C, e raccogliendole nella libreria Glk. I programmatori che hanno familiarità con il C possono scrivere delle applicazioni Glk (Glk applications), che fanno il trattamento dei dati e restituiscono i risultati in un formato che Glk può capire -- GlkInform, GlkTADS, e così via -- e delle librerie Glk (Glk libraries, chiamate anche "implementazioni Glk", Glk implementations), che adattano le funzioni Glk ad una specifica piattaforma: WinGlk, XGlk, MacGlk, ecc. Lo scrittore di interpreti non deve far altro che unire tra di loro applicazioni e librerie.

Se non è chiaro come questa cosa sia utile, immaginiamola in questo modo. Diciamo che invece di cercare di adattare differenti linguaggi per IF a differenti piattaforme, stiamo cercando di costruire un sistema ferroviario che trasporti le persone da alcune città della costa ovest degli Stati Uniti -- Seattle, Portland, San Francisco, Los Angeles, ecc. -- alle città della costa est: Boston, New York, Philadelphia, Washington, ed altre. Il sistema pre-Glk di collegamenti diretti avrebbe comportato la costruzione di rotaie da Seattle a Boston, da Seattle a New York, da Seattle a Philadelphia, ecc., poi da Portland a Boston, da Portland a New York, ecc. Se fosse venuto fuori un nuovo punto di partenza, avremmo dovuto costruire un intero nuovo insieme di rotaie: da San Diego a Boston, da San Diego a New York, ecc. E lo stesso sarebbe accaduto per ogni nuova destinazione: avremmo dovuto costruire da Seattle a Miami, da Portland a Miami, da San Francisco a Miami, e così via. Glk stabilisce un centro, un concentratore. Nella nostra analogia diciamo che sia Omaha nel Nebraska. Così, invece di costruire rotaie direttamente dai punti di partenza alle destinazioni, noi costruiamo da Seattle a Omaha, da Portland a Omaha, da San Francisco a Omaha, ecc. E poi costruiamo da Omaha a Boston, da Omaha a New York, ecc. Questo riduce drasticamente il numero di rotaie che dobbiamo costruire. E se viene fuori un nuovo punto di partenza, dobbiamo costruire solo una rotaia: da San Diego a Omaha. Una nuova destinazione? Una rotaia: da Omaha a Miami. E le persone che arrivano da San Diego possono cambiare treno a Omaha per andare ad ogni altra destinazione, e le persone che arrivano da qualunque parte della costa ovest possono cambiare treno a Omaha ed andare a Miami.

Così diciamo che qualcuno scrive un nuovo linguaggio per IF chiamato ABC. Non ha bisogno di scrivere degli interpreti ABC-per-Windows, ABC-per-Mac, ABC-per-Palm; invece scrive semplicemente un interprete ABC-per-Glk, e le persone di tutte le piattaforme con le librerie Glk possono giocare ai giochi ABC. Allo stesso modo se la Toastent Technologies rilascia il Cybertoaster, tutto quello che deve essere scritto è una libreria Glk-per-Cybertoaster, ed il Cybertoaster è istantaneamente pronto per usare i giochi Inform, TADS, Hugo, o giochi che usino qualunque altro sistema per il quale ci sia una applicazione Glk -- tutto quello di cui hanno bisogno gli utenti Cybertoaster è qualcuno che metta insieme le librerie e le applicazioni per creare degli interpreti.

Potreste chiedervi: le applicazioni Glk ricevono dalle virtual machine e riformattano il loro output così che Glk possa capirlo. Esistono virtual machine il cui output sia già adatto all'uso con Glk? La risposta: ci potete scommettere. Questo è Glulx.