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