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.

 

 

 

Quando ci siamo lasciati, era la fine dell'estate del 1979 e sette dei nove soci della Infocom vivevano a Boston, ognuno col proprio lavoro a tempo pieno, discutendo -quando il tempo lo permetteva- di quello che avrebbe dovuto fare la loro società nuova di zecca. Nel frattempo gli altri due soci, Marc Blank e Joel Berez vivevano a Pittsburgh e stavano affrontando il problema in modo più pratico, progettando (per ora interamente su carta) un sistema che permettesse di convertire Zork (o almeno una buona metà di Zork) dal PDP-10 ai microcomputer. Mentre Blank e Berez continuavano il proprio lavoro in quell'autunno, si convincevano sempre di più che, sì, la loro idea avrebbe potuto funzionare e così iniziarono a fare pressioni sugli altri di Boston per fare in modo che Zork diventasse il primo progetto della Infocom. Il loro piano era così allettante che alla fine persino il riluttante Al Vezza accettò.

 

In quel periodo Berez era stato ammesso a un programma di economia post-laurea alla Sloan School of Management del MIT; così quel Novembre rientrò a Boston per frequentare – e per assumere la carica di Presidente di una Infocom ancora esistente principalmente sulla carta. Dinanzi alla prospettiva di restare intrappolato da solo a Pittsburgh mentre i suoi amici implementavano il suo progetto, Blank prese la decisione -importantissima sul piano personale- di lasciare l’internato medico e trasferirsi a Boston. Così, all’alba dell’anno 1980, la proverbiale banda era di nuovo riunita e i lavori sul nuovo Zork procedevano di buona lena.

 

Con i loro rapporti al MIT e alla DEC, del tempo su un PDP-10 non era poi difficile da recuperare, anche se tutti quelli della Infocom avevano ormai ufficialmente lasciato il MIT. Nonostante il loro scopo finale fosse quello di vendere Zork sui microcomputer, in questa fase la Infocom continuava a lavorare interamente sul PDP-10; probabilmente il vecchio motto “Noi odiamo i micro!” non era ancora  completamente passato di moda. Blank e Lebling scrissero sul PDP-10 l’intero sistema di sviluppo ZIL, incluso il compilatore, nonché (per poter fare delle prove) la prima versione funzionante della macchina virtuale Z-Machine. Sorprendentemente, il progetto astratto che Blank e Berez avevano ideato su dei tovagliolini e su dei pezzi di carta usata, si rivelò perfettamente funzionante nella realtà. Come dicevo nel mio ultimo post, implementare di nuovo il gioco in ZIL diede loro l’opportunità di migliorare ancora da diversi punti di vista l’originale Zork.

 

Perfino quando arrivò il momento di abbandonare il PDP-10, le preferenze della Infocom restarono evidenti: la seconda implementazione della Z-Machine non era né per la macchina della Radio Shack, né per quella della Apple, bensì per un DEC PDP-11. Se il PDP-10 era l’ammiraglia della DEC (tanto grande e potente che forse si meriterebbe di essere etichettato come mainframe piuttosto che come minicomputer), il PDP-11 era un modello più piccolo, più economico, pensato per “portare il pane a casa”. Si stima che la DEC ne avesse venduti più di 170.000 nei soli anni ‘70. Relativamente trasportabile (se la possibilità di trasportare un computer con un singolo camioncino lo rende “trasportabile”) e senza che necessiti di un pavimento sopraelevato o di altre macchinazioni da "data-center", i PDP-11 erano ovunque: nelle fabbriche, nei laboratori, nei centri di controllo del traffico aereo, e… nella camera da letto di Joel Berez (!!!). In un certo senso il PDP-11 aveva già il suo Zork, essendo stata la prima piattaforma su cui fu creato il porting in FORTRAN di Dungeon, ma ciò non fermò la Infocom dal rendere lo Zork per PDP-11 il suo primo prodotto commerciale. Nonostante la diffusione del PDP-11, il suo mercato non era esattamente una roccaforte del gaming: è riportato che Zork su quella piattaforma vendette meno di 100 copie (una delle quali di recente è apparsa su eBay: sul sito di "Get Lamp" di Jason Scott trovate una scansione del suo manuale, sorprendentemente completa, seppur battuta a macchina e ciclostilata [Il link originale è stato rimosso, ma potete trovare una copia del manuale qui, ndFestuceto]). Era del tutto evidente che la Infocom doveva convertire Zork per i microcomputer.

 

In questo spirito, la Infocom comprò un sistema TRS-80 e Scott Cutler (uno dei pochi soci che avesse avuto una qualche esperienza con i microcomputer) si mise al lavoro, con l’aiuto di Blank, per  costruire un’ apposita Z-Machine. Il momento della verità era arrivato:

 

 

È sempre un momento teso quando un progetto finalmente prende vita e mostra qualcosa di concreto. Ricordo ancora quanto fossi eccitato quando il mio personalissimo interprete di Z-Machine, Filfre, visualizzò il testo d’apertura del primo gioco con cui avevo deciso di provarlo, Infidel. Posso solo immaginare l’eccitazione di Blank e Cutler, quando tutto questo era così nuovo e la posta in gioco era così tanto più alta. Quel che conta però è che l’idea della Z-Machine funzionò. Quando il giocò fu completamente giocabile, la Infocom (erede di una lunga tradizione di informatica istituzionale che faceva le cose come dovevano essere fatte) fece qualcosa di virtualmente senza precedenti per un gioco per microcomputer: sottopose il proprio gioco a una fase di betatesting rigorosa e ripetuta. Il suo tester principale fu uno studente del MIT chiamato Mike Dornbrook, che si era innamorato del gioco al punto di diventarne oltremodo ossessionato, tracciando delle bellissime mappe dettagliate della sua geografia e lavorando sodo per affinare non solo i problemi tecnici ma anche gli enigmi peggiori e le difficoltà del parser (se solo in quei primi tempi la On-Line Systems, Scott Adams, e gli altri sviluppatori avessero avuto una pazienza simile e altrettanta dedizione alla qualità...)

 

Se si esclude il betatest che era ancora in corso, la Infocom a quel punto aveva un vero prodotto da commercializzare. Ora dovevano solo decidere come lo avrebbero venduto. Un’opzione era quella di fare ciò che Ken Williams stava decidendo di fare più o meno proprio in quel periodo: provarci da soli. Tuttavia, data la poca esperienza e la scarsa conoscenza della giovane industria dei microcomputer, ciò sembrò rischioso e nessuno dei soci era poi così eccitato all’idea di inventarsi un packaging e di duplicare migliaia (questa, almeno, era la speranza) di dischi. Iniziarono quindi a proporre Zork a vari publisher. Un tentativo con Microsoft fu respinto dal dipartimento di marketing: avevano già la loro avventura testuale (niente di meno che Adventure in persona) e evidentemente credevano che una fosse più che sufficiente per un singolo publisher. In seguito Bill Gates (che era stato un fan di Zork sul PDP-10) seppe dell’offerta e provò a riaprire la trattativa, ma a quel punto la Infocom stava già trattando con Dan Fylstra della Personal Software, facendo dello Zork della Microsoft un qualcosa di affascinante che sarebbe potuto essere ma non è mai stato.

 

Personal Software oggi è stata quasi completamente dimenticata, ma all’epoca era la stella più luminosa della giovane industria, in grado di eclissare facilmente anche la Microsoft. Fondata da  Peter R. Jennings e Dan Fylstra, fondatori della seminale rivista Byte, la Personal Software trovò la sua miniera d’oro nel 1979, quando raggiunse un accordo con Dan Bricklin e Bob Frankston per la pubblicazione del loro VisiCalc per l’Apple II. Col supporto di un’intelligente campagna promozionale da parte della Personal Software (che enfatizzava opportunamente la natura rivoluzionaria di questo prodotto autenticamente rivoluzionario), al tempo in cui la Infocom si presentò a bussare alla porta del publisher, VisiCalc era sulla bocca di tutto il mondo degli affari, diventando la hit della giovane industria dei microcomputer e arrivando così a vendere centinaia di migliaia di copie. VisiCalc non solo fece della Personal Software il più grande publisher del pianeta, nonché l’oggetto di articoli su riviste come il Time, ma gli conferì anche un enorme potere all’interno del settore. Questo potere si estendeva perfino sulla Apple stessa: un numero infinito di clienti metteva il carro davanti ai buoi, e comprava gli Apple II solo per avere un computer su cui far girare la loro nuova copia di VisiCalc. Fu, insomma, la prima “killer application” dell’era dei PC, e come tale vendette tutti gli Apple II che ciò comportava. Con così tanti soldi e con un tale potere, la Personal Software non sembrò alla Infocom una brutta strada per far uscire il loro nuovo gioco. Fylstra aveva frequentato la scuola di economia al MIT, dove aveva conosciuto sia Vezza che la versione PDP-10 del gioco. Non fu quindi troppo difficile per Berez e Vezza chiudere la trattativa, che incluse anche un anticipo sulle future royalty, aspetto questo per loro assolutamente indispensabile, giacché la Infocom aveva sostanzialmente già speso i suoi 11.500 $ iniziali in hardware, betatester, e tempo sul PDP-10.

 

Nel mezzo dei rispettivi compiti, gli altri soci scrissero anche un paio di articoli per le riviste, che servissero per stimolare un po’ l’attenzione. “Come far entrare un programma grande in una macchina piccola”, una spiegazione un po’ evanescente dei concetti di virtual machine e di virtual memory, apparso nel numero di Luglio di Creative Computing; e “Zork e il futuro delle simulazioni fantasy su computer”, un articolo più teorico sulla nascente arte delle avventure testuali, apparso nel grande numero dedicato alle avventure di Byte di dicembre. Non avendo ancora adottato l’elegante nome di “interactive fiction”, in questo secondo articolo Lebling affibbiò a Zork e ai suoi simili l’etichetta (alquanto scomoda) di “computerized fantasy simulations” (“CFS”). La versione per TRS-80 di Zork stava ormai per sbarcare sul mercato sotto l’ombrello della Personal Software.

 

Le vendite iniziali non furono eccezionali: la versione TRS-80 vendette circa 1.500 copie nei suoi primi nove mesi. Questi numeri possono forse essere in parte spiegati con il marketing poco convinto e privo di immaginazione della Personal Software, che (alla luce del colosso VisiCalc) era sempre meno convinta di voler essere coinvolta nel mercato videoludico. È altresì vero che il mercato del software per TRS-80 non ha mai prosperato nel modo che ci si potrebbe aspettare se lo paragoniamo alle vendite del rispettivo hardware. Uno dei colpevoli principali era da ricercarsi nelle politiche di Radio Shack. Radio Shack insisteva infatti nel voler vendere nei propri negozi solo il software pubblicato sotto la propria etichetta. E al tempo stesso offriva agli sviluppatori delle royalty davvero modeste se confrontate col resto dell’industria, rifiutandosi perfino di attribuirgli adeguatamente la paternità del prodotto sul software stesso, preferendo promuovere l’immagine di una caritatevole Tandy Corporation che apparentemente generava immacolate creazioni software direttamente dal suo didietro. Nel frattempo i proprietari dei negozi di computer (come quelli di ComputerLand, che stavano esplodendo in tutta la nazione) lasciarono Radio Shack da sola a vendere e a occuparsi delle proprie macchine, concentrandosi piuttosto su altre piattaforme. È probabile che lo Zork per TRS-80 fosse finito, almeno in parte, in questa specie di buco nero distributivo, che stava già trasformando il TRS-80 in uno sconfitto, in contrasto con il nuovo gioiellino dell’industria dei microcomputer, l’Apple II. Infatti, quello stesso dicembre la Apple si quotò in borsa, facendo seduta stante dei suoi fondatori e di altre 300 persone, dei miliardari: la prima grande Offerta Pubblica Iniziale del mercato tech, il segno che presto “l’industria dei microcomputer” sarebbe diventata semplicemente “l’industria dei computer”.

 

A proposito dell’Apple II, Bruce Daniels (l’unico membro del team originale di Zork che all’epoca non si era associato alla Infocom) aveva accettato un posto alla Apple, trasferendosi in California dopo la laurea. Accettò di creare sotto contratto la Z-Machine per l’Apple II. Lo Zork dell’Apple II fu così pubblicato nel Febbraio del 1981 e fece molto meglio della versione per TRS-80, vendendo costantemente circa 1.000 copie al mese. Adesso la Infocom aveva finalmente un flusso costante di introiti, oltre all’infrastruttura tecnologica di base (lo ZIL e la Z-Machine) che avrebbe caratterizzato la società per il resto della sua vita. Le cose iniziavano ad andare per il verso giusto, ma dei risvolti imprevisti erano già all’orizzonte.

 

Ve ne parlerò molto presto, ma la prossima volta voglio lasciare da parte la realtà storica in favore di quella virtuale. Ebbene sì, faremo un piccolo viaggio nel Grande Impero Sotterraneo di Zork.

 

Quando ci siamo lasciati l’ultima volta, Marc Blank e Joel Berez stavano valutando come portare Zork sui microcomputer. In realtà stavano cercando di risolvere tre problemi interconnessi. A costo di risultare pedante, lasciate che ve li riassuma:

 

1. Come portare Zork (un gioco enorme, che consumava 1 MB di memoria sul PDP-10) sui microcomputer di fascia più bassa che avevano selezionato: Apple II o TRS-80 con 32 K di RAM e un singolo floppy-disk.

 

2. Come farlo in modo che fosse facilmente convertibile per altre piattaforme, affinché fosse il più indolore possibile trasportare Zork non solo sull’Apple II e sul TRS-80, ma anche (se tutto fosse andato bene) sulle molte altre piattaforme incompatibili, presenti e future.

 

3. Come usare il codice sorgente esistente di Zork in MDL come base per una nuova versione per microcomputer, piuttosto che dover ripartire da zero e implementare da capo il gioco su un qualche nuovo ambiente di programmazione.

 

Volendo potete considerare questo elenco come una classifica di problemi in ordine di importanza, da “assolutamente essenziale” fino a “non sarebbe male”. Ma non è strettamente necessario, perché -come vedremo di qui a poco- Blank e Berez (col successivo aiuto degli altri) riuscirono a risolverli tutti in modo assolutamente brillante. Vorrei potermi occupare singolarmente di ognuno di questi problemi, ma (come sa chiunque si sia cimentato con delle complicate mansioni di programmazione) le soluzioni tendono a intrecciarsi l’una con l’altra. Quindi mi limiterò a chiedervi di tenere a mente questi tre obbiettivi, mentre io vi spiegherò come funzionava nel suo insieme il progetto di Blank e Berez.

 

Quando ci troviamo davanti a un gioco troppo grande per essere accomodato in un nuovo ambiente, la soluzione più ovvia sarebbe quella di rendere semplicemente il gioco più piccolo, rimuovendo dei contenuti. E questa è appunto una di quelle cose che la Infocom fece con Zork. Stu Galley:

 

 

Dimezzando il mondo di Zork, la Infocom potette ridurre drasticamente le dimensioni del gioco. 191 stanze divennero 110; 211 oggetti divennero 117; 911 parole conosciute dal parser divennero 617. Non era la soluzione definitiva ai loro problemi, ma di certo aiutava, lasciandoli comunque con in mano un gioco enorme, delle dimensioni approssimative simili a quelle dell’originale Adventure come numero di stanze, ma capace comunque di annichilirlo in termini di oggetti e di parole, e che era comunque più grande di ogni altro gioco d’avventura per microcomputer. E, come spiega Galley qui sopra, li lasciava comunque in possesso di abbondante materiale con cui costruire un possibile seguito.

 

Altri risparmi potevano essere conseguiti spostando l’attenzione sul compilatore per MDL. Essendo un linguaggio progettato per eseguire molti compiti di computazione generici, molte delle capacità dell’MDL risultavano ovviamente inutilizzate in un gioco d’avventura come Zork. Ma, anche se inutilizzate, esse consumavano comunque memoria preziosa. La Infocom dette un paio di sforbiciate all’MDL, proprio come avevano fatto con il mondo di Zork, eliminando le librerie e la sintassi superflua, e tenendo solo ciò che era strettamente necessario per implementare un gioco d’avventura. Chiamarono il nuovo linguaggio ZIL (Zork Implementation Language [“Linguaggio per l’Implementazione di Zork”; ndAncient]), mentre il compilatore che attivava il linguaggio (che girava ancora su un PDP-1) lo chiamarono Zilch. Lo ZIL restò abbastanza simile, come sintassi e impostazione di base, all’MDL, tanto è vero che convertire Zork verso lo ZIL fu piuttosto indolore, ma nonostante ciò il nuovo linguaggio non solo produceva degli eseguibili più compatti e più veloci, ma era anche molto più pulito sintatticamente. Infatti lo ZIL incoraggiò la Infocom non solo a convertire Zork per il nuovo linguaggio, ma anche a migliorarlo da molti punti di vista; in particolare fu il parser che, implementato nel più congeniale ZIL, divenne ancora migliore.

 

Questa è la lanterna di Zork in MDL:

 

 

E questo è il medesimo oggetto in ZIL:

 

 

Per i posteri darò una veloce spiegazione del codice ZIL mostrato qui sopra. La prima linea semplicemente ci dice che quel che segue descriverà un oggetto chiamato “lanterna”. La linea successiva ci dice che esso si trova nel soggiorno della casa bianca. Poi vediamo che il giocatore si può riferire a esso anche con i termini “lamp,” “lantern,” or “light,”, con l’aggettivo opzionale di “d’ottone” (che del resto può rivelarsi utile per distinguerla dalla lanterna rotta che si trova in un’altra zona del gioco). Quella che viene chiamata descrizione breve (e cioè, con maggior precisione, il nome col quale appare nell’inventario e in altri punti dove deve essere inserito nel testo) è “lanterna d’ottone”. Il flag TAKEBIT indica che è un oggetto che il giocatore può raccogliere e portare in giro con sé; il flag LIGHTBIT significa che proietta luce, illuminando qualunque stanza buia in cui viene lasciato o trasportato.  LANTERN-F è la speciale routine d’azione della lanterna: un pezzo di codice che ci permette di scrivere delle “regole” speciali per la lanterna, che valgono solo per essa, come ad esempio le routine che permettono al giocatore di accenderla e di spegnerla (come ho spiegato in precedenza, questo livello di programmabilità e il conseguente approccio “orientato agli oggetti” era ciò che davvero contraddistingueva l’MDL -e di conseguenza lo ZIL- da tutti gli altri sistemi di sviluppo di avventure testuali dell’epoca). FDESC è la descrizione della lanterna che appare prima che essa sia spostata, e quindi come parte della descrizione della stanza del soggiorno; LDESC invece appare dopo che l’oggetto è stato spostato e depositato altrove. Per finire, SIZE determina le dimensioni e il peso della lanterna ai fini di stabilire quanto il personaggio possa trasportare con sé in un certo momento. Vi lascerò come esercizio quello di tradurre il più caotico codice per MDL...

 

E così a questo punto la Infocom aveva in gran parte risolto il problema n° 3 e aveva fatto dei grandi passi in avanti con il problema n° 1. Il che però li lasciava ancora con in mano il problema n° 2. Probabilmente state pensando che fosse abbastanza facile progettare un’accoppiata engine/database simile a quella ideata da Scott Adams. La verità però è che era assai problematico. Vi ricorderete infatti che una delle cose che rendevano unico l’ambiente di sviluppo di Zork (che fosse l’MDL o lo ZIL) era la sua programmabilità. Passare a una soluzione simile a quella di Adams avrebbe significato sacrificare proprio questo e, nel mezzo, anche lo ZIL. Perché lo ZIL funzionasse doveva poter eseguire del codice che gli consentisse di gestire le interazioni speciali (come, appunto, l’accensione e lo spegnimento della lanterna); doveva, in altre parole, essere un vero linguaggio di programmazione “Turing-complete” e non un mero sistema di inserimento dati. Ma come riuscirci senza rinunciare ad avere un sistema che fosse anche portabile da macchina a macchina (incompatibile)? La risposta: avrebbero ideato una macchina virtuale, un computer immaginario ottimizzato proprio per giocare alle avventure testuali (proprio come lo ZIL era ottimizzato per scriverle) e poi avrebbero scritto il codice di un interprete che avrebbe simulato quel computer su ogni piattaforma per cui avrebbero voluto pubblicare Zork.

 

Oggi le macchine virtuali sono ovunque. Le app del vostro smartphone Android in realtà girano dentro una virtual machine. Potete utilizzare qualcosa tipo VMWare sul vostro computer per utilizzare Linux dentro Windows, o viceversa. I grandi mainframe e, sempre di più, anche i server di fascia alta hanno sistemi operativi tipo Linux che funzionano all’interno di macchine virtuali astratte dal sottostante hardware; ciò, fra i vari benefici, permette anche di suddividere un unico gigantesco mainframe in tanti mainframe più piccoli. A parte gli scenari di questo tipo, le virtual machine sono così interessanti essenzialmente per due motivi; e virtualmente (ah!) chiunque decida di usarle lo fa per un motivo o per l’altro, o per entrambi. Innanzitutto sono molto più sicure. Se un codice malevolo (come un virus) viene introdotto in una macchina virtuale, rimane al suo interno, anziché infettare l’intero sistema che la ospita, e il codice che manda in crash la virtual machine (che lo faccia intenzionalmente o accidentalmente) in realtà manda in crash solo la virtual machine stessa, e non tutto il sistema che la ospita. La seconda cosa è che una virtual machine consente di eseguire lo stesso programma su macchine che sarebbero altrimenti incompatibili. È un caso di “scrivilo una volta e poi gira ovunque”, come erano soliti ripetere i sostenitori di Java. Nel loro caso, ogni piattaforma su cui doveva girare il programma in questione doveva solo essere dotata di un’implementazione aggiornata della virtual machine di Java (non necessariamente il linguaggio, anche solo la virtual machine). Le macchine virtuali hanno però anche un grosso svantaggio: poiché la piattaforma che le ospita sta emulando un altro computer, tendono a essere molto più lente dello stesso codice sorgente eseguito direttamente sulla propria piattaforma (lo so, tecnologie come la compilazione just-in-time possono fare molto per alleviare questo difetto, ma qui non è il caso di addentrarsi ulteriormente nell’argomento). Tuttavia oggi il potere computazionale è poco costoso e molto diffuso, e quindi questo in genere non è un grande problema. E infatti la situazione attuale può diventare a tratti anche abbastanza ridicola: la mia versione per Kindle di The King of Shreds and Patches è costruita su una virtual machine (Glulx) che viene eseguita dentro un’altra virtual machine (quella di Java), il tutto eseguito su un minuscolo lettore portatile... e nonostante questo le performance restano accettabili.

 

Già nel 1979 le virtual machine non erano un’idea nuova. Fra il 1965 e il 1967 un team dell’IBM aveva lavorato in stretto contatto con il Lincoln Laboratory del MIT per creare un sistema operativo chiamato CP-40, nel quale fino a 14 utenti potevano loggarsi all'interno di un proprio computer mono-utente, interamente simulato da un software eseguito su un grande mainframe della IBM. In seguito il CP-40 divenne la base del sistema operativo opportunamente chiamato VM, pubblicato per la prima volta dalla IBM nel 1972 e ancora oggi largamente usato sui mainframe odierni. Nel 1978 un’implementazione in Pascal, nota come UCSD Pascal introdusse la P-Machine, una macchina virtuale portatile che consentiva ai programmi scritti in UCSD Pascal di girare su molte macchine diverse, incluso perfino l’Apple II (in seguito alla pubblicazione dell’Apple Pascal nell’agosto del 1979). Proprio la P-Machine ebbe una grande influenza sulla virtual machine della Infocom, la Z-Machine.

 

Nell’optare per una virtual machine, dovettero ovviamente pagare (come con ogni altra virtual machine) la penalità in termini di performance, ma essa non era troppo severa come invece ci si aspetterebbe. Proprio come avevano ottimizzato lo ZIL, Blank e Berez resero infatti la Z-Machine il più leggera ed efficiente possibile, includendovi solo quelle caratteristiche davvero utili per eseguire un’avventura testuale. E poi avrebbero implementato l’interprete di ogni piattaforma solo in un linguaggio assembly altamente ottimizzato, col risultato che Zork (pur girando all’interno di una virtual machine) girava comunque molto, molto più velocemente delle tipiche avventure scritte in BASIC di quegli anni. E infatti il potere computazionale dei microcomputer, per quanto limitato, non era mai stato la loro preoccupazione principale durante la conversione di Zork: il vero collo di bottiglia era la memoria. Sì, avrebbero dovuto sacrificare della memoria aggiuntiva per l’interprete, ma ne avrebbero risparmiata ancora di più lavorando sull’efficienza della Z-Machine. Per esempio, una speciale codifica gli permetteva di immagazzinare la maggior parte dei caratteri in 5 bit invece che in 8 bit, e gli permetteva di rimpiazzare le parole più comunemente usate con delle loro abbreviazioni. Una tale compressione del testo era molto rilevante, specie se consideriamo che, dopotutto, è il testo che compone la maggior parte di un'avventura testuale. Con tali tecniche di compressione, insieme alle sforbiciate al gioco stesso e al linguaggio ZIL, finirono per avere un gioco di soli 77 K di dimensioni, senza ovviamente considerare l’interprete della macchina virtuale che era necessario per eseguirlo; quest’ultimo fu chiamato Zip (da non confondersi ovviamente con il formato di compressione dei file). Il file del gioco da 77 K, che la Infocom iniziò a chiamare “story file” [“file della storia”; ndAncient] è sostanzialmente uno "snapshot" della memoria della virtual machine.

 

Quando parliamo di capacità di immagazzinamento di un computer, in realtà stiamo parlando (confondendo così genitori e nonni di tutto il mondo) di due quantità separate: la capacità su disco e la capacità di memoria (RAM). Un Apple II poteva contenere 140 K su un singolo dischetto, mentre il TRS-80 in realtà faceva un po’ meglio con i suoi 180 K. E così ora la Infocom aveva un gioco che poteva essere comodamente alloggiato, insieme al suo necessario interprete, su un singolo dischetto. Il problema era la RAM: anche dimenticandoci il necessario interprete, 77 K non entrano in 32 K, per quanto ci si sforzi di ficcarceli. Oppure sì?

 

Non era la prima volta nemmeno in quegli anni che si sentiva usare il disco come una sorta di memoria secondaria, leggendo dei pezzetti di dati e trasferendoli nella RAM, per poi scartarli quando non erano più necessari. La Microsoft aveva usato proprio questa tecnica per infilare Adventure nei 32 K del TRS-80: ogni pezzo di testo, tutti immagazzinati in un file esterno al gioco stesso proprio come nel progetto originale di Crowther e Woods, veniva letto dal disco solo quando doveva andare a schermo. Tuttavia il sofisticato sistema orientato agli oggetti della Infocom mischiava necessariamente testo e codice, rendendo quantomeno poco pratico un tale approccio. Per questo Blank e Berez si spinsero un passo oltre: avendo già progettato una virtual machine, vi aggiunsero un’implementazione della memoria virtuale.

 

Anche il concetto di memoria virtuale non era nuovo, in generale, nel mondo dell’informatica. E infatti la memoria virtuale risale ancora più indietro nel tempo delle virtual machine, fino a uno dei primi supercomputer, sviluppato dalla University of Manchester e chiamato Atlas, che era stato ufficialmente commissionato nel 1962. In un sistema con memoria virtuale, ogni programma non ha un punto di vista “onesto” sulla memoria fisica del computer host. In sostanza gli viene data una mappa “idealizzata” della memoria, che potrebbe avere ben poco a che fare con il vero layout della RAM fisica del computer che lo ospita. Quando legge e scrive dei pezzi di questa mappa, l’host automaticamente traduce gli indirizzi virtuali in indirizzi reali dentro la sua memoria fisica, in modo trasparente. Ma perché mai fare una cosa del genere, specialmente se consideriamo che produce necessariamente uno spreco di risorse? Anche stavolta per due principali ragioni, entrambe le quali di solito si considerano applicabili solo a sistemi operativi multitasking (che ovviamente erano poco più di un sogno per i microcomputer del 1979 o del 1980). Per prima cosa, isolando la memoria di ciascun programma da quella di ogni altro (oltre che da quella del sistema operativo) la memoria virtuale si assicura che un programma non possa (per malizia o semplicemente a causa di bug) corrompersi e danneggiare altri programmi, se non addirittura far crashare l’intero sistema. Per seconda cosa, la memoria virtuale fornisce al computer una specie di “seconda spiaggia”, un’alternativa al semplice fallimento di sistema, qualora un programma (o più programmi) in esecuzione chiedessero più memoria fisica di quella concretamente disponibile. Quando ciò accade, il sistema operativo cerca nella propria memoria dei pezzi che non vengono usati spesso. A quel punto li archivia nella cache su disco, facendo così spazio nella RAM fisica per allocare la nuova richiesta. Quando si deve accedere nuovamente alle aree così archiviate nella cache, esse devono essere riportate nella RAM, possibilmente scambiandole con altri chunk, se la memoria è scarsa. Tutto ciò avviene in modo trasparente rispetto al programma (o ai programmi) in questione, che continuano a vivere all’interno del loro punto di vista idealizzato sulla memoria, gioiosamente ignari di quanto il sistema sottostante stia in realtà ansimando per tenere tutto in piedi. La memoria virtuale ormai è con noi da molti anni nel mondo dei PC desktop. In uno schema del genere c’è inevitabilmente un punto in cui il gioco non vale più la candela: se avete provato ad aprire tantissime finestre o programmi su un vecchio PC, avrete notato che tutto diventava terribilmente lento, mentre l’hard disk lavorava come un mulino; ecco, adesso sapete quello che stava succedendo dietro le quinte (sempre che non lo sapeste già; qui al The Digital Antiquarian non presupponiamo nessun livello di conoscenze tecniche nei nostri lettori).

 

Per la Z-Machine, Berez e Blank adoperarono una versione molto più semplice della memoria virtuale rispetto a quella che oggi troviamo in sistemi operativi come Windows, Linux, o OS X. E se certe importanti informazioni dinamiche (come la posizione attuale di oggetti all’interno del mondo di gioco) deve essere sempre tracciata e aggiornata dinamicamente, la gran parte dei dati che compongono un gioco come Zork è in realtà statica e non cambia nel tempo: tanto, tanto testo, ovviamente, mischiato a un bel po’ di codice. Berez e Blank riuscirono a progettare il compilatore ZIL in modo tale che esso collocasse tutta la roba che poteva realisticamente cambiare (e che noi chiameremo “dati dinamici”) all’inizio dello story file. Tutto il resto (che noi chiameremo “dati statici”) veniva dopo. Ebbene, dei 77 K dello story file di Zork, solo 18 K erano di dati dinamici. Ecco quello che fecero, quindi...

 

I dati dinamici (cioè la memoria in cui la virtual machine avrebbe scritto, oltre che letto) è sempre immagazzinata nella RAM del computer host. I dati statici tuttavia sono caricati e scaricati dalla RAM ad opera dell'interprete, secondo il bisogno, in blocchi di 1 K chiamati “page” [“pagine”; ndAncient]. In altre parole: dal punto di vista del gioco, esso ha 77 K di memoria con cui lavorare. L’interprete nel frattempo scambia freneticamente blocchi di memoria dentro e fuori dalla molto più limitata RAM fisica, per mantenere in piedi questa illusione. Come la virtual machine, anche la memoria virtuale porta ovviamente con sé un rallentamento, ma è un male necessario. Su un sistema a 32 K, con 18 K riservati ai dati dinamici, la Infocom aveva ancora 14 K liberi per ospitare al loro interno l’interprete della macchina virtuale, un piccolo “stack” (cioè un’area dove i programmi immagazzinano le informazioni temporanee di cui hanno bisogno per il “moment-to-moment processing”) e una “page” o due di memoria virtuale. Certo alle volte poteva rallentare vistosamente, ma funzionava. E, quando veniva avviato su un sistema con, ad esempio, 48 K, l’interprete se ne accorgeva automaticamente e usava questa memoria addizionale per tenere più dati statici nella RAM fisica, velocizzando così il tutto e ripagando l’utente per il suo investimento nell’hardware.

 

Con l’impianto ZIL / Z-Machine, la Infocom aveva creato un sistema, robusto e riutilizzabile, che avrebbe potuto godere di vita propria ben al di là del compito specifico di infilare Zork sul TRS-80 e sull’Apple II. Sono certo di non spoilerare niente a nessuno, se vi svelo già adesso che ciò è esattamente ciò che accadde.

 

Forti di tali fondamenta tecniche, la prossima volta osserveremo il percorso che portò infine Zork sul mercato.  

 

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).

 

 

 

Nel novembre del 1980, la Personal Software iniziò a pubblicizzare l’annuncio di cui sopra sulle riviste di computer, per promuovere un nuovo gioco disponibile su TRS-80 e (qualche mese più tardi) sull'Apple II. Non si può definire esattamente un capolavoro del marketing: l'artwork pacchiano e dilettantesco può essere difeso solo perché in linea con le altre pubblicità dell'epoca, e il testo riesce a non spiegare assolutamente niente di cosa contraddistingua Zork dalle altre avventure testuali simili. Come non perdonare un avventuriero scafato che abbia voltato distrattamente pagina alla lettura dei “labirinti che ingarbuglieranno la tua quest” e dei “20 tesori” che devono essere riposti “nell'Armadietto dei Trofei”. Perfino Scott Adams (che non era esattamente il paladino della sperimentazione) aveva ritenuto opportuno spingersi oltre le semplicistiche cacce al tesoro fantasy. Senza considerare poi che Zork non offriva nemmeno le belle immagini dei primi giochi della On-Line Systems (per quanto questi fossero punitivi fin quasi al punto di risultare ingiocabili).

 

Nonostante ciò, Zork rappresenta una vera svolta nel genere della avventure testuali, anzi... un’intera collezione di svolte, a partire dal suo parser che mostrava davvero un barlume di uso corretto della lingua inglese (invece del solito semplicissimo schema ripetitivo del testo in-game), tale da far pensare per la prima volta che dietro vi fossero degli autori davvero interessati alla qualità della loro prosa, che non ritenevano la grammatica e l’ortografia delle inutili distrazioni.

In una delle mie parti preferite del documentario Get Lamp di Jason Scott, diversi intervistati riflettono su quanto formidabile fosse Zork nel mondo dell’informatica del 1980-1981. Tutti concordano nell’affermare che, per un breve lasso di tempo, esso sia stato il dischetto più impressionante da tirar fuori per mostrare ciò di cui erano capaci i nuovi TRS-80 e Apple II.

 

Zork giocava su un livello completamente diverso da qualunque altro gioco d’avventura, cosa che del resto non sorprende più di tanto, considerando il suo pedigree. Di certo non si può dedurlo dalla pubblicità qui sopra, ma Zork nasce nell’area più leggendaria della più importante università della storia dell’ingegneria informatica: il MIT. A ben vedere il pedigree di Zork è così impressionante che è difficile sapere da dove iniziare a descriverlo e ancor più difficile sapere dove smettere, e altrettanto difficile evitare di venir risucchiati in un'interminabile versione informatica del “Numero di Bacon”. Per gestire la cosa, cercherò il più possibile di limitarmi alle persone coinvolte direttamente con Zork o con la Infocom, la società che lo ha sviluppato. Iniziamo quindi con Joseph Carl Robnett Licklider, un tizio che per sua ammissione ebbe un ruolo più marginale che diretto nella storia della Infocom, ma che ci serve come esempio della “rarefatta aria di ingegneria informatica” che si respirava alla Infocom.

 

Nato nel 1915 a Saint Louis, Licklider era uno psicologo di mestiere, ma aveva quell’intelletto irrequieto di cui Joseph Weizenbaum avrebbe lamentato la scomparsa (apparente) nelle successive generazioni di studenti del MIT. Conseguì un triplice bachelor's degree in fisica, matematica, e psicologia alla Washington University in Saint Louis all’età di 22 anni, avendo anche “flirtato”, lungo il percorso, con la chimica e le belle arti. Si fermò un attimo per concentrarsi sulla psicologia per il suo Master's degree e per il suo dottorato di ricerca, pur restando costantemente interessato a connettere la scienza “soft” della psicologia con le scienze “hard” e con la tecnologia. E così, studiando la componente psicologica dell’udito, apprese la conformazione fisica del sistema nervoso uditivo dell’uomo e degli animali più di quanto non facciano molti medici specialisti (una volta lo ebbe a definire “il prodotto di un superbo architetto e di un approssimativo operaio”). Durante la Seconda Guerra Mondiale le ricerche sugli effetti dell’altitudine sugli equipaggi dei bombardieri lo portarono ad essere altrettanto coinvolto nella ricerca sulla tecnologia radio utilizzata per le comunicazioni tra i membri dell'equipaggio e con gli altri aerei.

 

Dopo alcuni brevi periodi in varie università, Licklider arrivò al MIT nel 1950, inizialmente per continuare i suoi studi sull’acustica e sull’udito. Tuttavia l’anno seguente il complesso militare-industriale americano si rivolse al MIT in cerca di aiuto per create un network di allerta precoce per i bombardieri sovietici, che ci si immaginava avrebbero potuto calare sull'America dal Circolo Polare Artico. Licklider si unì all’istituzione che fu creata per portare avanti il progetto (il Lincoln Laboratory) in qualità di capo del gruppo di “human-engineering”, ed ebbe un ruolo nella creazione del Semi-Automatic Ground Environment (SAGE), di gran lunga la più ambiziosa applicazione di tecnologia informatica concepita fino ad allora e per molti anni a venire. Creato dal Lincoln Lab del MIT insieme alla IBM e altri partner, il cuore del SAGE era un insieme di mainframe IBM AN/FSQ-7, fisicamente i computer più grandi mai costruiti (un record che probabilmente deterranno per sempre). Il sistema compilava i dati provenienti da molte stazioni radar, per permettere agli operatori di tracciare in tempo reale un ipotetico attacco. Potevano far decollare in allarme e guidare aerei americani per intercettare i bombardieri, con una visuale a volo d’uccello sulla battaglia risultante. Le versioni successive di SAGE consentivano perfino di prendere il momentaneo controllo di aerei alleati, guidandoli verso il punto di intercettazione attraverso un collegamento ai loro sistemi di auto-pilota. SAGE è rimasto operativo dal 1959 al 1983, costando più di quel Manhattan Project, che per primo aveva scoperchiato il vaso di Pandora del conflitto nucleare, e produsse giganteschi passi avanti nell’informatica, in particolare nelle aree del networking e del time-sharing interattivo. D’altro canto, però, se consideriamo che, quando esso divenne operativo, la minaccia rappresentata dai bombardieri nucleari (che il SAGE avrebbe dovuto fronteggiare) era stata già abbondantemente surclassata da quella dei Missili Balistici Intercontinentali, la sua utilità da un punto di vista militare è quantomeno discutibile.

 

 

Negli anni '50 la maggior parte delle persone, fra cui anche molti degli ingegneri e dei primi programmatori che ci lavoravano, vedevano i computer essenzialmente come dei giganteschi calcolatori. Mettevi dei numeri in un'estremità e ne ottenevi altri dall'altra, che si trattasse della giusta traiettoria di un pezzo di artiglieria destinato a colpire un qualunque bersaglio, o che si trattasse dei conti correnti dei milioni di clienti di una banca. Tuttavia, osservando i primi tester di SAGE mentre tracciavano in tempo reale delle minacce simulate, Licklider ebbe una visione radicalmente nuova dall'informatica, in cui l'uomo e il computer potevano collaborare attivamente insieme, in modo interattivo, per risolvere problemi, generare idee, e magari anche divertirsi. E lui si portò dietro queste idee quando nel 1953 lasciò il nascente progetto SAGE per galleggiare fra vari ruoli diversi all'interno del MIT, allontanandosi lentamente sempre di più dalla psicologia tradizionale a favore dell'informatica. Nel 1957 iniziò a dedicarsi all'informatica a tempo pieno, quando (seppur solo temporaneamente) lasciò il MIT per la società di consulenze Bolt Beranek and Newman, una società che giocherà un ruolo enorme nello sviluppo dei network informatici e di quella che oggi conosciamo come internet (i lettori più fedeli di questo blog si ricorderanno che la BBN è anche il luogo dove era impiegato Will Crowther quando creò la versione originale di Adventure come svago dalla sua attività principale di programmazione del codice di gestione dei primi router per network informatici).

 

Licklider, che voleva che tutti (perfino i suoi studenti universitari) lo chiamassero semplicemente “Lick”, era una persona brillante quanto umile. Con la parlata lenta e strascicata del Missouri che poteva oscurare il genio di alcune delle sue idee, non ha mai pensato alla carriera o alla fama personale, e non ha mai fatto uso di inganni o di scaltrezze per avere più successo. Quando uno dei suoi colleghi più ambiziosi rubava una sua idea, Lick si limitava a scrollare le spalle, dicendo: “Non importa che si prenderà il merito; quel che conta è che il risultato sia raggiunto.” Tutti lo adoravano. Gran parte del suo lavoro sarà anche stato finanziato dalla realpolitik dell'industria militare, ma Lick era di indole idealista. Si era convinto che i computer avrebbero potuto plasmare una società migliore e più giusta, in cui gli uomini avrebbero potuto creare ed esplorare il proprio potenziale affiancati dai computer, che si sarebbero assunti tutti i compiti noiosi e ripetitivi. Anticipando in modo sorprendente il World Wide Web, si era immaginato un mondo di “plance di home computer” connesse a un network più ampio che avrebbe portato il mondo dentro casa, in modo interattivo (invece che nel modo passivo e dominato dalle grandi società, come avveniva nella televisione). Tutte queste idee le mise anche nero su bianco in uno studio del 1960 (“Man-Computer Symbiosis” [“Simbiosi Uomo-Computer”]), inserendo il suo pensiero nella lunga schiera degli utopisti informatici, che giocheranno un ruolo essenziale nello sviluppare tecnologie più amichevoli per l'uomo comune, come il linguaggio di programmazione BASIC e i microcomputer veri e propri.  

 

Nel 1958 il governo degli Stati Uniti d'America creò l'Advanced Research Projects Agency in risposta alla presunta superiorità tecnologica e scientifica dell'Unione Sovietica alla luce del lancio dello Sputnik (il primo satellite del mondo) avvenuto l'anno precedente. L'ARPA sarebbe dovuta essere un qualcosa di “visionario”, che metteva insieme scienziati e ingegneri per ricercare idee e tecnologie che sarebbero anche potute non essere di immediata applicabilità nei programmi militari in corso, ma che si sarebbero potute dimostrare utili in futuro. Fu il passo successivo di Lick dopo la BBN: nel 1962 assunse il ruolo di capo del loro “Information Processing Techniques Office”. Rimase all'ARPA per soli due anni, ma in molti gli riconoscono il merito di aver profondamente cambiato il modo di pensare dell'agenzia. Prima di lui l'ARPA era concentrata su monolitici mainframe, usati come gigantesche “macchine per risposte”, che operavano in batch-processing. Da Where Wizards Stay Up Late:

 

 

“Robe da asini” tipo queste erano il motore di gran parte delle riflessioni sui computer di quei giorni, perfino in università prestigiose come il MIT. Tuttavia Lick virò ARPANET in una direzione più gestibile e fruttifera, verso delle reti di computer che gestissero applicazioni interattive in connubio con gli umani: dei fatti e dei numeri se ne sarebbe occupato il computer, mentre delle conclusioni e del processo decisionale se ne sarebbe occupato l'uomo. Questo cambiamento di rotta condusse, nel giro di una decade, alla creazione di ARPANET. E, come tutti oggi ben sanno, ARPANET alla fine divenne Internet (dite quel che volete della Guerra Fredda, ma non che non abbia portato dei giganteschi passi in avanti nell’informatica). La visione umanistica dell’informatica, di cui Lick era paladino, resta percorribile e allettante ancora oggi, mentre restiamo in attesa che i fautori dell’intelligenza artificiale ci producano il primo HAL.

 

 

Lick tornò al MIT nel 1968, stavolta come direttore del leggendario Project MAC. Creato nel 1963 col fine di condurre ricerche per ARPA, la sigla MAC stava (a seconda della persona con cui stiamo parlando) per "Multiple Access Computing" o per "Machine Aided Cognition". Questi due nomi definiscono anche l’oggetto principale delle prime ricerche che vi venivano condotte: sistemi in "time-sharing" che permettessero a utenti multipli di condividere risorse e usare programmi interattivi su una singola macchina; e intelligenza artificiale, sotto la guida di due dei più famosi sostenitori dell’IA: John McCarthy (che ne ha anche coniato il termine) e Marvin Minsky. Potrei scrivere con facilità altri post (se non addirittura dozzine di post) sulla carriera e sulle idee di questi due uomini, affascinanti, problematici, e a volte un po’ inquietanti. E potrei dire lo stesso di molti altri dei luminari dell’informatica del MIT con cui Lick fu in stretto contatto, tipo Ivan Sutherland, l’inventore del primo programma di disegno nonché sostanzialmente di tutto il campo della ricerca nella computer grafica, oltre che suo successore alla guida di ARPA. Invece mi limiterò (ancora una volta) a segnalarvi Hackers di Steven Levy, un libro di facile lettura ma necessariamente incompleto, che descrive il fermento intellettuale del MIT degli anni ‘60, e poi Where Wizards Stay Up Late di Matthew Lyon e Katie Hafner, per approfondire i primi anni della carriera di Lick, ma anche la BBN, il MIT, e il nostro vecchio amico Will Crowther.

 

Il Project MAC si divise in due nel 1970, diventando il MIT AI Laboratory e il Laboratory for Computer Science (LCS). Lick rimase con quest’ultimo nel ruolo di una sorta di figura paterna per la nuova generazione di giovani hacker che alla fine degli anni ‘70 stavano lentamente rimpiazzando la vecchia guardia, di cui parla il libro di Levy. La sua era una mente accorta, sempre pronta a raccogliere le loro idee, e lui riusciva sempre (grazie anche alla sua rete di connessioni col governo e con l’industria) a trovare i fondi per portarle avanti.

 

L’LCS era formato da una serie di gruppi di lavoro più piccoli, uno dei quali era noto come il Dynamic Modeling Group. È stranamente difficile abbinare questi gruppi a uno scopo univoco. A ben vedere non è possibile farlo nemmeno con gli stessi AI Lab e LCS. Molte ricerche che si sarebbero potute facilmente considerate inerenti all’IA si svolgevano all’LCS, e molte che invece non rientravano tanto comodamente sotto quell’ombrello si svolgevano all’AI Lab (per esempio Richard Stallman sviluppò il text editor definitivo per gli hacker, l'EMACS, al AI Lab – un progetto indiscutibilmente meritevole, ma che ha davvero poco a che fare con l’intelligenza artificiale). I gruppi e gli individui al loro interno avevano un’immensa libertà di "hackerare" su qualunque progetto giustificabile di loro interesse (con i progetti non giustificabili che venivano rimandati al dopolavoro), aspetto questo che fece dell’LCS e dell’AI Lab l'amatissima casa degli hacker. E molti di loro arrivarono a ritardare la propria laurea, o addirittura non ci persero proprio tempo, tanto era intellettualmente fertile l’atmosfera nel MIT in contrasto con ciò che avrebbero trovato in una “normale” carriera nell’industria privata.

 

 

Il direttore del Dynamic Modeling Group era un tizio chiamato Albert (Al) Vezza, che ricopriva anche il ruolo di direttore aggiunto dell’LCS. E qui dobbiamo prestare attenzione. Se sapete già qualcosa della storia della Infocom, probabilmente vi ricorderete di Vezza come dell'imprenditore severo e cattivo, che non riusciva a vedere la magia nel nuovo medium della narrativa interattiva che il resto della società voleva perseguire, e che insisteva nel voler ridurre il lavoro della divisione ludica a una mera fonte di introiti per finanziare le applicazioni professionali più “serie”, e che alla fine condusse la società alla rovina per colpa delle sue errate priorità. È però anche vero che non c’è nemmeno mai stato un vero scontro diretto fra gli ex studenti universitari della Infocom e Vezza. Un’intervista con Mike Dornbrook per un progetto di uno studente del MIT impegnato a studiare la storia della Infocom, ci fornisce la seguente immagine di Vezza al MIT:

 

 

D’altro canto Lyon e Hafner hanno però questo da dire al riguardo:

 

 

Al di là dei suoi difetti, Vezza era molto più di un vuoto colletto bianco privo di immaginazione. Ha infatti avuto una lunga e brillante carriera, spesa in gran parte a portare avanti le idee inizialmente proposte dallo stesso Lick; per esempio, appare nel libro di Lyon e Hafner perché ebbe un ruolo chiave nell’organizzazione della prima dimostrazione pubblica delle capacità della nascente ARPANET. Anche dopo gli anni alla Infocom, la sua restò una voce importante nel World Wide Web Consortium, l’ente che sviluppò molti degli standard che ancora oggi guidano internet. Di certo non rende onore a Vezza il fatto che la sua pagina di Wikipedia consista quasi esclusivamente nel suo inglorioso mandato alla Infocom, un periodo che probabilmente lui considera poco più che una sgradevole parentesi della sua carriera. Anche noi però siamo principalmente interessati a tale parentesi, benché per adesso ci accontentiamo di tracciare il ritratto di un uomo che era più un amministratore o un burocrate che un hacker, e che era più pragmatico che idealista; un uomo che, in conseguenza di ciò, aveva problemi a relazionarsi con le persone che avrebbe dovuto dirigere.

 

Molte di queste persone avevano nomi che i fan della Infocom hanno imparato a conoscere bene: Dave Lebling, Marc Blank, Stu Galley, Joel Berez, Tim Anderson, ecc. ecc. Come Lick, molte di queste persone erano diventate hacker passando per vie traverse. Lebling, per esempio, aveva conseguito un diploma in scienze politiche prima di venir risucchiato nell’LCS, mentre Blank faceva la spola fra Boston e New York, dove in qualche modo riuscì a completare i suoi studi di medicina pur "hackerando" come un pazzo al MIT. Una cosa però accomuna tutte queste persone: erano in gamba. Del resto all’LCS i cretini erano mal sopportati – anzi, non erano sopportati per niente.

 

Uno dei primi lavori del Dynamic Modeling Group fu la creazione di un nuovo linguaggio di programmazione da utilizzare nei suoi progetti, che (con la tipica impudenza degli hacker) fu chiamato “Muddle” [“bordello”]. Il Muddle divenne rapidamente l’MDL (MIT Design Language) in risposta a qualcuno (Vezza?) che non apprezzava lo humour del Dynamic Modeling Group. Si trattava, in sostanza, di una versione migliorata di un vecchio linguaggio di programmazione sviluppato al MIT da John McCarthy, che era (e resta ancora oggi) il linguaggio favorito dai ricercatori nel campo dell’intelligenza artificiale: il LISP.

 

Forti del MDL, il Dynamic Modeling Group si lanciò in una serie di progetti, individuali o cooperativi. Alcuni di questi progetti avevano anche delle vere applicazioni militari che dovevano strizzare l'occhio a quelle persone che, in ultima analisi, pagavano per tenere in piedi tutta la baracca; Lebling, per esempio, passò un bel po’ di tempo su dei sistemi informatizzati di riconoscimento del codice morse. Ma c’erano anche molti giochi, in alcuni dei quali anche Lebling partecipava, incluso quello più ricordato di tutti, Maze. Maze funzionava in rete, con fino a 8 Imlac PDS-1 (dei microcomputer molto semplici, dotati di primitive capacità grafiche) che fungevano da “client” connessi ad un singolo “server” DEC PDP-10. I giocatori sui PDS-1 potevano navigare attraverso un ambiente condiviso, sparandosi contro; una sorta di antenato di giochi moderni tipo Counter-Strike. Maze divenne un grande successo, nonché un serio problema per i burocrati tipo Vezza; non solo un vero gioco da 8 giocatori spingeva il server PDP-10 ai suoi limiti, ma aveva anche la tendenza a far crashare del tutto questa macchina, che altri dovevano usare per lavorare davvero. Vezza chiese più e più volte che venisse rimosso dai sistemi, ma cercare di imbrigliare il caos del Dynamic Modeling Group era una causa persa in partenza. Fra gli altri progetti “divertenti”, Lebling creò anche un quiz, che permetteva agli utenti di ARPANET di inviare le domande scritte da loro e che alla fine poteva contare su un database di migliaia di domande.

 

E poi, nella primavera del 1977, Adventure arrivò al MIT. Come nei dipartimenti di informatica di tutta la nazione, anche qui il lavoro sostanzialmente si fermò mentre tutti cercavano di risolverlo; alla fine i membri del Dynamic Modeling Group conquistarono quel “last lousy point” [cioè “quell’ultimo disgustoso punto”; ndAncient] con l’aiuto di uno strumento di debugging. Forti di questo risultato, iniziarono (come molti altri hacker, in molti altri luoghi) a pensare a come avrebbero potuto creare un Adventure migliore. A differenza di altri, però, il  Dynamic Modeling Group aveva degli strumenti a portata di mano che lo metteva in una posizione più che unica per riuscirci.

Abbiamo lasciato Scott Adams alla fine del 1979, impegnato a spingere tutta questa cosa delle avventure al proverbiale “livello successivo”, con un solido catalogo di titoli già disponibili per numerose piattaforme, con il nome più noto di tutta la nascente industria dei giochi per computer, e con una società nuova di zecca (la Adventure International), pronta a pubblicare le opere sue, e quelle di altri, sotto il suo marchio editoriale. L’anno successivo lo vide quindi impegnato a mettere a frutto tutto quel potenziale, e anche di più, per andare così ad occupare un posto di primissimo piano nella nascente industria.

 

La Adventure International negli anni successivi crebbe a passi da gigante, pur restando (come del resto ogni altra cosa toccata da Adams) indelebilmente marchiata dalla personalità del suo fondatore. I suoi cataloghi erano pieni di un’accozzaglia di software di ogni genere. La Adventure International in un certo senso era i Grandi Magazzini dell’industria del software. Oltre alle prevedibili avventure testuali scritte da Adams e da altri (e molte di queste usavano comunque l’engine di Adams), c’erano dei cloni dei titoli da sala giochi (“di gran lunga superiore a ogni altro gioco per il TRS-80 ispirato a Space Invader pubblicato fin qui”, recitava una pubblicità di Invaders Plus, facendo sfoggio più di onestà che di saggezza legale), giochi di strategia spaziale (Galactic Empire e Galactic Trader), programmi di scacchi (“anche se è disponibile una scacchiera visualizzata su schermo, per giocare si consiglia di munirsi di una vera scacchiera.”), adattamenti di giochi da tavolo (Micropoly, anche lui talmente avventato da pubblicizzarsi come un clone del Monopoli già dal testo promozionale), e perfino TRS-80 Opera, che consentiva di ascoltare la ouverture del Guglielmo Tell di Rossini attraverso una radio a transistor posizionata i prossimità del lettore di cassette della macchina (la mancanza di un’adeguata protezione dalle interferenze radio sul TRS-80 non era poi sempre così negativa, dunque…). E, per quando il tempo dello svago era finito, c’erano anche programmi di matematica, spooler di stampa, strumenti per programmare, programmi di disegno, e software educativo (quest’ultimo ovviamente presentava la solita passione per gli Stati e le loro capitali, così comune fra i primi programmatori). Tutto questo software era relativamente poco costoso (solitamente era prezzato $9.95 o $14.95) e di qualità… variabile. E, pur tuttavia, era emozionante camminare per le corsie virtuali dei cataloghi della Adventure International, osservando gli espositori stracolmi dei prodotti di una nuova industria in espansione e chiedendosi quali altre idee pazze (per non dire bislacche) avremmo trovato nella corsia successiva. E, ad aleggiare su tutta questa scena, c’era sempre la personalità straripante di Adams, che sarebbe rimasto per tutta la vita breve ma intensa della Adventure International un capo d’azienda insolitamente visibile (e infatti -leggendo le scritte legali in piccolo sui suoi prodotti- si scopre che la Adventure International in realtà era solo “una divisione della Scott Adams Inc.”).

 

Il 1980 rappresenta un momento cruciale per l’industria del software d’intrattenimento. A parte un paio di eccezioni tipo Microsoft e Automated Simulations, i giochi per computer fino ad allora erano stati distribuiti come prodotti secondari, per mano di soggetti non professionisti che si limitavano ad appendere le loro Ziploc nei negozi di computer locali e che al massimo aderivano ai servizi di distribuzione per hobbisti (tipo quelli delle riviste SoftSide e Creative Computing). Ora invece le compagnie come la Adventure International, e altre che iniziavano ad apparire più o meno contemporaneamente, iniziarono a rendere più professionale il settore. Nel giro di pochi anni i sacchetti Ziploc sarebbero stati sostituiti da dei massicci cartonati colorati, pieni di manuali patinati e altri gadget, e quei “soggetti non professionisti” con gli uffici in camera o in casa sarebbero stati sostituiti da veri studi di sviluppo i cui membri facevano quello di lavoro. I giochi per computer stavano diventando un business vero e proprio, attirando sulla scena più risorse, che presto avrebbero permesso creazioni più grandi e ambiziose di qualunque cosa si fosse vista fino ad allora, ma che al tempo stesso avrebbero complicato le cose e avrebbero inevitabilmente condotto a quella tipica perdita di innocenza che sempre consegue alla monetizzazione di una passione.

 

Alla luce della crescita esplosiva della sua compagnia, non sorprende che la creazione di nuove avventure da parte di Adams avesse subito un drammatico rallentamento. Una parte delle sue energie furono assorbite -e nemmeno questa sarebbe stata l’ultima volta che ciò sarebbe avvenuto!- con la ripubblicazione dei suoi giochi già esistenti. Tutti ricevettero delle illustrazioni di copertina fatte a penna e acquerello grazie a un artista noto solo come “Peppy”, il cui stile colorato, seppur poco rifinito, si adattava perfettamente al folle entusiasmo della prosa di Adams.
 

Nel 1980 la Adventure International pubblico solo due nuove avventure scritte da Adams: la parodia western chiamata Ghost Town a primavera e Savage Island Part One (prima parte di due) a Natale, un'avventura che fu pubblicizzata come abbastanza difficile da risultare impegnativa anche per i giocatori più hardcore fra i giocatori hardcore.

Ho ritenuto di dare un’occhiata più approfondita alla prima di queste due, per vedere quali progressi avesse fatto l’arte di Adams dopo The Count. La risposta, triste ma semplice, è: nessun progresso, davvero. Anzi, ci sono state delle involuzioni da molti punti di vista. L’ambientazione western era evidentemente solo l’ennesima in una lista di generi che Adams intendeva coprire, visto che essa contribuisce ben poco a dare forma all’esperienza di gioco. Ghost Town è una caccia al tesoro senza trama, proprio come Adventureland; come se The Count non ci fosse mai stato: “DROP TRESURES”, e poi “SCORE.” Sigh.

 

 

 

 

 

Quel che è peggio è che anche come caccia al tesoro Ghost Town non è né divertente, né soddisfacente. Se si escludono un paio di battute (tipo la risposta a VAI SPECCHIO - “Non sono Alice!”), Ghost Town ha perso un po’ di quel calore amichevole che un po’ ci faceva perdonare le incertezze dei primi giochi. L’utile comando HELP, con i suoi velati suggerimenti, è sparito del tutto, mentre gli enigmi sono involuti in una variegata raccolta di peccati di design. Adams ha lentamente fatto impennare la difficoltà dei suoi giochi con ogni titolo successivo che ha scritto, come se si aspettasse che il giocatore li affrontasse in sequenza e arrivasse quindi ben preparato a Ghost Town. Presumo che in astratto possa anche essere un approccio ragionevole, ma nella realtà nessuna preparazione è possibile per gli enigmi di Ghost Town. Perfino quelli meno discutibili richiedono comunque una notevole dose di conoscenze esterne, tipo la composizione della polvere da sparo o la capacità di tradurre il codice morse.
 

 

 

Inutile dire che nel 1980, quando ancora Wikipedia non era a un click di distanza da noi, questo genere di cose poteva richiedere una spedizione in biblioteca. Altri enigmi invece ci richiedono di visualizzare la stanza in questione esattamente come Adams se l’era raffigurata, nonostante le sue celeberrime descrizioni minimali, solitamente limitate all'elenco degli oggetti all’interno.

Altri ancora ricompensano invece la cieca caparbietà del giocatore, piuttosto che le sue intuizioni, come quello che ci costringe a trascinarci un badile per tutta la mappa, provando a scavare in ogni singola stanza sperando che sbuchi fuori qualcosa. E poi ancora -forse il peggiore di tutti-  vanno menzionate le infinite battaglie con il parser. Non voglio nemmeno pensare a quanto tempo potrebbe servire al giocatore medio per intuire che per far muovere il cavallo deve dire GIDYUP. Né voglio pensare a quante volte siano stati mischiati inutilmente insieme carbone, zolfo, e nitrato di potassio prima di aver finalmente scritto FAI POLVERE DA SPARO. A volte il parser sembra non solo tecnicamente limitato, ma anche volutamente crudele!
 

 

 

Scrivere solo POLVERE DA SPARO, invece che CON POLVERE DA SPARO al prompt di cui sopra restituisce un messaggio d'errore generico.

 

È forte la tentazione di concludere che Adams semplicemente non avesse quella visione che sarebbe stata necessaria per poter spingere ancora oltre le avventure testuali. È una tentazione, ma probabilmente non sarebbe corretto. Per un paio di anni Adams tenne una rubrica sulla rivista SoftSide. Nel novembre del 1980 annunciò che aveva in progetto un nuovo sistema per avventure testuali chiamato Odyssey, che si sarebbe avvantaggiato dei sistemi dotati di floppy drive nello stesso modo utilizzato da Microsoft Adventure, e cioè utilizzando lo spazio sui dischetti come memoria ausiliare. I suoi progetti erano a dir poco ambiziosi:

 

 

Il concetto tecnico dietro Odyssey è incredibilmente simile a quello che sarebbe stato utilizzato di lì a poco da una minuscola startup del Massachusetts chiamata Infocom. È però interessante notare che Marc Blank e Stu Galley della Infocom avevano già delineato in astratto le basi della loro virtual machine, la  “Z-Machine”, in un articolo su Creative Computing [Il link non è più attivo, pertanto non è stato possibile recuperare l'articolo] giusto un paio di mesi prima che Adams scrivesse queste righe. Che sia stato ispirato proprio da quell'articolo?

 

Tale strategia rimase profittevole per qualche altro anno ancora, ma è difficile oggi non chiedersi dove lo avrebbe portato la strada che scelsce di non intraprendere, il territorio che cedette senza combattere alla Infocom e agli altri. Dal 1980 in poi, Adams è più interessante come uomo d'affari e come facilitatore delle opere altrui, che come artista di software vero e proprio. Al riguardo, la prossima volta vi voglio parlare un po' di qualche altra creazione interessante che affiancava le avventure di Adams nel guazzabuglio del catalogo della Adventure International.

 

Se volete provare Ghost Town, ecco qui una versione [Il link non è più attivo, per cui non è attualmente possibile reperire il file] che potete caricare nell'emulatore MESS utilizzando la funzione “Devices -> Quickload”.