Uno dei tratti distintivi degli hacker è il non considerare mai un programma davvero completamente e definitivamente finito; ci sono sempre aggiunte da fare, angoli da smussare. E di certo Adventure, per quanto impressionante, lasciava ampio spazio ai miglioramenti. Dobbiamo poi aggiungere che Adventure arrivò al MIT attraverso Don Woods dell'AI Lab della Stanford, forse l'unico corso di informatica della nazione che aveva la statura per potersi confrontare alla lontana con quello del MIT. Gli studenti del MIT erano fieramente orgogliosi della propria Università. Anche se la Stanford aveva prodotto per prima un gioco d'avventura, il Dynamic Modeling Group del MIT avrebbe potuto quantomeno farlo meglio. E certo non nuoceva alla causa il fatto che il Project MAC e il Laboratory for Computer Science (per non parlare dello stesso Dynamic Modeling Group) avessero donato loro degli ottimi strumenti con cui affrontare il problema.

 

Adventure era stata implementato in FORTRAN, un linguaggio non particolarmente adatto alla creazione di un'avventura testuale. E infatti il FORTRAN non poteva nemmeno gestire nativamente le stringhe di lunghezza variabile, lasciando a Crowther e Woods il compito di arrangiare qualche soluzione, come del resto dovettero fare anche con molti altri problemi. Come sappiamo, entrambi erano programmatori molto talentuosi e ci riuscirono al meglio. E così gli hacker del Dynamic Modeling Group (la cui opinione del FORTRAN era solo un gradino superiore a quella che avevano del BASIC) non vedevano l'ora di progettare il proprio gioco d'avventura con il proprio linguaggio, l'MDL. Non solo l'MDL (essendo un linguaggio progettato, almeno in parte, per la ricerca nel campo dell'Intelligenza Artificiale) poteva vantare capacità di gestione di stringhe relativamente robuste, ma offriva anche la possibilità di definire dei nuovi “data type” complessi, adatti per compiti specifici, e la possibilità di inserire direttamente in tali strutture dei pezzi di codice. Lasciatemi provare a spiegarvi perché tutto questo era così importante.

 

Inizieremo con la stanza di apertura di Zork, il gioco che alla fine fu prodotto dal Dynamic Modeling Group in risposta ad Adventure. La descrizione di tale stanza al giocatore [nella nostra traduzione italiana di Zork I; ndAncient] appare così:

 

 

 

Questo è il codice sorgente originale in MDL che descrive la stanza:

 

 

Praticamente tutto ciò che il programma deve sapere di questa stanza è incapsulato qui dentro in modo ordinato. Analizziamolo, linea per linea. Il tag “ROOM” [stanza] all'inizio definisce questa struttura come una stanza, chiamata brevemente “WHOUS” [abbreviazione di "West of House", cioè "A Ovest della Casa", ndAncient]. La linea di testo seguente è la descrizione della stanza che il giocatore vede quando vi entra la prima volta o quando digita “GUARDA”. “West of House” è invece il nome completo della stanza, quello che appare come titolo della descrizione della stanza e nella linea di stato in cima allo schermo, ogni volta che il giocatore si trova in questa stanza. Poi abbiamo un elenco di uscite dalla stanza, andare a nord porta il giocatore a “North of House,” a sud lo porta a “South of House”, a ovest in una di diverse stanze che compongono la “Foresta”. Cercare di andare a est produrrà invece uno speciale messaggio di fallimento, che riferirà al giocatore di non essere in possesso di una chiave per aprire la porta, anziché il generico: “Non puoi andare in quella direzione”. Subito dopo abbiamo gli oggetti che si trovano nella stanza all'inizio del gioco: la porta frontale, la cassetta delle lettere, e il tappetino di benvenuto. Quindi una serie di "flag" definisce altre proprietà della stanza: che è asciutta anziché invasa dall'acqua, che è illuminata anche se il giocatore non ha con sé una lanterna accesa; che (essendo all'aperto) non ha pareti; che è “sacred” [“sacra”] (il che significa che il ladro -un personaggio che vaga in giro, infastidendo il giocatore in modo non dissimile dai nani e dal pirata di Adventure- non può venire qui). E, alla fine, l'ultima linea associa questa stanza alla "white house" o, per essere più precisi, la associa a una parte della “regione casa” della geografia del gioco.

 

Ogni oggetto e ogni personaggio del gioco è definito da un simile blocco, che spiega quasi tutto ciò che il gioco deve sapere al riguardo. Va aggiunto anche che le abilità e le capacità speciali di oggetti e personaggi sono descritti come parti di essi, utilizzando dei collegamenti a delle sezioni speciali del codice, create appositamente. Per questo una volta che l'impalcatura del codice alla base di tutto questo fu creata (cosa che, ovviamente, non era affatto banale), aggiungere nuovo contenuto a Zork era prevalentemente una questione di aggiungere più stanze, più oggetti, e più personaggi, senza bisogno ogni volta di rituffarsi nell'"engine" che muoveva il tutto; solo le capacità speciali degli oggetti e dei personaggi dovevano essere programmate da zero e collegate nei punti giusti. Componendo il mondo da una raccolta di “oggetti” integrati, gli hacker del Dynamic Modeling Group stavano inconsapevolmente dirigendosi verso un nuovo paradigma nella programmazione, che sarebbe giunto alla ribalta dell'informatica solo alcuni anni dopo: la programmazione orientata agli oggetti, in cui i programmi non sono rigorosamente divisi nel codice che li esegue e nei dati che esso manipola, ma sono piuttosto costruiti dall'interazione di oggetti semi-autonomi che contengono il proprio codice e i propri dati. Un tempo considerata praticamente la soluzione a ogni problema (forse persino alla fame nel mondo), oggigiorno in certe aree, ci sono delle resistenze (probabilmente giustificate) alla imposizione, applicata a prescindere, della teoria della programmazione orientata agli oggetti operata da certi linguaggi, come il Java. Sia come sia, la programmazione orientata agli oggetti resta praticamente la soluzione ideale nella creazione delle avventure testuali. Per mostrarvi cosa intendo, guardiamo all'alternativa, illustrata da Adventure (scritto in FORTRAN, un linguaggio altamente NON orientato agli oggetti).

 

Ad ogni stanza di Adventure è assegnato un numero da 1 (la location iniziale, naturalmente all'esterno di un piccolo edificio di mattoni) fino a 140 (stavolta, meno naturalmente, un vicolo cieco in un labirinto). Per trovare la descrizione completa della stanza (quella che viene mostrata al giocatore quanto vi entra per la prima volta o quando la GUARDA) il programma scava nella prima tabella di un file esterno di dati, confrontando il numero della stanza alle rispettive voci.

 

 

Un'altra tabella mostra invece la descrizione breve che viene visualizzata quando si entra in una stanza già visitata:

 

 

E ora viene il bello. Un'altra tabella ancora ci dice cosa ci aspetta in ogni direzione cardinale.

 

 

La prima linea di cui sopra ci dice che quando siamo in stanza 1, possiamo andare in stanza 2 digitando una delle tre voci di un'altra tabella ancora; in questo caso: “ROAD o HILL” (voce 2); “WEST” or “W” (voce 44); or “UPWAR” (infatti le parole vengono confrontate sulla base dei primi 5 caratteri soltanto [in questo caso la parola completa sarebbe UPWARD, formata da 6 caratteri, che significa SU; ndAncient], “UP,” “ABOVE,” or “ASCEN” (voce 29). In modo del tutto analogo, le definizioni degli oggetti sono sparpagliate su più tabelle all'interno del data file. Quindi, anche se Adventure tenta almeno in parte di astrarre il suo "engine" dai dati che compongono il suo mondo (collocando questi ultimi in un "data file" esterno), modificare il mondo stesso è un procedimento rognoso e foriero di errori, che consiste nell'editare più tabelle criptiche. I primi "engine" per avventure testuali sui microcomputer, come quelle di Scott Adams, funzionano tutti in questo modo. E anche se era comunque possibile sviluppare dei tool che alleviassero il fardello di modificare a mano i "data file", il sistema di Zork basato sull'MDL è flessibile e programmabile in un modo ben superiore a quello di questi sistemi: non essendo possibile inserire del codice all'interno degli oggetti del mondo di gioco, creare oggetti non standard in Adventure o in un gioco di Scott Adams richiedeva generalmente di andare a modificare il codice dell'"engine"; non proprio il massimo.

 

Per questo l'MDL era semplicemente migliore per scrivere un'avventura testuale che fosse capace di rappresentare limpidamente un mondo vasto, in un modo che fosse anche leggibile e facilmente mantenibile. Era quasi come se l'MDL fosse stato progettato a questo scopo. Ed effettivamente, se avete usato un linguaggio di programmazione di IF più moderno (come Inform 6), sareste rimasti sorpresi da quanto poco sia cambiato l'approccio nella definizione del mondo rispetto ai giorni dell'MDL di Zork. (Inform 7, uno degli ultimi, e migliori, tool per lo sviluppo di IF si è allontanato dal modello della programmazione orientata agli oggetti in favore di un approccio basato su regole più leggibili -se non addirittura più “letterarie”-. Basti dire che i meriti e gli svantaggi dell'approccio di Inform 7 sono un argomento troppo complesso per essere affrontato in questa sede. Forse ne riparleremo fra 20 anni, quando finalmente il Digital Antiquarian si occuperà dell'anno 2006...)

 

E gli hacker del Dynamic Modeling Group avevano ancora un altro asso nella loro manica.

 

Il MIT aveva all'attivo importanti ricerche sulla comprensione del linguaggio naturale nel computer, che risalivano almeno fino a Joseph Weizenbaum e al suo sistema ELIZA del 1966. E se quel programma alla fin fine era poco più di un elaborato trucco da salotto, esso però ispirò altri e più rigorosi tentativi di far parlare a un programma un buon inglese. È estremamente noto quello che fra il 1968 e il 1970 fu sviluppato da Terry Winograd sotto il nome di SHRDLU, che simulava un modello di mondo composto di blocchi. L'utente poteva chiedere al programma di manipolare questo mondo, spostando i blocchi di posto in posto, impilandoli, e così via, il tutto limitandosi a digitare le sue richieste con delle semplici frasi imperative in lingua inglese. Era perfino possibile porre delle semplici domande al computer, per sapere ad esempio quale blocco fosse collocato in una determinata posizione. Piuttosto sopravvalutato all'epoca (come gran parte della ricerca sull'intelligenza artificiale), quasi fosse un passo decisivo verso HAL, SHRDLU riuscì comunque a dimostrare che, almeno all'interno di un dominio molto ristretto, è possibile per un programma parlare e “comprendere” realmente un significativo sottoinsieme della lingua inglese. Partendo dalla tradizione di SHRDLU, gli hacker del Dynamic Modeling Group crearono un parser per avventure testuali che era oggettivamente il primo mai creato a essere degno del termine. E se Adventure se la cavava con un semplice riconoscimento delle parole (stratagemma reso palese dal fatto che “LAMPADA PRENDI” funziona esattamente come “PRENDI LAMPADA”), Zork comprendeva davvero non solo il verbo e il complemento oggetto, ma anche le preposizioni, il complemento di termine, le congiunzioni, la punteggiatura, e perfino gli articoli. A dare un contributo essenziale al raggiungimento di tale obbiettivo fu nuovamente l'MDL che (essendo un linguaggio ideato pensando alla ricerca sull'IA) aveva delle straordinarie capacità di manipolazione delle stringhe. Il parser che riuscirono a ideare si rivelò una creazione mirabile, che si sarebbe contraddistinta per molti anni a venire (un'eternità, allora come ora, nel mondo dell'informatica). Ma ora sto andando troppo avanti.

 

La strada che condurrà a Zork iniziò nel Maggio del 1977, quando Dave Lebling creò un semplicissimo parser e un semplicissimo "engine" piuttosto simile a quello di Adventure, dal quale Marc Blank e Tim Anderson crearono il loro primo gioco di quattro stanze, come prototipo. A quel punto Lebling si prese una vacanza di due settimane, mentre Blank, Anderson, e Bruce Daniels "hackeravano" come pazzi, creando la struttura base di Zork così come la conosciamo ancora oggi. Il nome stesso era una parola priva di senso presa dal gergo parlato al MIT; una parola che si usava nelle situazioni di tensione al posto di un altra più scurrile: “Zorka quel maledetto codice!”, quando una linea di codice non ne voleva sapere di funzionare, e cose del genere. Ogni programmatore ha qualche parola tipo questa che usa per programmi, variabili, funzioni, e così via, quando sta semplicemente facendo esperimenti e non ha tempo di inventarsi un nome migliore (negli ultimi 25 anni il mio personale “go-to placeholder” è stata la parola “fuzzy”, per ragioni troppo imbarazzanti e stravaganti per spiegarle qui). Nel caso di Zork, però, un nome vero e proprio tardava a venir fuori. E così il gioco restò Zork per i primi sei mesi della sua esistenza.

 

Quando Lebling tornò dalla vacanza per riprendere a lavorare al gioco, c'erano già delle solide basi. Tutto il design era modulare; questo significava (come dimostrato sopra) che era facile aggiungere altre stanze, altri oggetti, altri enigmi, ma anche che ogni parte della sottostante tecnologia poteva essere facilmente rimossa, migliorata, e inserita di nuovo. Il parser in particolare migliorò gradualmente da uno a due parole (“intelligente quasi quanto quello di Adventure”), fino a diventare la creazione allo stato dell'arte che era alla fine; il tutto prevalentemente grazie all'impegno di Blank, che ne divenne ossessionato fino a produrne “40 o 50” iterazioni.

 

Negli anni successivi la Infocom avrebbe sviluppato una storia e una mitologia, complesse ma anche comiche, intorno a Zork e al suo “Grande Impero Sotterraneo”, ma in questi primissimi giorni di sviluppo gli autori erano interessati al mondo di gioco solo come luogo in cui ambientare delle scene accattivanti ma anche ridicolmente eterogenee, e -ovviamente- degli enigmi da risolvere, nel solco della tradizione inaugurata da Don Woods con Adventure. E infatti il mondo di Zork rende omaggio ad Adventure quasi al punto da sembrare inizialmente un suo remake. Come Adventure, si inizia all'aria aperta, accanto ad una piccola casa; come in Adventure c'è una piccola area esterna da esplorare, ma il succo del gioco si svolge sottoterra; come Adventure lo scopo è raccogliere tesori e riportarli dentro la casa, che serve quindi da base delle nostre operazioni; ecc. ecc. Solo andando molto avanti nel gioco, Zork diverge davvero da questo schema e assume una sua distinta personalità, con location fantasiose ed enigmi molto più intricati, resi possibili dallo stupefacente parser. Ovviamente tutte queste parti furono ideate in seguito, quando il team di sviluppo aveva più esperienza e quando il parser era ormai molto migliore di quello iniziale. Personalmente darò uno sguardo approfondito a Zork nella sua versione per microcomputer, piuttosto che nella sua incarnazione per PDP-10, ma se siete interessati a saperne di più sull'implementazione originale senza capo né coda, vi invito a dare un'occhiata all'approfondito play-through di Jason Dyer.

 

Come Adventure, anche Zork girava su un DEC PDP-10. A differenza di Adventure però, girava sotto il sistema operativo che ospitava anche l’ambiente MDL, l’Incompatible Timesharing System (così chiamato, con un po’ di sano humour da hacker, in sarcastica risposta ad un precedente Compatible Timesharing System; anche qui però -scusate se insisto- vi rimando a Hackers di Levy per un eccezionale racconto delle sue origini). L’Incompatible Timesharing System era sostanzialmente unico del MIT, l’istituzione che lo aveva sviluppato. E aveva un elemento di estrema originalità: in uno stravagante (ma qualcuno lo chiamerebbe folle) tributo alla tradizione degli hacker di totale apertura e trasparenza, non aveva password; anzi, non aveva nessun tipo di sicurezza. Proprio chiunque poteva loggarsi e fare ciò che voleva. Questo creò una specie di community di coloro che gli hacker del MIT chiamavano “gente a caso dalla rete”: persone che non avevano niente a che fare con il MIT, ma che godevano, da qualche parte, di un accesso a un computer connesso ad ARPANET e che si fermavano per rovistare nel sistema, solo per vedere cosa stessero facendo quei folli hacker del MIT. La macchina del Dynamic Modeling Group aveva raccolto intorno a sé una community considerevole di gente a caso, grazie a un precedente gioco di quiz. Non ci volle molto prima che scoprissero Zork (anche se non era mai stato annunciato ufficialmente) e che si imbarcassero nell’avventura. Ben presto questo gioco in sviluppo si guadagnò una certa reputazione su ARPANET. Proprio a vantaggio di questa community di giocatori, gli sviluppatori iniziarono a collocare una copia dell’U.S. News and Dungeon Report in una delle prime stanze, che elencava tutti gli ultimi cambiamenti e le ultime aggiunte a questo mondo virtuale che la gente stava esplorando. La gente a caso dalla rete, insieme ad altri utenti più “legittimati” di base al MIT (fra cui anche John McCarthy, il padre dell’intelligenza artificiale), servirono da team allargato di beta-test; gli implementatori potevano vedere quello che queste persone provavano a fare, per non dire ciò di cui si lamentavano, e modificavano il gioco di conseguenza. In particolare, molti dei miglioramenti al parser furono senza dubbio incentivati da questo processo; chiunque abbia mai sottoposto una propria avventura testuale a un beta-test, sa bene che non si può semplicemente prevedere a priori gli infiniti modi in cui le persone proveranno a esprimere certe cose.  

 

La crescente popolarità di Zork sollevò delle inevitabili preoccupazioni sull’eccessivo carico generato da questi giocatori sul sistema PDP-10 del Dynamic Modeling Group, che a conti fatti era finanziato dal Dipartimento della Difesa e che quindi -teoricamente- sarebbe dovuto servire per vincere la Guerra Fredda. Al tempo stesso c’erano altri che chiedevano una copia del gioco, per poterla installare sulle proprie macchine. Anche se sviluppato e utilizzato principalmente sotto l’Incompatible Timesharing System, esisteva però una versione dell’ambiente MDL che girava su un altro sistema operativo per PDP-10, il TOPS-20, pubblicato dalla DEC per la prima volta nel 1976 e pubblicizzato come una versione più avanzata e user-friendly del TOPS-10. A differenza dell’Incompatible Timesharing System, il TOPS-20 era assai diffuso al di fuori del MIT. Gli hacker del Dynamic Modeling Group modificarono quindi Zork quanto bastava per farlo girare sul TOPS-20 e iniziarono a distribuirlo a tutti gli amministratori che gliene chiedevano una copia. Alla fine dell’anno tutte le macchine della nazione ospitavano Zork ed era stata perfino predisposta una "mailing list" per informare i vari amministratori delle espansioni e dei miglioramenti che venivano apportati.

 

Gli hacker del Dynamic Modeling Group erano generosi, ma non quanto lo era stato Don Woods con Adventure. Distribuirono Zork solo come file criptati, che erano eseguibili in un ambiente MDL ma che non erano leggibili (né modificabili) a livello di codice sorgente. Arrivarono perfino a modificare il proprio sistema di sviluppo Incompatible Timesharing System, celebre per la sua mancanza di sicurezza, aggiungendo una protezione esclusivamente alla cartella che conteneva il codice sorgente di Zork. Tuttavia gli hacker non si smentiscono mai e ben presto uno della DEC aveva già penetrato il velo. Dalla “History of Zork” della Infocom:

 

 

Riguardo a queste “altre conseguenze”:

 

Ad un certo punto, alla fine del 1977, gli hacker del Dynamic Modeling Group decisero che la loro creazione aveva davvero, davvero bisogno di un nome vero e proprio.  Lebling suggerì Dungeon, che non emozionò nessuno (Lebling incluso), ma a nessuno veniva in mente un’alternativa migliore. E così si optò per Dungeon. Ciò avvenne poco prima della breccia nella sicurezza appena descritta; per questo il gioco recuperato da quell’hacker della DEC non si chiamava Zork, bensì Dungeon. Poco dopo, al MIT giunsero voci di possibili azioni legali da parte (provate a indovinare) della TSR, il publisher di Dungeons and Dragons e di un gioco da tavolo di esplorazione di dungeon chiamato semplicemente Dungeon! La TSR era sempre particolarmente zelante nel querelare e gli avvocati del MIT, consultati dagli hacker del Dynamic Modeling Group, erano unanimemente concordi nel ritenere che la TSR non avesse nessun appiglio legale a cui aggrapparsi. Tuttavia, piuttosto che venir risucchiati in una controversia su un nome che oltretutto non piaceva a nessuno, decisero di ritornare al ben più memorabile Zork. E così, all’inizio del 1978, Dungeon tornò di nuovo a essere Zork, per poi mantenere quel nome per sempre.

 

Quasi per sempre. Vi ricordate quel codice sorgente che “Ted” aveva sottratto al MIT? Ebbene, arrivò nelle mani di un altro hacker del DEC, un certo Robert Supnik, che convertì il tutto per FORTRAN, più diffuso e portabile (seppur intrinsecamente e infinitamente meno adatto alle avventure testuali); fu uno sforzo erculeo che stupì perfino gli hacker del Dynamic Modeling Group. Poiché il gioco contenuto nel codice sorgente in MDL a cui aveva accesso si chiamava Dungeon, questa nuova versione rimase Dungeon. Inizialmente Supnik eseguì il porting con l'intenzione di portare Dungeon a girare su un DEC PDP-11 (che, a discapito di quanto sembra indicare il nome, non era un successore del PDP-10, ma piuttosto una macchina fisicamente più piccola, meno potente, e meno costosa). Con il codice sorgente in FORTRAN di Supnik libero di essere distribuito, tuttavia, il salto dal PDP-11 ad altre architetture fu assai breve. Perciò, in questi primi anni, il Dungeon di Supnik con ogni probabilità era più ampiamente distribuito, e quindi era anche più giocato, dello Zork del Dynamic Modeling Group. E quando arrivarono dei PC in grado di supportarlo, Dungeon sbarcò inevitabilmente anche su questi. E così alla fine degli anni ‘80 la situazione era incomprensibile per chi non conosceva tutta questa storia: c’era questo gioco gratuito, chiamato Dungeon, che era stranamente simile ai giochi commerciali ufficiali di Zork, che a loro volta erano molto simili a quest’altro gioco, Adventure, che all’epoca era disponibile in dozzine di versioni gratuite e commerciali. Ad oggi il Dungeon di Supnik è disponibile insieme al codice sorgente (finalmente libero) della versione per PDP-10 di Zork.

 

Tornando al MIT, lo sviluppo dello Zork vero e proprio continuò per tutto il 1978, seppur a un ritmo decrescente. Se si escludono delle correzioni minori di bug, che sarebbero proseguite per un paio di anni ancora, gli ultimi pezzi di Zork furono aggiunti nel Febbraio del 1979. A quel punto il gioco aveva assunto proporzioni davvero enormi: 191 stanze, 211 oggetti, un vocabolario di 908 parole con 71 verbi diversi (senza considerare i loro sinonimi). Gli implementatori avevano praticamente finito le idee per nuovi enigmi ed erano comprensibilmente esausti per il grande sforzo, e (qualora queste giustificazioni non fossero sufficienti) avevano completamente riempito l'unico MB circa di memoria che un programma MDL poteva utilizzare. E così accantonarono Zork e si spostarono su altri progetti.

 

La storia sarebbe potuta tranquillamente finire lì, con Zork che passa alla storia come un altro esempio, eccezionalmente significativo, di avventura testuale fiorita sulle macchine istituzionali negli anni successivi alla pubblicazione di Adventure; insomma, Zork come fosse un altro Mystery Mansion, Stuga (AGGIORNAMENTO: non proprio; leggete il commento di Jason Dyer [“Se vogliamo essere precisi, Stuga non può essere annoverato nel gruppo degli altri due titoli; fu distribuito commercialmente, e vendette piuttosto bene, e può essere definito lo Zork della Svezia”; ndAncient]), o HAUNT. Però non andò così, grazie ad Al Vezza, il direttore (dall’anima tutt’altro che hacker) del Dynamic Modeling Group, che qualche mese più tardi decise che il momento era giusto per entrare coi suoi collaboratori nella nuova, promettente frontiera dei microcomputer, avviando una software house. Non poteva però certo immaginare dove avrebbe portato questa sua decisione.