Come Vendettero Zork
The Digital Antiquarian (la traduzione ufficiale italiana)



Rieccoci fedeli lettori al nostro appuntamento settimanale con l'Avventura (con la "A" maiuscola). E dopo aver esplorato gli aspetti tecnici dello sviluppo di Zork e della sua incredibile conversione per le umili piattaforme casalinghe dell'epoca, il sapiente Antiquario ci racconterà di quando la neonata Infocom impegnò tutte le risorse di cui disponeva per presentare la propria creatura al grande pubblico.
Nel 1980 il mercato videoludico era praticamente agli albori
 e le avventure testuali in circolazione erano, più o meno, quelle di Scott Adams pubblicate dalla Adventure International e poco altro...niente a che vedere con Zork!
 
Ma prima, l'imperdibile 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
 
Buona lettura avventurieri... e raccogliete tanti zorkmid!
 
Festuceto
 
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:
 
Scott e Marc dimostrarono che Zork I poteva vivere al suo interno, avviando il gioco e riuscendo a fare dei punti con l’incantamento “N.E.OPEN.IN.” (che di certo non sono meno memorabili del “Come here, Mr. Watson; I want you!” di Alexander Graham Bell). 
 
È 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.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

ZIL e la Z-Machine
The Digital Antiquarian (la traduzione ufficiale italiana)


Bentrovati fedeli lettori di OldGamesItalia e del Digital Antiquarian, vi siete mai chiesti come sia possibile giocare a Zork sui moderni computer e tablet? Nulla di più semplice: per prima cosa, come ogni avventuriero che si rispetti, munitevi di foglio e matita, poi scaricate la nostra epica traduzione di Zork, infine procuratevi un interprete di Z-Machine.
La Z-Machine, ecco, è solo grazie alla mitica "Macchina Z" se Zork e la sua ricca eredità sono stati convertiti per una moltitudine di piattaforme e giocati da milioni di persone per decenni fino ai giorni nostri, un'impresa che nel 1979 era quasi impossibile... ma non per Joel Berez e Marc Blank
L'Antiquario ci trasporta in quel delicato momento della storia di Infocom.
 
La rassicurante lista degli articoli del ciclo 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
 
Buona lettura avventurieri... e non perdete la bussola!
 
Festuceto
 
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:
 
Dave esaminò la sua mappa completa di Zork e tracciò un confine intorno a una porzione della stessa che includeva circa 100 location: tutte le stanze all’aperto e un’ampia sezione intorno alla Round Room. Lo scopo era quello di creare uno Zork più piccolo, che rientrasse nei limiti fissati dal progetto di Joel e Marc. Tutto quello che restava fuori sarebbe stato messo da parte per un altro gioco, da realizzare in un altro momento.
 
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:
 
<OBJECT ["LAMP" "LANTE" "LIGHT"]
["BRASS"]
"lamp"
<+ ,OVISON ,TAKEBIT ,LIGHTBIT>
LANTERN
()
(ODESCO "A battery-powered brass lantern is on the trophy case."
ODESC1 "There is a brass lantern (battery-powered) here."
OSIZE 15
OLINT [0 >])>
 
E questo è il medesimo oggetto in ZIL:
 
<OBJECT LANTERN
                (LOC LIVING-ROOM)
                (SYNONYM LAMP LANTERN LIGHT)
                (ADJECTIVE BRASS)
                (DESC "brass lantern")
                (FLAGS TAKEBIT LIGHTBIT)
                (ACTION LANTERN-F)
                (FDESC "A battery-powered lantern is on the trophy
               case.")
                (LDESC "There is a brass lantern (battery-powered)
               here.")
                (SIZE 15)>
 
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.  

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

 

La Nascita di Infocom
The Digital Antiquarian (la traduzione ufficiale italiana)

Ormai persino i lettori più distratti avranno capito cosa bolle in pentola, quale segreto si annida tra le pagine polverose di OldGamesItalia. Dopo la gloriosa traduzione di Zork I - The Great Undreground Empire, è in cantiere la localizzazione del secondo capitolo della fortunata trilogia di Infocom.
E quale modo migliore di celebrarne la pubblicazione che pubblicare gli articoli del nostro Antiquario Digitale dedicati proprio alla genesi di Zork e di Infocom? Ed è per l'appunto dell'effettiva nascita di questa mitica azienda di videogiochi, agli albori dell'era dei microcomputer, che tratterà l'articolo di oggi.
 
Ma prima, l'immancabile indice degli articoli del ciclo Infocom:
 
La Nascita della Infocom
ZIL e la Z-Machine
Come Vendemmo Zork
Giochi a 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
 
Buona lettura avventurieri... e portate le lanterne!
 
Festuceto
 
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).

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

 

Zork sul PDP-10
The Digital Antiquarian (la traduzione ufficiale italiana)

Continua il ciclo di articoli dedicato alla nascita di Infocom e ai primi tre capitoli della celebre serie di Zork. Sì avete letto bene: nel corso del nostro viaggio analizzeremo i primi tre capitoli di Zork. Contrariamente a quanto annunciato nell'ultimo editoriale, non ci limiteremo ai primi due titoli della leggendaria serie Infocom, ma chiuderemo la trilogia originale, com'è giusto che sia. 
Pertanto considerate l'indice riportato di seguito, soltanto parziale. Sarà nostra premura completarlo non appena sarà possibile, e se proprio non potete resistere, cliccate in fondo all'articolo per fiondarvi nel blog originale del "The Digital Antiquarian" ... ma non vorrete rovinarvi la sorpresa, vero?
 
A proposito, nel caso vi steste ancora chiedendo perché Zork sia così attuale qui su OldGamesItalia, vi consiglio di visitare attentamente la sezione "traduzioni" del nostro forum... 
Ecco il solito indice degli articoli:
 
Zork sul PDP-10
La Nascita della Infocom
ZIL e la Z-Machine
Come Vendemmo Zork
Giochi a 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
 
Buona lettura esploratori e ... attenti ai grue!
 
Festuceto
 
Uno dei tratti distintivi degli hacker è il non considerare mai un programma davvero completamente e definitivamente finito; ci sono sempre aggiunte da fare, angoli da smussare. E di certo Adventure, per quanto impressionante, lasciava ampio spazio ai miglioramenti. Dobbiamo poi aggiungere che Adventure arrivò al MIT attraverso Don Woods dell'AI Lab della Stanford, forse l'unico corso di informatica della nazione che aveva la statura per potersi confrontare alla lontana con quello del MIT. Gli studenti del MIT erano fieramente orgogliosi della propria Università. Anche se la Stanford aveva prodotto per prima un gioco d'avventura, il Dynamic Modeling Group del MIT avrebbe potuto quantomeno farlo meglio. E certo non nuoceva alla causa il fatto che il Project MAC e il Laboratory for Computer Science (per non parlare dello stesso Dynamic Modeling Group) avessero donato loro degli ottimi strumenti con cui affrontare il problema.
 
Adventure era stata implementato in FORTRAN, un linguaggio non particolarmente adatto alla creazione di un'avventura testuale. E infatti il FORTRAN non poteva nemmeno gestire nativamente le stringhe di lunghezza variabile, lasciando a Crowther e Woods il compito di arrangiare qualche soluzione, come del resto dovettero fare anche con molti altri problemi. Come sappiamo, entrambi erano programmatori molto talentuosi e ci riuscirono al meglio. E così gli hacker del Dynamic Modeling Group (la cui opinione del FORTRAN era solo un gradino superiore a quella che avevano del BASIC) non vedevano l'ora di progettare il proprio gioco d'avventura con il proprio linguaggio, l'MDL. Non solo l'MDL (essendo un linguaggio progettato, almeno in parte, per la ricerca nel campo dell'Intelligenza Artificiale) poteva vantare capacità di gestione di stringhe relativamente robuste, ma offriva anche la possibilità di definire dei nuovi “data type” complessi, adatti per compiti specifici, e la possibilità di inserire direttamente in tali strutture dei pezzi di codice. Lasciatemi provare a spiegarvi perché tutto questo era così importante.
 
Inizieremo con la stanza di apertura di Zork, il gioco che alla fine fu prodotto dal Dynamic Modeling Group in risposta ad Adventure. La descrizione di tale stanza al giocatore [nella nostra traduzione italiana di Zork I; ndAncient] appare così:
 
 
West of House
This is an open field west of a white house, with a boarded front door.
There is a small mailbox here.
A rubber mat saying 'Welcome to Zork!' lies by the door.
 
Questo è il codice sorgente originale in MDL che descrive la stanza:
 
<ROOM "WHOUS"
"This is an open field west of a white house, with a boarded front door."
"West of House"
<EXIT "NORTH" "NHOUS" "SOUTH" "SHOUS" "WEST" "FORE1"
"EAST" #NEXIT "The door is locked, and there is evidently no key.">
(<GET-OBJ "FDOOR"> <GET-OBJ "MAILB"> <GET-OBJ "MAT">)
<>
<+ ,RLANDBIT ,RLIGHTBIT ,RNWALLBIT ,RSACREDBIT>
(RGLOBAL ,HOUSEBIT)><
 
Praticamente tutto ciò che il programma deve sapere di questa stanza è incapsulato qui dentro in modo ordinato. Analizziamolo, linea per linea. Il tag “ROOM” [stanza] all'inizio definisce questa struttura come una stanza, chiamata brevemente “WHOUS” [abbreviazione di "West of House", cioè "A Ovest della Casa", ndAncient]. La linea di testo seguente è la descrizione della stanza che il giocatore vede quando vi entra la prima volta o quando digita “GUARDA”. “West of House” è invece il nome completo della stanza, quello che appare come titolo della descrizione della stanza e nella linea di stato in cima allo schermo, ogni volta che il giocatore si trova in questa stanza. Poi abbiamo un elenco di uscite dalla stanza, andare a nord porta il giocatore a “North of House,” a sud lo porta a “South of House”, a ovest in una di diverse stanze che compongono la “Foresta”. Cercare di andare a est produrrà invece uno speciale messaggio di fallimento, che riferirà al giocatore di non essere in possesso di una chiave per aprire la porta, anziché il generico: “Non puoi andare in quella direzione”. Subito dopo abbiamo gli oggetti che si trovano nella stanza all'inizio del gioco: la porta frontale, la cassetta delle lettere, e il tappetino di benvenuto. Quindi una serie di "flag" definisce altre proprietà della stanza: che è asciutta anziché invasa dall'acqua, che è illuminata anche se il giocatore non ha con sé una lanterna accesa; che (essendo all'aperto) non ha pareti; che è “sacred” [“sacra”] (il che significa che il ladro -un personaggio che vaga in giro, infastidendo il giocatore in modo non dissimile dai nani e dal pirata di Adventure- non può venire qui). E, alla fine, l'ultima linea associa questa stanza alla "white house" o, per essere più precisi, la associa a una parte della “regione casa” della geografia del gioco.
 
Ogni oggetto e ogni personaggio del gioco è definito da un simile blocco, che spiega quasi tutto ciò che il gioco deve sapere al riguardo. Va aggiunto anche che le abilità e le capacità speciali di oggetti e personaggi sono descritti come parti di essi, utilizzando dei collegamenti a delle sezioni speciali del codice, create appositamente. Per questo una volta che l'impalcatura del codice alla base di tutto questo fu creata (cosa che, ovviamente, non era affatto banale), aggiungere nuovo contenuto a Zork era prevalentemente una questione di aggiungere più stanze, più oggetti, e più personaggi, senza bisogno ogni volta di rituffarsi nell'"engine" che muoveva il tutto; solo le capacità speciali degli oggetti e dei personaggi dovevano essere programmate da zero e collegate nei punti giusti. Componendo il mondo da una raccolta di “oggetti” integrati, gli hacker del Dynamic Modeling Group stavano inconsapevolmente dirigendosi verso un nuovo paradigma nella programmazione, che sarebbe giunto alla ribalta dell'informatica solo alcuni anni dopo: la programmazione orientata agli oggetti, in cui i programmi non sono rigorosamente divisi nel codice che li esegue e nei dati che esso manipola, ma sono piuttosto costruiti dall'interazione di oggetti semi-autonomi che contengono il proprio codice e i propri dati. Un tempo considerata praticamente la soluzione a ogni problema (forse persino alla fame nel mondo), oggigiorno in certe aree, ci sono delle resistenze (probabilmente giustificate) alla imposizione, applicata a prescindere, della teoria della programmazione orientata agli oggetti operata da certi linguaggi, come il Java. Sia come sia, la programmazione orientata agli oggetti resta praticamente la soluzione ideale nella creazione delle avventure testuali. Per mostrarvi cosa intendo, guardiamo all'alternativa, illustrata da Adventure (scritto in FORTRAN, un linguaggio altamente NON orientato agli oggetti).
 
Ad ogni stanza di Adventure è assegnato un numero da 1 (la location iniziale, naturalmente all'esterno di un piccolo edificio di mattoni) fino a 140 (stavolta, meno naturalmente, un vicolo cieco in un labirinto). Per trovare la descrizione completa della stanza (quella che viene mostrata al giocatore quanto vi entra per la prima volta o quando la GUARDA) il programma scava nella prima tabella di un file esterno di dati, confrontando il numero della stanza alle rispettive voci.
 
1
1 YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.
1 AROUND YOU IS A FOREST.  A SMALL STREAM FLOWS OUT OF THE BUILDING AND
1 DOWN A GULLY.
 
Un'altra tabella mostra invece la descrizione breve che viene visualizzata quando si entra in una stanza già visitata:
 
1 YOU'RE AT END OF ROAD AGAIN.
 
E ora viene il bello. Un'altra tabella ancora ci dice cosa ci aspetta in ogni direzione cardinale.
 
1 2 2 44 29
1 3 3 12 19 43
1 4 5 13 14 46 30
1 5 6 45 43
1 8 63
 
La prima linea di cui sopra ci dice che quando siamo in stanza 1, possiamo andare in stanza 2 digitando una delle tre voci di un'altra tabella ancora; in questo caso: “ROAD o HILL” (voce 2); “WEST” or “W” (voce 44); or “UPWAR” (infatti le parole vengono confrontate sulla base dei primi 5 caratteri soltanto [in questo caso la parola completa sarebbe UPWARD, formata da 6 caratteri, che significa SU; ndAncient], “UP,” “ABOVE,” or “ASCEN” (voce 29). In modo del tutto analogo, le definizioni degli oggetti sono sparpagliate su più tabelle all'interno del data file. Quindi, anche se Adventure tenta almeno in parte di astrarre il suo "engine" dai dati che compongono il suo mondo (collocando questi ultimi in un "data file" esterno), modificare il mondo stesso è un procedimento rognoso e foriero di errori, che consiste nell'editare più tabelle criptiche. I primi "engine" per avventure testuali sui microcomputer, come quelle di Scott Adams, funzionano tutti in questo modo. E anche se era comunque possibile sviluppare dei tool che alleviassero il fardello di modificare a mano i "data file", il sistema di Zork basato sull'MDL è flessibile e programmabile in un modo ben superiore a quello di questi sistemi: non essendo possibile inserire del codice all'interno degli oggetti del mondo di gioco, creare oggetti non standard in Adventure o in un gioco di Scott Adams richiedeva generalmente di andare a modificare il codice dell'"engine"; non proprio il massimo.
 
Per questo l'MDL era semplicemente migliore per scrivere un'avventura testuale che fosse capace di rappresentare limpidamente un mondo vasto, in un modo che fosse anche leggibile e facilmente mantenibile. Era quasi come se l'MDL fosse stato progettato a questo scopo. Ed effettivamente, se avete usato un linguaggio di programmazione di IF più moderno (come Inform 6), sareste rimasti sorpresi da quanto poco sia cambiato l'approccio nella definizione del mondo rispetto ai giorni dell'MDL di Zork. (Inform 7, uno degli ultimi, e migliori, tool per lo sviluppo di IF si è allontanato dal modello della programmazione orientata agli oggetti in favore di un approccio basato su regole più leggibili -se non addirittura più “letterarie”-. Basti dire che i meriti e gli svantaggi dell'approccio di Inform 7 sono un argomento troppo complesso per essere affrontato in questa sede. Forse ne riparleremo fra 20 anni, quando finalmente il Digital Antiquarian si occuperà dell'anno 2006...)
 
E gli hacker del Dynamic Modeling Group avevano ancora un altro asso nella loro manica.
 
Il MIT aveva all'attivo importanti ricerche sulla comprensione del linguaggio naturale nel computer, che risalivano almeno fino a Joseph Weizenbaum e al suo sistema ELIZA del 1966. E se quel programma alla fin fine era poco più di un elaborato trucco da salotto, esso però ispirò altri e più rigorosi tentativi di far parlare a un programma un buon inglese. È estremamente noto quello che fra il 1968 e il 1970 fu sviluppato da Terry Winograd sotto il nome di SHRDLU, che simulava un modello di mondo composto di blocchi. L'utente poteva chiedere al programma di manipolare questo mondo, spostando i blocchi di posto in posto, impilandoli, e così via, il tutto limitandosi a digitare le sue richieste con delle semplici frasi imperative in lingua inglese. Era perfino possibile porre delle semplici domande al computer, per sapere ad esempio quale blocco fosse collocato in una determinata posizione. Piuttosto sopravvalutato all'epoca (come gran parte della ricerca sull'intelligenza artificiale), quasi fosse un passo decisivo verso HAL, SHRDLU riuscì comunque a dimostrare che, almeno all'interno di un dominio molto ristretto, è possibile per un programma parlare e “comprendere” realmente un significativo sottoinsieme della lingua inglese. Partendo dalla tradizione di SHRDLU, gli hacker del Dynamic Modeling Group crearono un parser per avventure testuali che era oggettivamente il primo mai creato a essere degno del termine. E se Adventure se la cavava con un semplice riconoscimento delle parole (stratagemma reso palese dal fatto che “LAMPADA PRENDI” funziona esattamente come “PRENDI LAMPADA”), Zork comprendeva davvero non solo il verbo e il complemento oggetto, ma anche le preposizioni, il complemento di termine, le congiunzioni, la punteggiatura, e perfino gli articoli. A dare un contributo essenziale al raggiungimento di tale obbiettivo fu nuovamente l'MDL che (essendo un linguaggio ideato pensando alla ricerca sull'IA) aveva delle straordinarie capacità di manipolazione delle stringhe. Il parser che riuscirono a ideare si rivelò una creazione mirabile, che si sarebbe contraddistinta per molti anni a venire (un'eternità, allora come ora, nel mondo dell'informatica). Ma ora sto andando troppo avanti.
 
La strada che condurrà a Zork iniziò nel Maggio del 1977, quando Dave Lebling creò un semplicissimo parser e un semplicissimo "engine" piuttosto simile a quello di Adventure, dal quale Marc Blank e Tim Anderson crearono il loro primo gioco di quattro stanze, come prototipo. A quel punto Lebling si prese una vacanza di due settimane, mentre Blank, Anderson, e Bruce Daniels "hackeravano" come pazzi, creando la struttura base di Zork così come la conosciamo ancora oggi. Il nome stesso era una parola priva di senso presa dal gergo parlato al MIT; una parola che si usava nelle situazioni di tensione al posto di un altra più scurrile: “Zorka quel maledetto codice!”, quando una linea di codice non ne voleva sapere di funzionare, e cose del genere. Ogni programmatore ha qualche parola tipo questa che usa per programmi, variabili, funzioni, e così via, quando sta semplicemente facendo esperimenti e non ha tempo di inventarsi un nome migliore (negli ultimi 25 anni il mio personale “go-to placeholder” è stata la parola “fuzzy”, per ragioni troppo imbarazzanti e stravaganti per spiegarle qui). Nel caso di Zork, però, un nome vero e proprio tardava a venir fuori. E così il gioco restò Zork per i primi sei mesi della sua esistenza.
 
Quando Lebling tornò dalla vacanza per riprendere a lavorare al gioco, c'erano già delle solide basi. Tutto il design era modulare; questo significava (come dimostrato sopra) che era facile aggiungere altre stanze, altri oggetti, altri enigmi, ma anche che ogni parte della sottostante tecnologia poteva essere facilmente rimossa, migliorata, e inserita di nuovo. Il parser in particolare migliorò gradualmente da uno a due parole (“intelligente quasi quanto quello di Adventure”), fino a diventare la creazione allo stato dell'arte che era alla fine; il tutto prevalentemente grazie all'impegno di Blank, che ne divenne ossessionato fino a produrne “40 o 50” iterazioni.
 
Negli anni successivi la Infocom avrebbe sviluppato una storia e una mitologia, complesse ma anche comiche, intorno a Zork e al suo “Grande Impero Sotterraneo”, ma in questi primissimi giorni di sviluppo gli autori erano interessati al mondo di gioco solo come luogo in cui ambientare delle scene accattivanti ma anche ridicolmente eterogenee, e -ovviamente- degli enigmi da risolvere, nel solco della tradizione inaugurata da Don Woods con Adventure. E infatti il mondo di Zork rende omaggio ad Adventure quasi al punto da sembrare inizialmente un suo remake. Come Adventure, si inizia all'aria aperta, accanto ad una piccola casa; come in Adventure c'è una piccola area esterna da esplorare, ma il succo del gioco si svolge sottoterra; come Adventure lo scopo è raccogliere tesori e riportarli dentro la casa, che serve quindi da base delle nostre operazioni; ecc. ecc. Solo andando molto avanti nel gioco, Zork diverge davvero da questo schema e assume una sua distinta personalità, con location fantasiose ed enigmi molto più intricati, resi possibili dallo stupefacente parser. Ovviamente tutte queste parti furono ideate in seguito, quando il team di sviluppo aveva più esperienza e quando il parser era ormai molto migliore di quello iniziale. Personalmente darò uno sguardo approfondito a Zork nella sua versione per microcomputer, piuttosto che nella sua incarnazione per PDP-10, ma se siete interessati a saperne di più sull'implementazione originale senza capo né coda, vi invito a dare un'occhiata all'approfondito play-through di Jason Dyer.
 
Come Adventure, anche Zork girava su un DEC PDP-10. A differenza di Adventure però, girava sotto il sistema operativo che ospitava anche l’ambiente MDL, l’Incompatible Timesharing System (così chiamato, con un po’ di sano humour da hacker, in sarcastica risposta ad un precedente Compatible Timesharing System; anche qui però -scusate se insisto- vi rimando a Hackers di Levy per un eccezionale racconto delle sue origini). L’Incompatible Timesharing System era sostanzialmente unico del MIT, l’istituzione che lo aveva sviluppato. E aveva un elemento di estrema originalità: in uno stravagante (ma qualcuno lo chiamerebbe folle) tributo alla tradizione degli hacker di totale apertura e trasparenza, non aveva password; anzi, non aveva nessun tipo di sicurezza. Proprio chiunque poteva loggarsi e fare ciò che voleva. Questo creò una specie di community di coloro che gli hacker del MIT chiamavano “gente a caso dalla rete”: persone che non avevano niente a che fare con il MIT, ma che godevano, da qualche parte, di un accesso a un computer connesso ad ARPANET e che si fermavano per rovistare nel sistema, solo per vedere cosa stessero facendo quei folli hacker del MIT. La macchina del Dynamic Modeling Group aveva raccolto intorno a sé una community considerevole di gente a caso, grazie a un precedente gioco di quiz. Non ci volle molto prima che scoprissero Zork (anche se non era mai stato annunciato ufficialmente) e che si imbarcassero nell’avventura. Ben presto questo gioco in sviluppo si guadagnò una certa reputazione su ARPANET. Proprio a vantaggio di questa community di giocatori, gli sviluppatori iniziarono a collocare una copia dell’U.S. News and Dungeon Report in una delle prime stanze, che elencava tutti gli ultimi cambiamenti e le ultime aggiunte a questo mondo virtuale che la gente stava esplorando. La gente a caso dalla rete, insieme ad altri utenti più “legittimati” di base al MIT (fra cui anche John McCarthy, il padre dell’intelligenza artificiale), servirono da team allargato di beta-test; gli implementatori potevano vedere quello che queste persone provavano a fare, per non dire ciò di cui si lamentavano, e modificavano il gioco di conseguenza. In particolare, molti dei miglioramenti al parser furono senza dubbio incentivati da questo processo; chiunque abbia mai sottoposto una propria avventura testuale a un beta-test, sa bene che non si può semplicemente prevedere a priori gli infiniti modi in cui le persone proveranno a esprimere certe cose.  
 
La crescente popolarità di Zork sollevò delle inevitabili preoccupazioni sull’eccessivo carico generato da questi giocatori sul sistema PDP-10 del Dynamic Modeling Group, che a conti fatti era finanziato dal Dipartimento della Difesa e che quindi -teoricamente- sarebbe dovuto servire per vincere la Guerra Fredda. Al tempo stesso c’erano altri che chiedevano una copia del gioco, per poterla installare sulle proprie macchine. Anche se sviluppato e utilizzato principalmente sotto l’Incompatible Timesharing System, esisteva però una versione dell’ambiente MDL che girava su un altro sistema operativo per PDP-10, il TOPS-20, pubblicato dalla DEC per la prima volta nel 1976 e pubblicizzato come una versione più avanzata e user-friendly del TOPS-10. A differenza dell’Incompatible Timesharing System, il TOPS-20 era assai diffuso al di fuori del MIT. Gli hacker del Dynamic Modeling Group modificarono quindi Zork quanto bastava per farlo girare sul TOPS-20 e iniziarono a distribuirlo a tutti gli amministratori che gliene chiedevano una copia. Alla fine dell’anno tutte le macchine della nazione ospitavano Zork ed era stata perfino predisposta una "mailing list" per informare i vari amministratori delle espansioni e dei miglioramenti che venivano apportati.
 
Gli hacker del Dynamic Modeling Group erano generosi, ma non quanto lo era stato Don Woods con Adventure. Distribuirono Zork solo come file criptati, che erano eseguibili in un ambiente MDL ma che non erano leggibili (né modificabili) a livello di codice sorgente. Arrivarono perfino a modificare il proprio sistema di sviluppo Incompatible Timesharing System, celebre per la sua mancanza di sicurezza, aggiungendo una protezione esclusivamente alla cartella che conteneva il codice sorgente di Zork. Tuttavia gli hacker non si smentiscono mai e ben presto uno della DEC aveva già penetrato il velo. Dalla “History of Zork” della Infocom:
 
[La sicurezza] fu infine battuta da un hacker del sistema della Digital: usando un’arcaica (non che ne sia mai esistita una diversa) documentazione dell’Incompatible Timesharing System, riuscì a capire come modificare il sistema operativo. Sapendo il fatto suo, riuscì anche a capire come funzionava la nostra modifica per proteggere la cartella del codice sorgente. A quel punto era solo questione di decriptare i sorgenti, il che ben presto si ridusse a intuire la chiave che avevamo usato. Ted non ebbe difficoltà a procurarsi il tempo che gli serviva sulla macchina: aveva appena trovato una macchina TOPS-20 che era sottoposta agli ultimi test e vi avviò un programma che tentava ogni chiave finché una non gli restituì qualcosa che aveva le sembianze di un testo. Dopo meno di un giorno di lavoro, aveva una copia leggibile del sorgente. Dovemmo ammettere che, chiunque si fosse preso la briga di fare tutto ciò, di certo se lo meritava... Tutto questo produsse altre conseguenze in seguito.
 
Riguardo a queste “altre conseguenze”:
 
Ad un certo punto, alla fine del 1977, gli hacker del Dynamic Modeling Group decisero che la loro creazione aveva davvero, davvero bisogno di un nome vero e proprio.  Lebling suggerì Dungeon, che non emozionò nessuno (Lebling incluso), ma a nessuno veniva in mente un’alternativa migliore. E così si optò per Dungeon. Ciò avvenne poco prima della breccia nella sicurezza appena descritta; per questo il gioco recuperato da quell’hacker della DEC non si chiamava Zork, bensì Dungeon. Poco dopo, al MIT giunsero voci di possibili azioni legali da parte (provate a indovinare) della TSR, il publisher di Dungeons and Dragons e di un gioco da tavolo di esplorazione di dungeon chiamato semplicemente Dungeon! La TSR era sempre particolarmente zelante nel querelare e gli avvocati del MIT, consultati dagli hacker del Dynamic Modeling Group, erano unanimemente concordi nel ritenere che la TSR non avesse nessun appiglio legale a cui aggrapparsi. Tuttavia, piuttosto che venir risucchiati in una controversia su un nome che oltretutto non piaceva a nessuno, decisero di ritornare al ben più memorabile Zork. E così, all’inizio del 1978, Dungeon tornò di nuovo a essere Zork, per poi mantenere quel nome per sempre.
 
Quasi per sempre. Vi ricordate quel codice sorgente che “Ted” aveva sottratto al MIT? Ebbene, arrivò nelle mani di un altro hacker del DEC, un certo Robert Supnik, che convertì il tutto per FORTRAN, più diffuso e portabile (seppur intrinsecamente e infinitamente meno adatto alle avventure testuali); fu uno sforzo erculeo che stupì perfino gli hacker del Dynamic Modeling Group. Poiché il gioco contenuto nel codice sorgente in MDL a cui aveva accesso si chiamava Dungeon, questa nuova versione rimase Dungeon. Inizialmente Supnik eseguì il porting con l'intenzione di portare Dungeon a girare su un DEC PDP-11 (che, a discapito di quanto sembra indicare il nome, non era un successore del PDP-10, ma piuttosto una macchina fisicamente più piccola, meno potente, e meno costosa). Con il codice sorgente in FORTRAN di Supnik libero di essere distribuito, tuttavia, il salto dal PDP-11 ad altre architetture fu assai breve. Perciò, in questi primi anni, il Dungeon di Supnik con ogni probabilità era più ampiamente distribuito, e quindi era anche più giocato, dello Zork del Dynamic Modeling Group. E quando arrivarono dei PC in grado di supportarlo, Dungeon sbarcò inevitabilmente anche su questi. E così alla fine degli anni ‘80 la situazione era incomprensibile per chi non conosceva tutta questa storia: c’era questo gioco gratuito, chiamato Dungeon, che era stranamente simile ai giochi commerciali ufficiali di Zork, che a loro volta erano molto simili a quest’altro gioco, Adventure, che all’epoca era disponibile in dozzine di versioni gratuite e commerciali. Ad oggi il Dungeon di Supnik è disponibile insieme al codice sorgente (finalmente libero) della versione per PDP-10 di Zork.
 
Tornando al MIT, lo sviluppo dello Zork vero e proprio continuò per tutto il 1978, seppur a un ritmo decrescente. Se si escludono delle correzioni minori di bug, che sarebbero proseguite per un paio di anni ancora, gli ultimi pezzi di Zork furono aggiunti nel Febbraio del 1979. A quel punto il gioco aveva assunto proporzioni davvero enormi: 191 stanze, 211 oggetti, un vocabolario di 908 parole con 71 verbi diversi (senza considerare i loro sinonimi). Gli implementatori avevano praticamente finito le idee per nuovi enigmi ed erano comprensibilmente esausti per il grande sforzo, e (qualora queste giustificazioni non fossero sufficienti) avevano completamente riempito l'unico MB circa di memoria che un programma MDL poteva utilizzare. E così accantonarono Zork e si spostarono su altri progetti.
 
La storia sarebbe potuta tranquillamente finire lì, con Zork che passa alla storia come un altro esempio, eccezionalmente significativo, di avventura testuale fiorita sulle macchine istituzionali negli anni successivi alla pubblicazione di Adventure; insomma, Zork come fosse un altro Mystery Mansion, Stuga (AGGIORNAMENTO: non proprio; leggete il commento di Jason Dyer [“Se vogliamo essere precisi, Stuga non può essere annoverato nel gruppo degli altri due titoli; fu distribuito commercialmente, e vendette piuttosto bene, e può essere definito lo Zork della Svezia”; ndAncient]), o HAUNT. Però non andò così, grazie ad Al Vezza, il direttore (dall’anima tutt’altro che hacker) del Dynamic Modeling Group, che qualche mese più tardi decise che il momento era giusto per entrare coi suoi collaboratori nella nuova, promettente frontiera dei microcomputer, avviando una software house. Non poteva però certo immaginare dove avrebbe portato questa sua decisione.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

 

Le Radici della Infocom
The Digital Antiquarian (traduzione ufficiale italiana)

 
Dopo una prolungata pausa estiva riprende la traduzione ufficiale del nostro "Antiquario" preferito e - come avranno intuito i lettori più scaltri - i prossimi articoli riguarderanno un argomento molto caro agli avventurieri e per certi versi di grande attualità, il perché vi sarà chiaro nei mesi a venire...
L'articolo del The Digital Antiquarian (versione italiana) che vi presentiamo inaugura il ciclo dedicato alla nascita della Infocom e ai primi due capitoli della serie di Zork.
 
Il percorso di lettura includerà i seguenti articoli:
 
Le Radici della Infocom
Zork sul PDP-10
La Nascita della Infocom
ZIL e la Z-Machine
Come Vendemmo Zork
Giochi a 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
 
Buona Lettura!
 
Festuceto
 
 
Zork
by Personal Software
 
Zork è un fantasy digitale di sfida definitiva. Creature immonde sono a guardia di tesori inimmaginabili. Labirinti ingarbuglieranno la tua quest. Quindi affila il tuo ingegno e scegli attentamente il tuo percorso attraverso il Grande Impero Sotterraneo. L’oggetto più improbabile potrebbe essere il solo in grado di salvarti la vita.
Nonostante tutto, potresti farcela. Scopri i 20 tesori di Zork, riportali nell’Armadietto dei Trofei, e vattene con la tua vita. Ma porta con te tutta l’astuzia e il coraggio che possiedi, perché in Zork… non si fanno prigionieri!
 
Zork, Il Grande Impero Sotterraneo è stato creato dalla Infocom inc. ed è disponibile per Apple II 32K e II Plus e S-80 32 K Model I Level II.
$39.95
 
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:
 
Avrebbero immesso nel computer informazioni segrete provenienti da varie fonti umane, quali pettegolezzi da feste od osservazioni alle parate militari del Primo Maggio, per cercare di delineare uno scenario probabile delle prossime mosse dei Sovietici. “L'idea consisteva nell'immettere in un potente calcolatore informazioni qualitative del tipo: 'Il comandante dell'aviazione ha bevuto due Martini' oppure ' Khrushchev non legge la Pravda il lunedì', ricorda Ruina. 'E il computer avrebbe recitato la parte di Sherlock Holmes, e ne avrebbe concluso che i russi stavano costruendo un missile MX-72, o qualcosa del genere.”
 
“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:
 
Se Licklider era carismatico e veniva affettuosamente chiamato “Lick” dai suoi studenti, Vezza non parlava quasi mai con i membri dell’LCS e di solito la mattina passava dall’ascensore al suo ufficio senza una minima deviazione, chiudendosi la porta alle spalle, per poi non vedere più nessuno per tutto il giorno. All’LCS c’era chi era scontento del suo stile dirigenziale, affermando che fosse freddo e che “non parlava mai con le altre persone se non vi era costretto, perfino con quelle che lavoravano all'interno del Lab.”
 
D’altro canto Lyon e Hafner hanno però questo da dire al riguardo:
 
Vezza faceva sempre una buona impressione. Era affabile ed eloquente in modo impeccabile; aveva un’arguta mente scientifica e istinti amministrativi di primissimo livello.
 
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.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto


Consulta l'indice per leggere gli articoli precedenti

Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

 

Retrogiochiamo insieme a Trinity - parte 8

Torniamo, ancora una volta, alle atmosfere di Trinity, classico Infocom e capolavoro di Brian Moriarty, giocato dal paziente The Ancient One.

In questo episodio raggiungiamo finalmente il Trinity Site, dove tutto ha inizio e tutto avrà fine.

Un 1980 Indaffarato
The Digital Antiquarian (traduzione ufficiale italiana)

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.
 

 
“LASCIA TESORO e poi PUNTEGGIO”
 
Derubiamo il saloon degli incassi semplicemente perché ci sono.
Doppio-sigh.
 

 
———-> Cosa devo fare?
“VAI AL BANCONE”
OK
“Sono dietro al bancone. Oggetti visibili
Cartello - ‘Suona il campanello per il servizio in camera’
 
———-> Cosa devo fare?
“PRENDI CASSETTA DEI SOLDI”
OK
 
———-> Cosa devo fare?
“GUARDA CASSETTA DEI SOLDI”
OK
Vedo
Niente di speciale
 
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.
 

 
Sono in un ufficio del telegrafo. Oggetti visibili:
Chiave del telegrafo, filo sbucciato. Grossa cassaforte.
Uscite evidenti: SUD
 
———-> Cosa devo fare? SCRIVI
Non so come “SCRIVERE”.
 
———-> Cosa devo fare? PREMI TASTO
Click
SPARK! * * * *
… …. .- -.- - - --- .--. .--. . .--.
 
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!
 
 
Sono in una merceria. Oggetti visibili:
Ferro di cavallo. Grande campanella. *PROIETTILE D'ARGENTO* *DERRINGER D'ORO* Cartello. *SPERONI D'ARGENTO*. Cappello da Cowboy. Chiave piccola. Barilotto di polvere da sparo. Chiodi. Martello.
Uscite evidenti: NORD
 
———-> Cosa devo fare? RIEMPI BARILOTTO
OK
con cosa?
 
———-> Cosa devo fare? CON POLVERE DA SPARO
 
Scrivere solo POLVERE DA SPARO, invece che CON POLVERE DA SPARO al prompt di cui sopra restituisce un messaggio d'errore generico.
La mia esperienza con Ghost Town rafforza sempre di più in me l'idea che questi primissimi giochi erano semplicemente troppo limitati tecnologicamente per poter supportare degli enigmi complessi che fossero al tempo stesso anche equi e affrontabili con la logica, col risultato che -volendone aumentare la difficoltà oltre una certa soglia molto bassa- si ricadeva inevitabilmente in assurdità, che infatti abbondano in Ghost Town e nel finale di Adventure.
 
È 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:
 
“1. A ogni 'Odyssey' potranno partecipare più giocatori contemporaneamente. E ogni giocatore potrà aiutare o ostacolare, come meglio crede!
2. Frasi complete, invece del solito "linguaggio da bambini". Ad esempio: "Metti gli zoccoli al cavallo con il ferro da cavallo e il martello e i chiodi."
3. Messaggi di risposta più lunghi.
4. Effetti sonori
5. Trame più ampie.
Per sviluppare questo sistema in realtà ho dovuto prima sviluppare un nuovo linguaggio per computer che ho chiamato OIL ('Odyssey Interpretive Language'), che viene implementato da uno speciale assembler Odyssey, che  genera il codice macchina per Odyssey. Questo codice macchina viene poi implementato su ognuno dei diversi microcomputer (es. Apple, TRS-80, ecc.) attraverso uno speciale emulatore host che simula il mio (inesistente) computer Odyssey.
Attualmente (scrivo dal Washington Computer Show, ed è il Settembre del 1980) il sistema è nelle fasi finali di implementazione dell'emulatore host su un TRS-80 32 K a dischetti, e sto già scrivendo la prima 'Odyssey' (che ho già abbozzato e che è provvisoriamente intitolata Martian Odyssey) in OIL proprio per tale emulatore. Spero che quando voi starete leggendo queste righe, Odyssey Number One sia già disponibile nel vostro negozio di fiducia o nel catalogo del vostro servizio di acquisti per posta preferito."
 
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?
 
Quale che sia la risposta, Martian Odyssey non ha mai fatto la sua apparizione sulle scene e -per quanto ne so- Adams non ha mai più parlato del suo sistema Odyssey. Nel bene o (decisamente) nel male, Adams scelse di restare fedele a ciò che lo aveva portato fin lì: cacce al tesoro giocabili su computer di fascia bassa a 16 K equipaggiati solo con lettori di cassette.
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”.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.

Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto

Articoli precedenti:

Sulle tracce di The Oregon Trail
In difesa del BASIC
A Caccia del Wumpus
L'Avventura di Crowther
TOPS-10 in a Box
L'Avventura completata
Tutto il TRaSh del TRS-80
Eliza
Adventureland
Dog Star Adventure
Qualche domanda per Lance Micklus
Un 1979 indaffarato
The Count

Due diverse culture di avventurieri
Microsoft Adventure
La Narrativa Ludica già nota come Storygame
L'Ascesa dei Giochi Esperienziali
Dungeons And Dragons
Una Definizione per i Giochi di Ruolo per Computer
Dal Tavolo al Computer
- I Primi Giochi di Ruolo per Computer
- Temple of Apshai



Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!

Retrogiochiamo a Trinity - parte 7

Torna il leggendario Caronte nel nuovo episodio del Let's Play di Trinity, l'avventura testuale della Infocom, scritta da Brian Moriarty.

Il buon Ancient ci porta ad affrontare una massa di roditori e poi, forse, finalmente, sulla barca del famoso traghettatore!

Retrogiochiamo insieme a Trinity - parte 6

Continuano le avventure di Ancient in Trinity, l'avventura testuale di Brian Moriarty, pubblicata per la Infocom!

In questo episodio, visitiamo un atollo tropicale e andiamo a caccia di satelliti in orbita.Il buon Ancient sarà tornato sulla Terra? Lo scoprirete solo nel video!

Retrogiochiamo insieme a Trinity - parte 4

Ormai conoscete la storia: il buon Ancient ci porta nei meandri di Trinity, l'avventura testuale di Brian Moriarty, un classico Infocom.

In questo episodio scoperchiamo tombe, facciamo la conoscenza di Caronte e chiediamo aiuto a una piccola lucertola. Buona visione!

Retrogiochiamo ancora a Trinity!

Ancient non ci delude e ci porta la seconda parte di Trinity, storica avventura testuale di Brian Moriarty.

Questa volta, scopriremo funghi bianchi e bottiglie di Klein, accompagnati dalle piacevoli elucubrazioni dell'Antico.

Guarda la prima parte di Trinity

Retrogiochiamo insieme a Trinity

Il buon Ancient continua a mostrarci diverse avventure testuali, e questa volta ci porta Trinity, un classico Infocom realizzata da Brian Moriarty.

Dopo una dettagliata introduzione al titolo, Ancient ci mostra la prima mezz'ora del gioco, da quando il nostro protagonista si trova davanti al palazzo di Kensington fino all'inizio vero e proprio del gioco.

Adventureland - Parte 1
The Digital Antiquarian (traduzione ufficiale italiana)

Scott Adams occupa una strana posizione nel mondo dell'interactive fiction, essendo più amato da coloro che non fanno parte della community, che da quelli che ne fanno parte.
Ogni anno spuntano almeno un paio di sue interviste ossequiose (sia su siti mainstream che su quelli di retrogaming), a cui il Sig. Adams sembra non sappia mai tirarsi indietro. Invece nella community dell'IF le opere di Adams, se mai vengono citate, lo sono sempre e solo a titolo di curiosità storiche; non gli viene riconosciuto nemmeno un briciolo del rispetto che normalmente viene tributato ai classici Infocom. Restano fuori dal coro solo una manciata di voci reazionarie che interpretano questa mancanza di rispetto per i giochi, semplici ma divertenti, di Adams come il sintomo delle più ampie ambizioni letterarie della maggioranza della community, che hanno reso le moderne avventure testuali una zona in cui è "Vietato Divertirsi" (per una filippica in merito -ormai classica ma sempre divertente- potete leggere la pagina di discussione su Wikipedia della voce di Adventureland).
A ingarbugliare ulteriormente la questione ci si mette anche la sfortunata (ma grazie al cielo solo sporadica) tendenza all'auto-celebrazione tipica di Adams, come possiamo leggere nella FAQ della sua home page, dove si afferma che ad Adams: "è attribuito [e da chi?] la nascita dell'intera industria dei videogiochi, che oggi vale svariati miliardi all'anno". Avrei anche potuto convenire su un "contributo alla nascita", ma scritto così... Ne sei davvero convinto, Scott? Davvero credi di aver fatto nascere tutto da solo l'industria dei giochi su computer?

Tuttavia Adams si merità più considerazione e più rispetto, di quanto non ne riceva dalla community, per aver portato per primo le avventure testuali nelle case della gente comune e, in conseguenza di questo, per aver dimostrato al mondo che era possibile vivere agiatamente di questa attività. La sua realizzazione di un'avventura testuale giocabile su un TRS-80 con soli 16 K di RAM e un lettore di cassette fu concettualmente audace e tecnicamente impressionante; il fatto che ci sia riuscito utilizzando il lento e inefficiente BASIC del TRS-80 rende l'impresa ancora più memorabile.
Il più grande fallimento di Adams nel lungo periodo fu forse la sua incapacità di percorrere la transizione dalle avventure testuali di caccia al tesoro alla più sofisticata narrativa tipica dell'interactive fiction della Infocom. Il che sarebbe dimostrato anche dal suo apparente disinteresse nel migliorare la tecnologia dietro ai suoi giochi, se si esclude il mero tentativo di infiorettare con grafica e colori le sue semplicistiche opere.
Ma questa è materia per i prossimi post. Oggi voglio parlarvi del primo capolavoro di Adams: Adventureland.

Nato nel 1952, Adams aveva già una vasta esperienza professionale con i computer prima di scrivere Adventureland nel 1978, avendo completato i suoi studi di informatica presso il Florida Institute of Technology, avendo avuto a che fare con i computer durante un periodo in Marina, e avendo lavorato come programmatore presso la Stromberg-Carlson (uno di primi produttori di centraline telefoniche private). Adams inoltre aveva costruito e provato i microcomputer a casa propria fin dal 1975, quando con l'apposito kit si costruì uno Sphere 1. A partire da un gioco del tris che "non sapeva perdere", la sua principale attività con queste macchine è stata sempre quella di scrivere e giocare a videogiochi. Come molti altri hacker, anche lui restò stregato quando Adventure spuntò sul suo computer di lavoro e (come molti altri) quando finalmente lo ebbe completato, si dedicò a scrivere il suo Adventure. Ma -a differenza di tutti gli altri che lo fecero sui grandi computer istituzionali- Adams scelse come piattaforma il suo piccolo TRS-80.

Adams ovviamente non si era imbarcato nell'impresa con l'aspirazione di portare la narrativa interattiva alle masse. Nel tipico stile hacker, egli fu attratto da questo progetto perché era una sfida tecnica interessante per battere le limitazioni del TRS-80, ed era al contempo un'occasione per lavorare con le parole (cosa che non aveva mai fatto prima).
Essendo un programmatore di una certa esperienza, Adams condivideva con la maggior parte degli hacker una predilezione per la creazione di sistemi e strumenti robusti e riutilizzabili, piuttosto che programmi fini a sé stessi. Iniziò quindi a lavorare non tanto su un singolo gioco d'avventura, quanto su un sistema riutilizzabile per l'implementazione di avventure testuali. Divise quindi il progetto in tre parti: una specie di editor di database (che gli permettesse di inserire i dati volti alla creazione del mondo virtuale di ogni gioco), un interprete (che leggesse tali dati e permettesse al giocatore di interagirci), e in fine i dati del gioco vero e proprio.

Si tratta di un sistema notevole, anche se dobbiamo chiarire che Adams non creò una vera e propria virtual machine (come fece invece la Infocom con la sua Z-Machine, come vedremo in futuro). Infatti se da un lato è vero che l'interprete va effettivamente a leggere i dettagli delle stanze, degli oggetti, e di quant'altro, dall'altro lato la maggior parte della sua funzionalità è hard-coded all'interno dell'interprete BASIC. Per esempio l'engine presuppone che tutto il gameplay si sviluppi intorno alla raccolta di oggetti (tesori) e al depositarli in una specifica location. Quindi qualunque modifica non banale di Adventureland richiederebbe una modifica al codice dell'interprete, non fosse altro che per il fatto che al suo interno si trovano anche il titolo del gioco e le istruzioni.

*** BENVENUTO IN ADVENTURE LAND. (#4.2) ***
A MENO CHE NON TI VENGA DETTO DIVERSAMENTE DEVI TROVARE *TESORI*
E-RIPORTARLI-NEL-POSTO-GIUSTO!
IO SONO LA TUA MARIONETTA. DAMMI ORDINI IN INGLESE
COMPOSTI DA UN VERBO E UN SOSTANTIVO. ALCUNI ESEMPI...

A ben vedere si tratta quindi di un sistema ibrido, incredibilmente simile a quello dello stesso Adventure (che pure divideva la sua funzionalità fra il codice del programma e i file di dati).
E, a dire il vero, avendo appena giocato la versione originale di Adventureland, sono stupito da quante siano le similitudini con il suo predecessore.
Tanto per cominciare anche Adventureland è una caccia al tesoro senza trama che inizia in una foresta.

SONO IN UNA FORESTA. GLI OGGETTI VISIBILI SONO:
ALBERI.
USCITE EVIDENTI: NORD SUD EST OVEST
UNA VOCE TUOOOONA
PER VINCERE OTTIENI 100 QUANDO DICI "PUNTEGGIO". UN TESORO È
TUTTO QUELLO CHE HA UN * NEL NOME

L'area all'aperto di Adventureland è più grande e più interessante di quella di Adventure, con dei veri e propri enigmi ulteriori a quello (scontato) di trovare l'accesso al sotterraneo.
Il suo complesso sotterraneo invece è molto più piccolo, come era logico aspettarsi viste le limitazioni con cui Adams doveva fare i conti. Questo però non danneggia più di tanto il gioco: l'impossibilità tecnica di Adams di concedersi dozzine di locazioni vuote fa sì che tutto sia più concentrato e più facilmente gestibile da parte del giocatore. L'immancabile labirinto, per esempio, consiste di sole sei stanze, differenza assai significativa e gradita rispetto alle mostruosità di Adventure.

Questo però non fa di Adventureland un gioco più giocabile, almeno per gli standard odierni. Le aree all'aperto sono piene delle solite connessioni non reciproche fra stanze, che rendono una vera pena la mappatura e la navigazione, addolcita (ancora una volta) solo dal fatto che non sono poi così tante. Anche qui il grosso della sfida è rappresentato dalla logistica delle fonti di luce e della gestione dell'inventario, senza dimenticare l'esistenza di dozzine di occasioni per rovinare la partita rendendola interminabile, molte delle quale assolutamente imprevedibili prima che accadano.
Per comprendere a pieno il vero livello di crudeltà di tutto questo, vi invito a mettervi nei panni di chi all'epoca lo giocava su un vero TRS-80, dove è possibile ricaricare una posizione salvata solo riavviando il gioco da cassetta (procedura che richiede circa 25 minuti). E senza dimenticare che salvare una partita richiede più di 4 minuti! Non c'è da meravigliarsi quindi se Adams poté pubblicizzare Adventureland come un gioco che avrebbe richiesto settimane, se non mesi, per essere completato! Quello che si era dimenticato e che, per poterlo fare, oltre a un TRS-80 sarebbe servita anche la pazienza di Giobbe...

Negli enigmi di Adventureland ho notato la medesima dicotomia di cui ho parlato analizzando Adventure: la maggior parte di essi sono o troppo semplici e evidenti, o ingiusti fino al punto di risultare assurdi, con pochissime eccezioni collocate nel giusto mezzo. E, sempre come in Adventure, da certi punti di vista anche Adventureland ha una curva di difficoltà sorprendentemente progressiva, riuscendo anche a infilare un buon numero di indizi nei suoi 16 K... salvo poi lasciare alcuni dei suoi enigmi peggiori totalmente senza indizi.
Prendete ad esempio l'enigma dell'orso (che a sua volta è un'altra reminiscenza di Adventure). Vi blocca la strada e si può spostare solo con l'azione del tutto ingiustificata di GRIDARE. Le versioni successive permettono al giocatore anche di URLARE all'orso (vi invito a leggere la recensione di Grunion Guy per un divertente aneddoto al riguardo), ma nella versione originale si poteva solo GRIDARE.

SONO SU UNA STRETTA SPORGENZA DINANZI AD UNA STANZA DEL TRONO.
DALL'ALTRO LATO DEL BARATRO C'È UN'ALTRA SPORGENZA.. GLI OGGETTI VISIBILI SONO:
ORSO NERO MOLTO MAGRO.    *SPECCHIO MAGICO*
DIMMI COSA FARE? URLA ORSO
NON POSSO ANCORA FARLO
DIMMI COSA FARE? GRIDA
L'ORSO È TALMENTE IMPAURITO CHE CADE DALLA SPORGENZA

Per rendere l'enigma ancora peggiore, l'orso viene descritto come "affamato"; il che immancabilmente induce il giocatore a cercare di sfamarlo con il miele che ha trovato altrove; il che funzionerebbe anche, se non fosse che il suddetto miele è anche un tesoro (!?!) che deve essere conservato se si vuole completare il gioco! Tutto questo non è solo eccezionalmente crudele, ma quel che è peggio è che la soluzione sbagliata rappresenta al tempo stesso una soluzione molto più equa e gratificante di quella corretta!

Devo però aggiungere che anche qui, come in Adventure, un parser e un world model ancora estremamente primitivi rendono assai ardua l'ideazione di enigmi avvincenti che non scadano nell'iniquità più assoluta.
Vi invito ad esempio ad analizzare la sua implementazione del verbo TIRARE, che ci mostra come già allora Adams stesse lottando con i limiti del suo parser a due parole.

 

SONO IN UN PRATO SOLEGGIATO. GLI OGGETTI VISIBILI SONO:
GRANDE DRAGO ADDORMENTATO
UN CARTELLO DICE -IN MOLTI CASI IL FANGO È BENE. IN ALTRI...-.
USCITE EVIDENTI: NORD SUD EST OVEST
DIMMI COSA FARE? TIRA ASCIA
IN 1 PAROLA DIMMI A COSA
DIMMI COSA FARE? DRAGO
NON LO INFASTIDISCE NEPPURE

[Mi permetto di aggiungere che questa mi pare un'altra similitudine con il suo predecessore: infatti anche il drago di Adventure non viene nemmeno scalfito dalla nostra ascia. ndTraduttore]

Non sarebbe invece molto equo da parte nostra giudicare il testo di Adventureland secondo i normali criteri letterari, visto che ogni articolo determinativo o indeterminativo usa memoria preziosa (e quindi vengono tutti scartati a priori). Tuttavia ci sono dei passaggi in cui Adams sembra raggiungere una sorta di poetica minimalista.

 

SONO SULLA SPONDA DI UN LAGO. GLI OGGETTI VISIBILI SONO:
ACQUA   *PESCIOLINO ROSSO*   CARTELLO CHE DICE -VIETATO NUOTARE-.
USCITE EVIDENTI: NORD SUD EST OVEST GIU'
DIMMI COSA FARE? PRENDI PESCE
OK, TROPPO SECCO. PESCE MUORE.
DIMMI COSA FARE? INVENTARIO
STO TRASPORTANDO LE SEGUENTI COSE:
LAMPADA D'OTTONE VECCHIO STILE   *RETE D'ORO*   ACCIARINO
*MASSICCIO TAPPETO PERSIANO*   PESCE MORTO

A volte poi ha qualche problema di ortografia...

... ma, nel complesso, l'esperienza mantiene un suo fascino bizzarro...

 

SONO IN UN BANCO DI MEMORIA DI UN TRS-80.
HO SBAGLIATO STRADA!

... e, alla fine, il gioco si conclude così:

 

APPARE UN GENIO LUMINESCENTE. LASCIA QUALCOSA. POI SPARISCE.
DIMMI COSA FARE? PUNTEGGIO
HO ACCUMULATO 12 TESORI
IL CHE SU UNA SCALA DA 0 A 100 FA 92
DIMMI COSA FARE? STROFINA LAMPADA
APPARE UN GENIO LUMINESCENTE. LASCIA QUALCOSA. POI SPARISCE.
DIMMI COSA FARE? PUNTEGGIO
HO ACCUMULATO 13 TESORI
IL CHE SU UNA SCALA DA 0 A 100 FA 100
BEN FATTO.
ADESSO IL GIOCO È FINITO
GIOCHI DI NUOVO? _

E questo è tutto quello che c'è da dire su Adventureland, davvero. Nessun progresso rispetto allo schema della caccia al tesoro creato da Adventure, per quanto la sola esistenza di Adventureland sia di per sé un risultato assolutamente ragguardevole. E poi, ancora oggi, è in un certo senso divertente, seppur nella sua maniera semplice e ingenua.

Se volete provarlo, ci sono moltissimi modi per farlo. Il più accessibile dei quali è la versione Java giocabile in browser che è disponibile su FreeArcade. Lo stesso Scott Adams offre delle versioni scaricabili del gioco sul suo sito. O, se desiderate l'esperienza più autentica possibile, ho uno stato salvato per il MESS TRS-80 che vi permetterà di giocare all'originale versione BASIC sul suo hardware (virtuale) originale (consultate il mio post sull'emulazione del TRS-80 per iniziare con piede giusto).

La prossima volta vi parlerò di come Adventureland fu commercializzato e recepito, e di come generò una moda (passeggera) per gli adventure.

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon!

Articoli precedenti:
- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80
- Eliza

Visita il sito ufficiale di The Digital Antiquarian

Leggi la parte 2 di Adventureland!

Discutiamone insieme sul forum di OldGamesItalia!

Kickstarter Corner: Thaumistry: In Charm's Way

Bob Bates è uno dei padri dell'industria videoludica, avendo collaborato con la Infocom e avendo partecipato a fondare la Legend Entertainment. Ci ha regalato titoli meravigliosi, fra cui la serie di Spellcasting (insieme a Steve Meretzky), Eric the Unready, e Companions of Xanth (insieme a Michael Lindner).

Ebbene, siamo lieti di annunciare che Bob Bates ha appena lanciato un Kickstarter per un'avventura testuale: Thaumistry: In Charm's Way.
Un progetto di piccole dimensioni (da $25,000, già finanziati), già in avanzata fase di sviluppo, e con uno stretch goals ambizioso ma allettante: un porting pubblico dell'engine TADS per iOS e Android, che potrebbe poi essere sfruttato anche per giocare in mobilità con tutti gli altri giochi scritti in TADS esistenti.

Se siete alla ricerca di un'avventura testuale vecchio stile, Thaumistry: In Charm's Way potrebbe essere il gioco giusto da finanziare. Noi lo abbiamo già fatto.

Finanzia anche tu!