Bentrovati prodi avventurieri! Lo so, siete già tutti in trincea pronti per il tragico cenone della Vigilia, ma non è il momento di gozzovigliare... scintillanti tesori vi attendono nei perigliosi labirinti del magico Regno Sotterraneo di Zork. E a guidarci sarà, come sempre, il sapiente Antiquario Digitale.  Armatevi di coraggio compagni, entriamo finalmente nel vivo dell'esplorazione di Zork!   Ma prima la lista degli articoli del ciclo Infocom:   – Le Radici della Infocom – Zork sul PDP-10 – La Nascita della Infocom – Lo ZIL e la Z-Machine – Come Vendettero Zork – Giochi col Parser – Esplorando Zork, Parte 1 – Esplorando Zork, Parte 2 – Esplorando Zork, Parte 3 – Infocom: Come Cavarsela da Soli – Zork II, Parte 1 – Zork II, Parte 2 – Lo Zork User Group – Zork III, Parte 1 – Zork III, Parte 2   Posate la forchetta e afferrate la lanterna... inizia la discesa!   Festuceto

Oggi andremo al sodo del Grande Impero Sotterraneo di Zork, mostrato nella mappa qui sotto.

 

 

 

Mentre il Dynamic Modeling Group completava gli ultimi ritocchi su Zork e finalmente se ne congedava, al MIT si iniziava ad avvertire la fine di un’era. Marc Blank stava per laurearsi in medicina e stava per iniziare il suo internato a Pittsburgh, cosa che avrebbe reso impossibile continuare la sua opera di "hackeraggio" intensivo al MIT, nonostante le sue capacità apparentemente sovrumane. Altri ancora stavano ultimando i loro programmi di laurea al MIT, oppure (a forza di attardarsi all'università) stavano esaurendo le giustificazioni per ritardare ancora l'inizio delle loro “vere” carriere, con dei veri stipendi. Stava insomma per iniziare un esodo generazionale, non solo dal Dynamic Modeling Group ma proprio dal Laboratory for Computer e dall'AI Lab del MIT in generale. Le pressioni del mondo esterno avevano infine fatto breccia nell'utopia hacker del MIT, pressioni che negli anni immediatamente successivi, l'avrebbero cambiato per sempre. Gran parte di questo cambiamento originò però dall'invenzione dei microcomputer.

 

La maggior parte di coloro che frequentava gli ambienti dell’hacking istituzionale, tipo il MIT, all’inizio non era particolarmente entusiasta di quella che veniva chiamata la rivoluzione dei PC. Il che non deve sorprenderci. Quei primi microcomputer erano delle macchine con limiti assurdi. Gli “hacker casalinghi” che le comprarono (spesso costruendosele da soli) erano eccitati dalla semplice idea di avere accesso illimitato a un qualcosa che, almeno lontanamente, rispondesse alla definizione di “computer”. Invece i privilegiati che occupavano un posto in un’istituzione tipo il MIT, non solo avevano accesso illimitato (o quasi) ai suoi sistemi, ma tali sistemi erano anche abbastanza potenti da poter farci davvero qualcosa. Che fascino poteva avere un Altair o anche un TRS-80 in confronto ai sofisticati sistemi operativi come il TOPS-10 o il TOPS-20 o l’Incompatible Timesharing System, con linguaggi di programmazione ben strutturati come il LISP e l’MDL, con ricerche nei campi dell’intelligenza artificiale e del linguaggio naturale, e che avevano perfino dei giochi in rete come Maze, Trivia [il gioco a quiz di cui abbiamo già parlato; ndAncient] e, ovviamente, Zork? Il mondo dei microcomputer ai loro occhi doveva sembrare irrimediabilmente privo di cultura e di educazione, privo di quella vera tradizione di hacking che ormai affondava le sue radici in oltre venti anni di esperienza. Come si poteva pensare di scrivere dei programmi complessi usando il BASIC? Quando molti degli hacker istituzionali si degnarono di accorgersi delle nuove macchine, fu con atteggiamento sprezzante; Stu Galley decretò che il motto non ufficiale del Dynamic Modeling Group diventasse: “Noi odiamo i micro!”. Consideravano i microcomputer come poco più che dei giocattoli, che del resto era grossomodo la reazione avuta da gran parte della popolazione.

 

Già nella primavera del 1979, tuttavia, stava diventando via via più chiaro, a tutti coloro che volevano vederlo, che quelle piccole macchine avevano i loro usi. WordStar, il primo word processor per microcomputer davvero utilizzabile, era disponibile già da un anno, e stava portando sempre più macchine basate sul CP/M negli uffici e perfino negli studi degli scrittori. Alla West Coast Computer Faire di quel maggio, Dan Bricklin mostrò pubblicamente per la prima volta VisiCalc, il primo foglio elettronico del mondo, che avrebbe rivoluzionato la contabilità e la progettazione finanziaria. “Come hai potuto fare senza?”, chiedeva la prima pubblicità che ne anticipava la pubblicazione, con un'iperbole che (fu subito chiaro) si sarebbe rivelata assai preveggente; qualche anno più tardi, milioni di persone si chiederanno esattamente la stessa cosa. A differenza di WordStar e perfino di AdventureLand di Scott Adams, VisiCalc non era una versione più limitata di un concept sviluppato sui computer istituzionali e poi implementato sull’hardware dei microcomputer. Esso era stato concepito, progettato, e implementato interamente sull’Apple II; la prima idea autenticamente nuova nata su un microcomputer, il simbolo di un imminente cambio della guardia.

 

I microcomputer portarono molti, molti più utenti nel mondo dei computer di quanti non ce ne fossero mai stati. Il che portò molti più investimenti privati nel settore, guidati da una nuova realtà: con questa roba si potevano fare soldi veri. E questa consapevolezza portò dei grandi cambiamenti al MIT e nelle altre istituzioni di hacking “puro”. È (tristemente) famosa la spaccatura in due che avvenne durante l’inverno e la primavera del 1979 all’interno dell’AI Lab in seguito alla disputa fra Richard Greenblatt (che sostanzialmente all’interno del MIT era il decano della tradizionale etica degli hacker) e un più pragmatico amministratore di nome Russell Noftsker. Insieme a un piccolo team di altri hacker e di ingegneri informatici, Greenblatt aveva sviluppato un piccolo computer a utente singolo, una sorta di “boutique micro”, il primo di quelle che sarebbero poi state chiamate “workstation”, ottimizzato per far girare il LISP. Credendo che il progetto potesse avere un vero potenziale commerciale, Noftsker avvicinò Greenblatt con la proposta di creare una società che lo producesse. Greenblatt inizialmente si disse d’accordo, ma ben presto si dimostrò (almeno dal punto di vista di Noftsker)  indisponibile a sacrificare anche il più piccolo dei principi degli hacker dinanzi alla realtà degli affari. I due si lasciarono in malo modo, con Noftsker che portò con sé gran parte dell’AI Lab per implementare il concept originale di Greenblatt attraverso la Symbolics, Inc. Sentendosi disilluso e tradito, alla fine anche Greenblatt se ne andò, per formare una sua società, di minor successo, la Lisp Machines.

 

Non è che nessuno del MIT, prima di allora, avesse mai fondato una società, né che il commercio non si sia mai mischiato con l’idealismo di quegli hacker. Gli stessi fondatori della DEC, Ken Olson e Harlan Anderson, erano stati due allievi del MIT, che nella metà degli anni ‘50 si erano occupati, come studenti, del progetto di base di quella che sarebbe poi diventata la prima macchina della DEC, il PDP-1. Da allora il MIT ha sempre mantenuto una relazione privilegiata con la DEC, testando il loro hardware e, cosa ancora più importante, sviluppando del software estremamente essenziale per le macchine della società; una relazione che era (a seconda di come la si guarda) o una miniera d’oro per gli hacker che dava loro continuo accesso alle ultime tecnologie, oppure un brillante piano della DEC per mettere al proprio servizio alcune delle menti migliori dell’informatica di quella generazione senza pagare loro un centesimo. Nonostante questo, ciò che stava accadendo al MIT nel 1979 sembrava qualitativamente diverso. Questi hacker erano quasi tutti programmatori di software, dopotutto, e il mercato dei microcomputer stava dimostrando che adesso era possibile vendere autonomamente il software, in opere preconfezionate, proprio come avviene con un disco o con un libro. Un uomo saggio una volta ha detto: “il denaro cambia tutto”. Molti hacker del MIT erano eccitati all’idea del possibile lucro, come risulta evidente dal fatto che i più scelsero di seguire Noftsker fuori dall’università, piuttosto che l’idealistico Greenblatt. Solo una manciata di loro, come Marvin Minsky e il cocciutissimo Richard Stallman, restarono indietro e continuarono a seguire fedelmente la vecchia etica degli hacker.

 

I fondatori della Infocom non erano fra gli irriducibili. Come si intuisce già dal loro gesto di aggiungere una protezione (oggi suona quasi ridicolo scriverlo) all’Incompatible Timesharing System per proteggere il codice sorgente del loro Zork (una cosa che avrebbe fatto innalzare le urla di protesta di Stallman almeno su due diversi livelli), la loro devozione all’etica degli hacker era quantomeno negoziabile. E infatti Al Vezza e il Dynamic Modeling Group stavano rimuginando su possibili applicazioni commerciali per le creazioni del gruppo già dal 1976. Alla fine del semestre primaverile del 1979, tuttavia, sembrò palese che se questa versione del Dynamic Modeling Group (sul punto di sparpagliarsi ai proverbiali quattro venti) voleva fare qualcosa di commerciale, quello era il momento giusto per iniziare. E del resto molti altri al MIT stavano facendo la stessa identica cosa, no? Non aveva senso restare da soli in un laboratorio vuoto, come accadde letteralmente al povero Richard Stallman. In ogni caso, era così che Al Vezza vedeva la situazione e i colleghi da lui diretti (ansiosi di restare connessi e tutt’altro che contrari all’idea di aumentare i propri modesti stipendi universitari) accettarono di buon grado.

 

E così la Infocom venne ufficialmente fondata il 22 Giugno 1979, con dieci azionisti. Fra questi c’erano tre dei quattro hacker che avevano lavorato a Zork:  Tim Anderson, Dave Lebling, e Marc Blank (appena diventato dottore e già pendolare dal suo internato medico a Pittsburgh). Insieme a loro c’erano anche altri cinque membri (attuali o passati) del Dynamic Modeling Group: Mike Broos, Scott Cutler, Stu Galley, Joel Berez, Chris Reeve. E poi c’era lo stesso Vezza e anche Licklider, che accettò di unirsi al gruppo in una sorta di ruolo di consigliere, lo stesso che aveva rivestito al Dynamic Modeling Group del MIT. Oguno di loro raggranellò ogni finanziamento che poteva ottenere, da 400 $ fino a 2.000 $, e in cambio ricevette una proporzionale quota di azioni della nuova società. I fondi iniziali ammontavano a 11.500 $. Il nome della società era inevitabilmente vago, tanto più se consideriamo che nessuno sapeva cosa avrebbe prodotto quella società (se mai avesse prodotto qualcosa). Le parole composte da due termini troncati e vagamente futuristici erano estremamente in voga fra le società tecnologiche dell’epoca (Microsoft, CompuWare, EduWare) e la Infocom seguì la tendenza, scegliendo il nome su cui “tutti avevano meno obiezioni”.

 

 

Come dovrebbe essere chiaro da quanto sopra, non si può certo dire che la Infocom iniziò sotto i migliori auspici. La definirei una “startup da garage”, se non fosse che loro non avevano nemmeno un garage. Per alcuni mesi la Infocom esistette più come una società astratta sospesa in un limbo, che come una vera impresa in affari. Non ebbe nemmeno il suo primo indirizzo postale (una cassetta postale) fino al Marzo del 1980. Inutile dire che nei mesi successivi nessuno dei soci stava lasciando il proprio lavoro, mentre, di tanto in tanto, si incontravano per discutere il da farsi. Ad agosto, Mike Broos si era già stancato dell’andazzo e uscì dal progetto, lasciando quindi nove soci. Tutti furono concordi sul fatto che avevano bisogno di qualcosa da pubblicare in modo relativamente veloce, per far decollare la società. Solo allora sarebbero potuti seguire dei progetti più ambiziosi. Il problema era cosa avrebbero potuto fare per quel loro primo progetto.

 

Gli hacker passarono in rassegna i loro vecchi progetti del MIT, in cerca di idee. Continuavano a tornare sui giochi. C’era quel gioco a quiz, ma sarebbe stato difficile inserire abbastanza domande su un singolo floppy disk per dare un senso alla cosa. Più intrigante era il gioco chiamato Maze. I giochi arcade erano esplosi in quegli anni. Se la Infocom avesse potuto creare una versione di Maze per i cabinati, avrebbero avuto un qualcosa di unico, senza precedenti. Per farlo però sarebbe stato necessario un progetto ingegneristico enorme, sul lato hardware oltre che su quello software. I soci della Infocom erano tutti in gamba, ma erano tutti hacker di software e non di hardware, e di soldi ce n’erano ben pochi. E poi, ovviamente, c’era Zork… ma non c’era nessun modo di infilare un gioco d’avventura da 1 MB in un microcomputer da 32 K o 48 K. E poi ad Al Vezza non piaceva affatto l’idea di entrare nel settore dei giochi, perché temeva che ciò avrebbe potuto compromettere il nome della compagnia, anche se si fosse trattato solo di accumulare dei fondi iniziali per avviare le attività. E così ci furono abbondanti discussioni su altre idee, più legate al mondo degli affari, sempre tratte dalla storia dei progetti del Dynamic Modeling Group: un sistema di indicizzazione dei documenti, un sistema di email, un sistema di elaborazione testi.

 

Nel frattempo, Blank viveva a Pittsburgh ed era piuttosto scontento di ritrovarsi tagliato fuori dai vecchi tempi dell’hacking al MIT. Per fortuna aveva almeno una vecchia connessione con il MIT: Joel Berez, che prima della laurea nel 1977 aveva lavorato al Dynamic Modeling Group. Egli aveva trascorso gli ultimi due anni a Pittsburgh, lavorando nella ditta di famiglia (esperienza che forse convinse gli altri a nominarlo Presidente della Infocom nel 1979). Blank e Berez presero l’abitudine di ritrovarsi insieme per mangiare cinese (alimento alla base della dieta di ogni hacker) e per rimembrare i vecchi tempi. E tutte quelle loro conversazioni continuavano a ritornare su Zork. Era davvero impossibile immaginarsi di portare il gioco su microcomputer? In poco tempo le conversazioni passarono dal nostalgico al tecnico. Ma, come iniziarono a parlare delle questioni tecniche, si affacciarono altre sfide, anche al di là della mera capacità computazionale dei microcomputer.

 

Se anche avessero potuto in qualche modo portare Zork su microcomputer, quale avrebbero scelto? Il TRS-80 era di gran lunga quello più venduto, ma l’Apple II (la Cadillac della trinità del 1977) stava iniziando a guadagnare terreno, grazie all’aiuto del nuovo modello II Plus e di VisiCalc. Ma l’anno prossimo, e quello dopo ancora… chi poteva dirlo? E poi tutte queste macchine erano irrimediabilmente incompatibili l’una con le altre, il che significava che per raggiungere le diverse piattaforme sarebbe stato necessario implementare Zork (e ogni altro futuro gioco d’avventura si decidesse di sviluppare) di nuovo, ogni volta, su ciascuna di tali macchine. Blank e Berez si misero alla ricerca di un linguaggio di alto livello, che fosse abbastanza portabile e adeguato per implementare un nuovo Zork, ma non ne trovarono. Il BASIC era... beh, era il BASIC, e non era nemmeno particolarmente uniforme da microcomputer a microcomputer. All’orizzonte c’era una nuova, promettente implementazione di un più portabile Pascal per Apple II, ma non si parlava di nulla di simile per le altre piattaforme.

 

E così, se volevano essere in grado di vendere il proprio gioco a tutto il mercato dei microcomputer, anziché solo a una fetta dello stesso, si sarebbero dovuti inventare un sistema di gestione dei dati che fosse facilmente portabile, che potesse essere fatto funzionare su differenti microcomputer attraverso un interprete appositamente scritto per ogni modello. Ovviamente creare ogni singolo interprete sarebbe stato impegnativo, ma sarebbe comunque stato uno sforzo più modesto e, qualora la Infocom avesse deciso di fare altri giochi dopo Zork, il risparmio di energie sarebbe rapidamente diventato estremamente significativo. Nel giungere a questa conclusione, avevano sostanzialmente seguito una linea di pensiero già abbondantemente battuta da Scott Adams e dalla Automated Simulations.

 

Ma c’era un altro problema ancora: attualmente Zork esisteva solo su MDL, un linguaggio che ovviamente non era implementato sui microcomputer. Se non volevano riscrivere da zero l’intero gioco (del resto l’obbiettivo di tutto questo non era esattamente quello di tirar fuori un prodotto rapidamente e con una certa facilità?), dovevano anche trovare un modo per far girare quel codice sui microcomputer.

 

Quelli che avevano fra le mani erano un bel po’ di problemi. La prossima volta vedremo come li risolsero (in modo assolutamente brillante).

 

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.