Giochi col Parser
The Digital Antiquarian (la traduzione ufficiale italiana)



Benvenuti lettori temerari al consueto appuntamento con la traduzione ufficiale del The Digital Antiquarian, scritta dalla sapiente penna poliglotta del nostro The Ancient One e con la bislacca supervisione del sottoscritto: uno sforzo editoriale che si perpetua ormai da innumerevoli mesi e che raccoglie sempre più consensi e apprezzamenti.
Un lungo viaggio, dunque, che ci ha portati alla storia di Infocom e del primo grande successo commerciale nella storia delle avventure testuali, Zork. Ma, prima di addentrarci nel magico Regno Sotterraneo, L'Antiquario ci parlerà di un aspetto tecnico di importanza notevole per lo sviluppo delle avventure testuali: il parser. 
E come dimenticare la lista degli articoli del ciclo Infocom:
 
– 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 scegliete bene le parole!
 
Festuceto
 
Mi tufferò in maggior dettaglio dentro Zork nel mio prossimo post, ma prima mi sento in dovere di tornare in modo un po' più rigoroso sull'argomento che ho solo sfiorato nel primo post di questa serie: quanto era impressionante Zork nel mondo dei microcomputer del 1980-1981. Ho una tesi che vorrei illustrarvi, ma richiede un po' di teoria (ahia!). Ma, prima ancora, lasciatemi presentare lo scenario del nostro discorso, con alcune citazioni tratte dal progetto Get Lamp di Jason Scott.
 
“Due sono i prodotti che hanno venduto più computer di tutti gli altri: VisiCalc e Zork.” — Mike Berlyn
 
“Dopo la scuola andavamo in questo negozio e giocavamo a qualunque gioco ci fosse disponibile, oppure inserivamo personalmente il codice dei giochi, e mi ricordo anche di quando uscì Zork e lo giocavamo su Apple II, e ne eravamo semplicemente estasiati.” — Andrew Kaluzniacki
 
“La gente vedeva Zork e diceva: 'Lo voglio anche io, assolutamente sì. A chi intesto l'assegno?'” — Mike Berlyn
 
“Credo che ci sia stato un periodo di tempo, probabilmente fra l'80 e l'84, in cui, per un sacco di macchine, non c'era praticamente niente di lontanamente simile.” — Mike Dornbrook
 
Certo, il fatto che Berlyn metta Zork sullo stesso piano di un programma che ha definito un'intera industria come VisiCalc è forse un po' esagerato, ma dà un’idea di ciò di cui sto parlando. Affermazioni come quest'ultima oggi ci suonano ironiche, se non addirittura un po' tragiche. Nel giro di qualche anno da quel periodo (indicato da Dornbrook) che va dal 1980 al 1984, i publisher e gli appassionati avrebbero iniziato a individuare nella mancanza di un’attrattiva immediata delle IF, la ragione principale del declino delle fortune commerciali di tale genere (oltre ovviamente a lamentarsi dell'analfabetismo adolescenziale all'interno del segmento di popolazione che tipicamente fruiva dei videogiochi, e altri argomenti simili).
 
E, allora, cos'era che questi primissimi giocatori trovavano di così immediatamente attrattivo in Zork? Di certo il suo mondo non era solo più grande, ma anche modellato in un modo più rigoroso e più sofisticato di qualunque altra cosa si fosse mai vista prima. Di certo la scrittura (seppur a volte necessariamente sintetica a causa dei limiti di spazio) mostrava una certa verve e una certa nuance, oltre che -beh!- un'attenzione alla grammatica e all'ortografia che surclassava tutta la concorrenza. E di certo il suo gameplay era (seppur ancora afflitto da irritanti labirinti e da alcuni enigmi tragici) più equo della norma. Ma queste sono tutte cose che possono essere notate solo dagli appassionati di avventure testuali: il genere di cose che si palesa solo dopo aver passato un po' di ore dentro Zork e (almeno) un po' di ore con altri giochi del periodo. Invece, come illustrano bene le citazioni riportate qui sopra, la gente giocava Zork in negozio per qualche minuto e lo comprava in preda allo stupore. E forse, al di là dell'iperbole di Berlyn, a volte insieme comprava anche l'Apple II che serviva per giocarci. Perché? Credo che la risposta risieda nella relazione di amore-odio dei giochi d'avventura con il proprio parser.
 
In Joysprick, un libro su James Joyce, Anthony Burgess divide gli autori in due categorie (qui inserite liberamente la vostra barzelletta preferita che inizi con “C'erano due...”; fate con calma. Fatto? Bene...). Gli autori di Classe Uno si preoccupano esclusivamente dello storyworld (la realtà virtuale, se preferite) che vive “dietro” le loro parole. “Il contenuto diventa più importante dello stile, i referenti bramano di essere liberi dalle loro parole e di venir presentati direttamente come dati percepiti”. La “buona” scrittura, da questo punto di vista, è la scrittura che esiste esclusivamente per servire l’ambientazione e la storia che essa rivela, una scrittura che sa evocarle entrambe il più vividamente possibile, ma che al tempo stesso nasconde sé stessa dinanzi al lettore che con la sua immaginazione ricostruisce la sottostante realtà virtuale, rifiutandosi diligentemente di richiamare l’attenzione su di sé. Gli autori di Classe Due, all’opposto, sono preoccupati del loro linguaggio di per sé. I loro libri “sono fatti di parole, non meno che di personaggi”. A volte, come nel caso di Finnegans Wake o del capitolo “Sirene” dell’Ulysses, il linguaggio sembra essere l’unica cosa presente; la scrittura è tutta “superficie”. Alcuni potrebbero rimarcare che avere successo (o, almeno, provarci) su questo secondo piano è ciò che divide la “letteratura” dalla “fiction”. Ma noi ci terremo lontani da questo vaso di Pandora. Anzi, nel cercare di applicare questi concetti all’interactive fiction, mi asterrò dall’esprimere giudizi di valore.
 
Non voglio per ora applicare queste idee al testo che un’opera di IF mostra al giocatore, quanto piuttosto al testo che il giocatore vi immette (il parser, in altre parole). Non a caso, un modo per avvicinarsi alla narrativa interattiva è quella di considerarla una ricca realtà virtuale da abitare. Da questo punto di vista (quello di un giocatore di Classe Uno) il parser per lui esisterà solo come mezzo per iniettare le proprie scelte nel mondo, esattamente come un lettore di Classe Uno considera il testo come una finestra (idealmente il più trasparente possibile) attraverso cui osservare l’azione che si svolge nello storyworld. Questo è sempre stato il mio approccio di base all’interactive fiction, sia come giocatore che come scrittore. Visto che ormai in questo post mi sono concesso un sacco di citazioni dirette, lasciate che pecchi di modestia citando un mio precedente intervento sull’argomento. Nel 2008 ho scritto quanto segue, come commento al blog di Mike Rubin:
 
Credo che molte persone, incluso me stesso, abbiano effettivamente giocato a Facade come fosse una commedia, provando azioni sempre più oltraggiose per vedere cosa sarebbe successo, cercando cioè di arrivare a “rompere” il sistema. Mi permetto di osservare, però, che quando il giocatore inizia a fare ciò, è segno che il game designer ha, in una qualche misura, fallito. Ho infatti iniziato ad adottare un approccio ironico con Facade dopo aver provato numerose condotte ragionevoli a cui il gioco o non ha risposto affatto, o ha risposto in un modo che era palesemente inappropriato alle mie azioni. A quel punto per me la mimesi è crollata e ho iniziato a trattare il sistema come fosse un giocattolo ingegnoso, anziché come una narrativa interattiva immersiva. Ovviamente non c’è niente di male nel fallimento di Facade: è un concept rivoluzionario e dovrà necessariamente passare per molte altre iterazioni prima che possa sperare anche solo di avvicinarsi a un realismo completo.
 
Questo però solleva un punto: non credo che i giochi possano mantenere la propria mimesi rimproverando il giocatore, dicendogli in termini espliciti “di NO”, quando tenta di mangiarsi la spada o di colpire un amico. Dovremmo piuttosto impegnarci per rendere la nostra scrittura così buona, le nostre ambientazioni così credibili, e le nostre interazioni così lisce, che il giocatore sia assolutamente catturato dalla nostra storia, in modo che non gli venga mai in mente di mangiarsi la spada o di colpire gli amici, esattamente come non verrebbe mai in mente al suo avatar. Detto in altre parole, dobbiamo fare in modo che il giocatore DIVENTI davvero il suo avatar per tutto il poco tempo che giocherà.
 
Appena il gioco inizia ad andare in frantumi (per usare questa metafora)… è allora che il giocatore si ricorderà solo una stupida avventura testuale, ed è allora che inizierà a giocare per ridere, cercando di rompere più che mai il sistema. Io lo faccio ogni anno con almeno una dozzina di giochi dell’IFComp, cercando di RUBARE porte ed edifici, e più in generale di creare scompiglio nello storyworld. Del resto il divertimento sta dove lo si trova.
 
Ovviamente ci sono giocatori che affrontano ogni gioco con l’intenzione di romperlo. E alcuni potrebbero certamente considerare l’interactive fiction più interessante come un sistema con cui giocare che come storia, anche se penso che altri generi sarebbero più adatti per soddisfare questo loro bisogno. A questi giocatori dico: bene, divertitevi come più vi piace. Tuttavia credo che la maggior parte delle persone che giocano all’interactive fiction vi arrivino desiderando di essere immersi, per un po', in uno storyworld (e, sì, magari anche in una storia coerente) e di sperimentarlo attraverso gli occhi di qualcun altro. E le ricompense di un tale approccio devono essere infinitamente più grandi del provare azioni a caso per vedere dove sono collocati i confini della simulazione (per quanto anche questo possa risultare divertente).  
 
(Ma non avevamo detto qualcosa sul non esprimere giudizi di valore? Mi è passato di mente...)
 
Premesso questo, la gente che si meravigliava dinanzi a Zork nei negozi di computer non reagiva considerandolo una narrazione profonda e immersiva, né tantomeno un gioco d’avventura estremamente sofisticato. Lo stupore era tutto riservato al parser, inteso come oggetto (giocattolo) di per sé. Perché, nonostante le limitazioni di spazio entro cui dovevano lavorare, alla Infocom si ritagliarono dello spazio per le risposte ironiche proprio a quel genere di input, fuori di testa e privo di senso, che la gente di passaggio in un negozio di computer poteva inserire.
 
WEST OF HOUSE
YOU ARE STANDING IN AN OPEN FIELD WEST
OF A WHITE HOUSE, WITH A BOARDED FRONT
DOOR.
THERE IS A SMALL MAILBOX HERE.
>FUCK
SUCH LANGUAGE IN A HIGH-CLASS
ESTABLISHMENT LIKE THIS!
>SHIT
YOU OUGHT TO BE ASHAMED OF YOURSELF.
>TAKE ME
HOW ROMANTIC!
>ZORK
AT YOUR SERVICE!
>XYZZY
A HOLLOW VOICE SAYS 'CRETIN'.
>FIND HOUSE
IT'S RIGHT IN FRONT OF YOU. ARE YOU
BLIND OR SOMETHING?
>FIND HANDS
WITHIN SIX FEET OF YOUR HEAD, ASSUMING
YOU HAVEN'T LEFT THAT SOMEWHERE.
>FIND ME
YOU'RE AROUND HERE SOMEWHERE...
>CHOMP
I DON'T KNOW HOW TO DO THAT. I WIN IN
ALL CASES!
>WIN
NATURALLY!
>SIGH
YOU'LL HAVE TO SPEAK UP IF YOU EXPECT ME
TO HEAR YOU!
>REPENT
IT COULD VERY WELL BE TOO LATE!
>WHAT IS A GRUE?
THE GRUE IS A SINISTER, LURKING PRESENCE
IN THE DARK PLACES OF THE EARTH. ITS
FAVORITE DIET IS ADVENTURERS, BUT ITS
INSATIABLE APPETITE IS TEMPERED BY ITS
FEAR OF LIGHT. NO GRUE HAS EVER BEEN
SEEN BY THE LIGHT OF DAY, AND FEW HAVE
SURVIVED ITS FEARSOME JAWS TO TELL THE
TALE.
>WHAT IS A ZORKMID?
THE ZORKMID IS THE UNIT OF CURRENCY OF
THE GREAT UNDERGROUND EMPIRE.
>YELL
AAAARRRRGGGGHHHH!
 
Questo significa giocare a Zork come fosse Eliza: scoprire che risposte sono prodotte da questo o quell’input, in cerca dei limiti. Come dimostrato da alcuni recenti esperimenti, questa modalità di interazione è ancora oggi sostanzialmente la norma per i principianti che affrontano un’opera di narrativa interattiva per la prima volta. Nel 1981, quando i computer non erano ancora stati compresi così bene e per la maggior parte delle persone erano ancora qualcosa di vagamente magico (se non persino qualcosa di inquietante), l’idea di digitare qualcosa (specialmente qualcosa di poco pertinente al contesto o addirittura completamente inappropriato) ed essere ugualmente "compresi", era davvero molto potente e richiamava alla mente HAL e il computer parlante dell’Enterprise.
 
Ma perché vi dico tutto questo? Non sono così sicuro che ci sia qualcosa da imparare in tutto ciò. Dopo un po’ di tempo, giocare col parser e cercare di rompere le cose perde di fascino, e il giocatore o inizia ad appassionarsi allo storyworld e alla narrazione, oppure semplicemente passa ad altro. Da qui l’irrequietezza che esprimo sopra per i giocatori che non sembrano in grado di andare oltre il trionfo che scaturisce dal constatare che sì, senza troppi sforzi è possibile rompere il parser e con ogni probabilità anche la simulazione del mondo. Oltre dieci anni dopo Zork, un’avventura grafica chiamata Myst divenne per alcuni anni il gioco per computer più venduto di sempre. Spesso veniva definito il bestseller meno giocato di sempre. La gente lo comprava per ostentare le proprie nuove schede grafiche, le schede sonore, e i lettori CD-ROM, nel bel mezzo del boom dei “PC Multimediali” degli anni ‘90, ma resterei sorpreso se anche solo un dieci percento di loro si fosse seriamente appassionato ai suoi intricati enigmi intellettuali o avesse compiuto un vero sforzo per finirlo. In modo del tutto analogo, sospetto che molte delle copie di Zork esistevano più come qualcosa da tirar fuori alle feste, piuttosto che come genuina passione di coloro che le possedevano.
 
Ora però non iniziate a stampare le vostre t-shirt con la scritta “Io apprezzo Zork ad un livello molto più profondo di voi”, perché è pur vero che nessuno di noi è mai diventato fino in fondo un giocatore di Classe Uno. Ecco un’altra citazione ancora da Get Lamp, stavolta di Bob Bates, che cattura bene “gli avanti e indietro” che compongono gran parte dei piaceri delle avventure testuali:
 
“Molti giochi prevedano solo la parte del ‘se’, che poi sarebbe il percorso principale attraverso il gioco, di cui parlavo prima. Se il giocatore fa esattamente questo e tutto va bene, allora il gioco risponde così e tutto va avanti. Ma c’è sempre anche ‘altro’. E se il giocatore non facesse ciò che dovrebbe? Che succede se gli viene questa strana idea, o se digita quella o quell’altra cosa stramba che vuole provare semplicemente per vedere se il gioco si rompe? Così, tanto per vedere dove sono i confini. Ecco, questo fa parte del divertimento di giocare a un’avventura testuale, nonché parte del divertimento (una GRANDE parte del divertimento) del crearle; io infatti mi immagino un dialogo con il giocatore, così che alla fine quando il giocatore fa questa cosa estremamente strana e nel farla esclama ‘ah, nessuno può aver pensato di fare questo!’ e poi ‘Oh, cielo! Quella non è una risposta standard! Anche l’autore ci aveva pensato!’. Questo aiuta a forgiare un legame fra te e l’autore. ‘Quel tizio è strambo quanto me. Io e lui pensiamo nello stesso modo.’”
 
Quindi un motto per il successo di una buona avventura testuale potrebbe essere: attraili e affascinali con il parser, ma trattienili con il tuo storyworld. Con lo spirito di essere trattenuti con lo storyworld, la prossima volta indosseremo le nostre divise da giocatori di Classe Uno e ci avventureremo nel Grande Impero Sotterraneo. Stavolta davvero, promesso. 

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!

 

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:
 
– 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!

 

Narrativa Interattiva 2017

Le origini della Narrativa Interattiva o Interactive Fiction si perdono nella notte dei tempi, risalendo agli albori dell’intrattenimento informatico: ce lo racconta bene il nostro Digital Antiquarian, magistralmente tradotto da The Ancient One, ed un resoconto più sintetico – e senz’altro lacunoso – sull’argomento lo scrissi di mio pugno l’anno passato. E proprio nel 2016 inizia la nostra storia.

Innanzitutto è indispensabile una breve premessa di carattere storico: la storia dei videogiochi è costellata di premi, di ogni tipo e valore, sin dai tempi delle prime riviste cartacee di videogiochi si avvertiva il bisogno di votare il proprio gioco preferito, di redigere classifiche ed eventualmente premiare, anche solo simbolicamente, il titolo più meritevole. Molti concorsi erano riservati ad uno specifico genere videoludico e le IF non costituirono un’eccezione. Tuttavia il primo contest del genere arrivò soltanto nel 1998, negli Stati Uniti, quando ormai, paradossalmente, l’epoca d’oro delle IF era svanita da circa una decade, lasciando a bocca (quasi) asciutta i pochi appassionati ormai cresciuti e maturi. Proprio tra quegli appassionati si celavano nuovi autori, con idee inedite e strumenti innovativi (era da pochi anni in uso Inform di Graham Nelson, piattaforma di sviluppo, sempre più popolare e alla portata di tutti). Intanto internet garantiva la diffusione capillare delle IF, ormai non più prodotti commerciali, accessibili gratuitamente a chiunque disponesse di una connessione al web: erano cambiati gli strumenti di sviluppo e i canali di circolazione dei titoli di narrativa interattiva. Potenzialmente i nuovi giocatori di IF erano tantissimi, sparsi in tutto il mondo, purché anglofoni, perché, ovviamente, la maggior parte della produzione era in lingua albionica e così pure la prima competizione di genere, il celebre IFComp (Interactive Fiction Competition) ancora oggi, alla sua 22esima edizione, il più prestigioso premio per la narrativa interattiva. Subito dopo nacquero altri contest, tra i più noti, ricordiamo gli XYZZY Awards (dal 2000 ad oggi) e lo Spring Thing, dal sapore meno agonistico (dal 2002 ad oggi).

E l’Italia? L’anno successivo al primo IFComp, nel 1999, lo sparuto ma agguerritissimo gruppo di cultori italiani della narrativa interattiva, organizzò il Premio Avventura dell’Anno 1999.  Purtroppo seguirono soltanto altre cinque edizioni del premio: dal 2000 al 2003 e l’ultima nel 2008. Ricordiamo il vincitore del Premio Avventura dell’Anno 2001, Marco Vallarino con il suo acclamato Enigma (che si portò a casa, tra gli altri premi, una bella cassa di Piedirosso ischitano)  e Paolo Lucchesi, che con l'ottimo La Pietra della Luna, si aggiudicò l'edizione 2003 della competizione. Purtroppo la risonanza nazionale ed internazionale dell'iniziativa, nonostante la crescente partecipazione, restò sempre molto contenuta, ben lungi dai livelli dell'IFComp e degli altri eventi d'oltreoceano. Tuttavia la scena italiana delle avventure testuali era ancora fervente, tutt’altro che morta, e moltissimi nuovi autori comparvero all'orizzonte affiancandosi degnamente ai vecchi maestri, mentre gli appassionati giocatori sopravvivevano nei forum specializzati e nei newsgroup (ve li ricordate?), fucine di nuovi talenti. Certamente nulla di lontanamente paragonabile alla vastità (relativa) del pubblico anglofono, del resto i giocatori di IF italiani erano – e sono – decisamente pochi, se non altro per ragioni demografiche, e ciò costituisce, in definitiva, l'unico enorme limite al successo internazionale della narrativa interattiva italiana. Non è un caso se molti autori traducono le proprie opere in inglese, cimentandosi, con ottimi risultati, nelle varie competizioni internazionali. Ricordiamo la vittoria di Marco Innocenti nell'IFComp 2012 con il suo Andromeda Apocalypse, scritto esclusivamente in lingua inglese, una scelta forse discutibile, ma sicuramente significativa.

E arriviamo ad oggi. O meglio all'anno passato. Nel 2016 nasce, in seno alla comunità di OldGamesItalia, l’idea di riportare in auge i concorsi di narrativa interattiva in lingua italiana per restituire lustro e dignità al lavoro straordinario dei nostri autori (nuovi e vecchi). Oggi il panorama delle IF è cambiato e sono nati nuovi sottogeneri, prodotti sperimentali, a volte difficilmente inquadrabili: libri interattivi, avventure dinamiche, le definizioni, spesso inadeguate, si sprecano! E, come se non bastasse, sono apparse nuove piattaforme di sviluppo rivolte anche (e soprattutto) al pubblico "mobile". Sopravvivono poi gli irriducibili, “dinosauri” dell’IF, per fortuna, creando così una scena estremamente eterogenea per forma e contenuti. Allora perché non portare al grande pubblico l’esperienza della narrativa interattiva proprio oggi che, storicamente, è più facile fruirla? E perché non provare ad avvicinare anche i più giovani al genere, proprio attraverso gli strumenti a loro più familiari: smartphone e tablet? Abbiamo atteso quasi un anno, forse per paura di non essere all'altezza di un compito così arduo e delicato, ma alla fine ...eccoci pronti a partire!
Nasce, dopo innumerevoli sforzi (stiamo ancora asciugando le camicie): Narrativa Interattiva 2017, attualmente l’unico concorso italiano di Interactive Fiction.

Parteciperanno alla gara, in un Estate avventurosa come non mai, ben 16 titoli, pubblicati nel 2016 e tutti accessibili gratuitamente (come da tradizione). Non vi tedierò con i dettagli del concorso, peraltro fortemente ispirato all’IFComp nel regolamento, ma dallo spirito più rilassato. Tutto quel che dovete sapere è in basso, nel link in coda all’articolo. Vi basti tener presente che i votanti parteciperanno automaticamente all’estrazione di numerosi premi (giusto per spronare i più scettici).
Insomma, cosa si può desiderare di più? Be’ io un paio di cose le avrei in mente, ma restiamo con i piedi per terra...

Allora che aspettate? Giocate, divertitevi e votate.

Il 15 Giugno inizia Narrativa Interattiva 2017 e vi terrà compagnia per due mesi.

“Prendi la Lanterna” e inizia l’avventura! 

 

La pagina dedicata al concorso


Parliamone sul forum

Arriva il Segreto di Castel Lupo

Da Sabato 1 Ottobre è disponibile anche su iOS l'avventura completa de "Il Segreto di Castel Lupo", opera di narrativa interattiva dei Fix-a-Bug. Da qualche giorno l'opera era approdata sul Play Store di Android anche qui in una duplice versione: gratuita con contenuti pubblicitari, oppure a pagamento e senza pubblicità. In entrambi i casi sarà possibile giocare l'avventura completa scegliendo tra due personaggi: Simon e Violet, gli intraprendenti fratelli Weird alla scoperta dei misteri di Castel Lupo, lugubre maniero perduto tra le alpi svizzere. Gli enigmi e le situazioni cambieranno a seconda che si scelga di viverli attraverso gli occhi di Simon, provetto chimico, o di Violet, entomologa in erba, raddoppiando così la longevità e la varietà dell'esperienza di gioco. 

Ma Il Segreto di Castel Lupo è soprattutto un'occasione per avvicinare alla lettura i più giovani, implementando alla narrativa tradizionale per ragazzi quella componente interattiva così cara alle nuove generazioni di nativi digitali.

Leggiamo la recensione de "Il Segreto di Castel Lupo"!

Poi l'intervista agli sviluppatori

E visitiamo la scheda dell'avventura dal nostro archivio di IF Italia

Qui trovate l'avventura per i possessori di sistemi Android

Per i seguaci della mela morsicata invece cliccate qui.

Buona lettura!

Frankenstein

Quando il videogioco incontra la letteratura il rischio è sempre dietro l'angolo, soprattutto se, come in questo caso, il titolo in esame è quello di un classico immortale della letteratura inglese, Frankenstein, o il moderno Prometeo. Rischio di semplificare concetti ed argomenti, di banalizzare, sacrificare, rischio per il videogioco stesso di rivelarsi mezzo inadeguato per narrare qualcosa di più complesso. Parlando di interactive fiction, il genere videoludico ideale per esplorare i confini tra narrazione e interattività videoludica, il nostro compito è probilmente reso più semplice. Questa app per iOS e android pubblicata da Inkle Studio, la software house indipendente britannica che da tempo si è distinta nella produzione di giochi narrativi, si è rivelata infatti un banco di prova privilegiato, ma non per questo meno importante, per le ambizioni del videogaming.

Per chiunque abbia qualche dubbio sull'approccio, vogliamo sottolineare che il Frankenstein in questione, è una rilettura fantasiosa e personale, ma sempre rispettosa del classico di Mary Shelley, da parte di Dave Morris, esperto romanziere, autore di graphic novel, giochi di ruolo e di libri-game in stile Choose Your Own Adventure. Tanto per incominciare la storia qui è ambientata nella Francia rivoluzionaria, in un clima politico arroventato dagli eventi, il che rende più agevole il compito del dottor Frankenstein, che può reperire facilmente corpi e arti mozzati dalla ghigliottina. Cambiano anche i testimoni di quanto accade nel corso del racconto, a seconda del caso leggeremo monologhi del "mostro", di Victor (che forse in preda al delirio si rivolge ad un amico immaginario ), commenti dei membri di una nobile famiglia decaduta che assiste alle vicende. A tal proposito il gioco costituisce anche una vera e propria opera di riscrittura del testo originale, reso più snello, moderno e adatto all'interazione anche attraverso alcuni espedienti narrativi, il passaggio alla prima persona, l'uso del presente per raccontare gli esperimenti messi in atto dal dottore. Il tutto attraverso l'uso della piattaforma per la narrazione interattiva Inklewriter.

Dal punto di vista prettamente ludico l'impianto di gioco è  povero di un vero e proprio livello di sfida, non ci sono enigmi da risolvere, punteggi da raggiungere, il gioco verte esclusivamente sulla raccolta di oggetti e sulla consultazione di documenti da mettere in inventario e soprattutto al giocatore è lasciato il compito di fare una lunga sequenza di scelte, di decidere il prosieguo della storia, esperienza visualmente molto seducente e resa piacevole anche da qualche indiscreto effetto sonoro e in particolare da bellissime illustrazioni animate da attivare attraverso l'interazione con lo schermo (visual touch). Inoltre la priorità con la quale vengono letti documenti o esaminati oggetti, può anche influenzare minimamente la storyline.

Quello che Dave Morris ci mostra è che anche se il videogiocatore o il lettore, se preferite, non può stravolgere il canovaccio centrale con la sua interazione (e questo può sicuramente far storcere il naso a qualcuno che sentirà odore di "casual game"), attraverso le sue scelte può dare alla storia o ai personaggi una serie di sfumature, tonalità e dettagli molto interessanti che lo portano comunque a sentirsi parte integrante dell'esperienza "narrativa". I quesiti morali che incontrerà nel corso del gioco sono tanti, lo faranno entrare nella mente del mostro, gli faranno provare frustrazione, alienazione, sofferenza, disprezzo e tutta una serie di sentimenti contrastanti a seconda dei casi e delle decisioni prese lungo il cammino.

L'esperienza complessiva è dunque molto gradevole , una rivisitazione intelligente, arricchita non poco dall'impatto grafico, da piccoli dettagli che denotano la grande cura con la quale è stata realizzata questa applicazione. Il comparto puramente ludico sarebbe potuto essere più ricco, vario e soprattutto più incisivo in alcuni tratti, ma questo nulla toglie all'interattività che, seppure più discreta, anche rispetto a quella di un libro-game (ovviamente anche per non intaccare eccessivamente la struttura di questo classico) rimane comunque, insieme alla qualità della riscrittura ed alla bellezza delle atmosfere, il punto di forza del gioco.

Il videogioco ha dunque passato il test di maturità? nel suo piccolo anche quest'esperienza limitata e "di genere" ci dimostra come intrattenere in modo originale, intelligente e intellettualmente più coinvolgente non è impossibile e non è assolutamente pretestuoso, se fatto bene, rispettando il giocatore e con una forte consapevolezza del media che si utilizza. Il Frankenstein della Inkle ci riesce, in punta di piedi e con una struttura semplice, quasi delicata, ma efficace. Di sicuro abbiamo ancora una volta la conferma di quanto sia fondamentale nell'economia di un gioco, di qualsiasi tipo si tratti, poter disporre della mano esperta di uno scrittore professionista come Dave Morris che sappia montare e smontare il meccanismo creativo in qualsiasi momento e con coerenza, oltre ad abbinare sapientemente le esigenze narrative e quelle ludiche.

L'articolo fa parte della serie di articoli del Ciclo Inkle Studios