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!

 

The Wizard and The Princess - Parte 2
The Digital Antiquarian (traduzione ufficiale italiana)

È il 1980 e abbiamo appena comprato The Wizard and the Princess. Che dite, ci giochiamo?

Dopo aver avviato il gioco, ci ritroviamo nel villaggio di Serenia. Stiamo per partire al salvataggio della Principessa Priscilla dal “grande e spaventoso stregone” Harlin. Ci imbarchiamo nell'impresa, armati del nostro ingegno e del nostro coraggio, pronti per conquistare... il noioso labirinto di 15 stanze di deserto, che inizia subito fuori città. Dopo quasi un'ora di attenta mappatura, realizziamo che l'unica uscita da questa mostruosità è bloccata da un serpente che si rifiuta di farci passare. Ovviamente, essendo noi i classici avventurieri distruttivi, iniziamo a cercare un modo per ucciderlo, magari con una di quelle rocce sparse per il labirinto. Così proviamo a raccoglierne una... solo per venir uccisi all'istante dallo scorpione che c'era sotto. Dopo aver provato ogni genere d'azione (anche le più insensate a cui riusciamo a pensare) decidiamo di chiamare Ken e Roberta per avere un indizio e così scopriamo che eravamo sulla pista giusta. Il fatto è che in tutto il labirinto c'è una sola roccia che non ospita uno scorpione, l'unica che possiamo quindi raccogliere senza morire. Poiché non c'è assolutamente nessun modo per identificare questa roccia a priori, ci tocca passare tutta l'ora successiva a riavviare il gioco finché non ci imbattiamo in quella giusta. Se a questo punto non ci sentiamo più eccitati all'idea di guardare quelle immagini di deserto, belle ma noiosamente simili, che si disegnano lentamente sullo schermo, una dopo l'altra... beh, siamo più che giustificati.

Nel 1993, quando la moderna community dell'interactive fiction, che conosciamo ancora oggi, stava appena nascendo, Graham Nelson scrisse “la Carta dei Diritti del Giocatore” [tradotta in Italiano da Marco Falcinelli -anche lui autore di avventure testuali. Nel testo che segue abbiamo utilizzato la sua traduzione dei diritti dei giocatori; ndAncient], per iniziare a codificare le buone regole del game design delle avventure. Ebbene, già nei primissimi turni di gioco, The Wizard and the Princess riesce a violare ben 4 dei 17 diritti che vi sono elencati: “Non venir ucciso senza avvertimento”; “Essere in grado di vincere senza l’esperienza delle vite passate ”; “Non dover fare cose noiose solo per doverle farle”; e “Non dover subire troppi depistaggi”. Alla luce di un tale risultato, ho iniziato a chiedermi quanti altri diritti sarebbero stati calpestati nel corso di tutto il gioco. Vediamoli insieme passo dopo passo...

La sua coda sembra incastrata sotto la roccia

Non dover fare cose improbabili. Poco dopo aver schiacciato il serpente con una roccia, ne incontriamo un altro... schiacciato da una roccia (è chiaro che i serpenti e le rocce hanno un ruolo essenziale in questa prima parte del gioco).  Presumibilmente questo nuovo serpente è pericoloso quanto il precedente e, a giudicare da come ci siamo sbarazzati del primo, non siamo poi dei grandi amanti dei nostri amici con le squame. Questo però non ci impedisce di liberarlo con grande gentilezza dalla situazione difficile in cui si trova. Si scopre così che è il re dei serpenti e che ha perfino una parola magica da rivelarci in segno di ringraziamento (… mi chiedo però come sia possibile che il re dei rettili sia finito schiacciato da una roccia. Che le classi proletarie dei rettili siano in rivolta?)

Non dover fare troppo affidamento sulla fortuna. Il nostro incontro con il serpente gentile era un'anomalia. Di lì a poco ne troviamo un altro che si mette a inseguirci con l'intento di ucciderci. Dobbiamo così trovare un bastone in un'altra location del deserto, per darlo in testa al serpente per scacciarlo (un'immagine che trovo curiosamente ironica). Tuttavia, se il serpente dovesse (in modo casuale) apparire nel posto sbagliato o nel momento sbagliato, non avremmo il tempo per farlo – e il sipario si chiuderà su di noi, senza alcuna colpa.

Avere un parser decente. Più avanti in questo deserto infinito scopriamo un paio di appunti abbandonati (come è tipico di tutti i deserti del mondo...). Entrambi sono identificati come “appunto” [“note” nel testo originale ndAncient]; il parser apparentemente ne sceglie uno a caso, se proviamo a interagire con un “appunto” mentre entrambi sono nella stessa location. L'unico modo per poter interagire in modo coerente con entrambi è tenerli in due stanze separate. È questo genere di cose che mi fa venire la voglia di scriverlo a lettere maiuscole: DEVE AVERE UN PARSER DECENTE, MALEDIZIONE!

Sei nel deserto

Guarda appunto

Sei nel deserto

Guarda appunto

Non dover leggere suggerimenti orribili e per niente chiari. Proseguendo ancora nel deserto arriviamo a un burrone profondo e impossibile da attraversare. Qui dobbiamo digitare la parola magica “HOCUS”, facendo materializzare un ponte. Non mi è chiaro come dovrebbe fare il giocatore a intuire questa parola, ma posso immaginare che debba essere ricavata dai contenuti di uno, o di entrambi, questi appunti di cui vi ho appena parlato e che potete vedere sopra. Quello di sinistra assomiglia vagamente a un “HOCUS”, non vi pare? Forse strizzando un po' gli occhi... Ovviamente però, ammesso che si abbia l'intuizione, dobbiamo comunque andarcene letteralmente in giro a scrivere “HOCUS” ovunque, finché non accade qualcosa. Ma tanto, arrivati a questo punto, il gioco ha già abbondantemente polverizzato il nostro diritto a non essere sottoposti a “cose noiose”...

Non posso andare in quella direzione.
Sei in una barca a remi su una spiaggia di un'isola.

Avere una buona ragione per la quale qualcosa è impossibile. Abbandoniamo il continente e raggiungiamo una piccola isola su una barca a remi in cui, molto comodamente, ci imbattiamo sul nostro cammino. Dopo esserci occupati di tutte le solite scemenze che troviamo su quest'isola, arriva il momento di ripartire. Per proseguire il nostro viaggio potrebbe sembrarci normale utilizzare di nuovo la barca a remi che ci ha condotti fin là, ma ovviamente non è possibile. Perché? Non lo so; il gioco si limita a dirci: “Non posso andare in quella direzione”.

Avere un adeguato numero di sinonimi. Il gioco si aspetta che proseguiamo il nostro viaggio usando una pozione di volare (e, ovviamente, per scoprire in quale luogo dell'isola debba essere bevuta la pozione, l'unico modo è berla continuamente, in ogni stanza, ricaricando dopo ogni tentativo. Ma, giunti a questo punto, è subentrata una sorta di complicità da Sindrome di Stoccolma, e siamo pronti ad accettare anche questo, mettendoci al duro lavoro con un sospiro...), Il fatto è che il sostantivo “pozione”, che ci appare come il più logico da usare, non viene accettato. Possiamo digitare infatti solo “BEVI FIALA” (che sinonimo originale...) o “BEVI LIQUIDO”.

Una moneta d'oro l'uno.

Sei nelle colline sul lato settentrionale delle montagne.

Poter vincere senza sapere quali saranno gli eventi futuri. Proseguendo oltre incontriamo un venditore ambulante che ci offre degli stivali, un pugnale, una brocca da vino, una lente d'ingrandimento, e una tromba. Abbiamo una sola moneta d'oro e nessuna idea di quale di questi oggetti potrebbe rivelarsi utile. E così siamo costretti a salvare il gioco, iniziando a comprarne uno alla volta, per poi proseguire alla ricerca di un enigma risolvibile con quell'oggetto, salvo imbatterci in un vicolo cieco che ci dimostrerà che abbiamo scelto l'oggetto sbagliato. E no, il venditore ambulante non accetta resi...

Sei davanti al castello.

Intorno al castello c'è un fossato pieno di coccodrilli.

Essere in grado di capire un problema, dopo che è stato risolto. Alla fine arriviamo al castello dello stregone. Ci si para davanti un ponte levatoio chiuso. Scopriamo che la soluzione corretta a questo problema consiste nel suonare la tromba comprata dal venditore ambulante – se non altro almeno il dilemma dell'oggetto giusto da acquistare è stato chiarito. Immagino che sia una vaga allusione al cavaliere che, rientrando, suona il suo corno per avvisare il castello del suo ritorno. Ma perché mai dovrebbe funzionare per noi, che siamo i nemici dello stregone? Suonare la tromba non dovrebbe invece attirarci addosso una palla di fuoco? E poi, chi è che ci ha aperto il ponte levatoio? Di certo all'interno non c'è nessun portiere a darci il benvenuto. Che sia una tromba magica? Ma, se davvero fosse una tromba magica che consente l'accesso alla roccaforte, perché diavolo lo stregone l'ha data al venditore ambulante? Forse l'ha semplicemente persa e il venditore ambulante l'ha trovata per strada...? Chi può dirlo?

Dentro il castello, lo scontro finale con lo stregone è uno dei finali più anti-climatici di sempre. Al posto dello stregone, Roberta ci mette davanti un altro labirinto enorme e vuoto (se non altro il gioco, terminando così come era iniziato, ha una sorta di coerenza strutturale interna...). Non lo vediamo nemmeno mai nei suoi panni di stregone, ma solo come uccellino in cui per qualche ragione ha deciso di trasformarsi. Per fortuna abbiamo un anello magico che può trasformarci brevemente in un gatto (ma solo se ci abbiamo armeggiato quanto basta per capire che per attivarlo lo dobbiamo sfregare e non indossare) e... è tutto qui.

E che dire degli altri diritti del giocatore di Nelson? “Non avere il gioco bloccato senza avvertimento”, “Non dover digitare l’unico verbo corretto” e “Sapere come sta evolvendo il gioco” vengono violati così costantemente e per tutto il corso del gioco che andare ad analizzare le rispettive violazioni sarebbe solo un accanimento.

Il pappagallo mangia il cracker e ti è molto grato. Lascia per te una fiala di liquido sul ramo.

Qui c'è una fiala.

Non dover essere Americano per comprendere gli indizi. Questo diritto nasce dall'avversione di Nelson per uno specifico enigma, il famoso diamante del baseball di Zork II della Infocom (di cui parlerò più in dettaglio quando ci arriveremo); da qui la sua inusuale specificità. Credo che potremmo definirlo meglio come il divieto di richiedere al giocatore troppe nozioni specifiche di una determinata cultura, qualunque essa sia. Qui The Wizard and the Princess riesce a non essere troppo offensivo, pur essendoci un punto dove (dopo essere fuggiti su una barca a remi dalla terraferma fino a un'isola tropicale) dobbiamo dare un cracker trovato nel deserto (è incredibile quel che non si trova in un deserto, non vi pare?) a un pappagallo. Anche se non prettamente Americano, credo che il vecchio meme di Polly want a cracker sia noto solo nei paesi di lingua inglese.

Avere un’adeguata libertà d’azione. Entro i confini del suo parser primitivo e del suo primitivo world model, il giocatore ha abbastanza libertà. La libertà di impiccarsi, ma tant'è...

Anche togliendo queste ultime due infrazioni restiamo quindi con ben 15 potenziali violazioni su 17. Non proprio il massimo, ma quasi.

Dopo essermi divertito a giocare, è ora di dire un po' di cose. A qualcuno sembrerà un esercizio inutile quello di sviscerare così in dettaglio un singolo titolo della primissima scena dei giochi d'avventura, quando questa era assolutamente piena di giochi che violavano i diritti dei giocatori. Dopotutto Roberta, come tutti gli altri primissimi game designer, lavorava senza una rete intorno a lei, senza che nessuno potesse passarle la saggezza delle buone pratiche di game design, e con a disposizione solo delle tecnologie estremamente primitive. Si tratta sicuramente di un'osservazione corretta, rispetto alla quale posso difendermi (ma non è una vera e propria difesa) dicendo che verso Roberta sono particolarmente rigido nei miei giudizi, perché ha continuato a fare questo genere di errori per quasi tutta la sua ventennale carriera, quando ormai non potevano più essere invocate da tempo la scuse della mancanza di buone regole di game design e della tecnologia. Poi, certo, avendo  dedicato così tanto tempo negli ultimi sei mesi alle avventure old-school, forse uno sfogo prima o poi mi ci voleva... Di certo ho completamente violato una delle regole base di questo blog: tentare di guardare le opere che analizzo nel loro contesto storico. E quindi adesso è probabilmente una buona idea quella di ritornarci su, chiedendoci perché mai i giocatori del 1980 erano disposti ad accettare questa roba (e per di più a farlo apparentemente con la massima contentezza) e, prima ancora, perché mai i game designer commettessero delle tali violenze contro i loro giocatori.

The Wizard and the Princess conserva ancora oggi un certo appeal. C'è qualcosa di attraente nella sua fiabesca stravaganza e nella sua strabordante mappa incoerente. Se si escludono i porting dell'originale Adventure,The Wizard and the Princess era probabilmente il gioco d'avventura più grande che fosse mai apparso su un home computer. E poi, ovviamente, c'erano quelle immagini, che  oggi sono l'elemento che più ci interessa. E, se oggi quelle immagini ci attraggono come fossero oggetti pittoreschi, nel 1980 erano un “tour de force” tecnico, motivo più che sufficiente per radunare (e far sbalordire) la famiglia, gli amici, e i vicini dinanzi al piccolo Apple installato in un angolo di casa. I proprietari dei primi home computer fino ad allora avevano avuto ben poco di così istantaneamente impressionante da esibire, se non cumuli di testo monocromatico a blocchi scritto nell'inglese strangolato di Scott Adams o pieni di numeri criptici e di codice. Adesso finalmente avevano qualcosa di davvero impressionante da far vedere. Proprio come ogni generazione considera la musica della propria era piena di classici senza tempo e la musica delle generazioni seguenti come spazzatura priva di valore, ogni generazione di gamer ama accusare chi è venuto dopo di essere interessato solo alla grafica scintillante e al sonoro. Beh, sapete cosa? La verità è che ogni generazione di gamer è interessata alla grafica scintillante e al sonoro. È solo che la generazione di cui stiamo parlando adesso ne aveva avuta davvero ben poca a disposizione. E, se dovevano trovarla in un gioco che sembrava quasi una caricatura delle vecchie ostinate avventure testuali, che così fosse...

Detto questo, dobbiamo aggiungere che c'erano comunque dei giocatori che si divertivano (e non poco) con la difficoltà di giochi come The Wizard and the Princess. Alcuni non solo accettavano il rigido parser a due parole, ma lo consideravano parte del divertimento. A loro modo di vedere la risoluzione di un enigma era un processo in due fasi: intuire la soluzione e intuire come comunicarla al computer. A quei tempi c'era spesso una sorta di “machismo” e i giocatori, che si lamentavo dell'ottusità di un tale gameplay, venivano rapidamente etichettati come “non veri avventurieri”. Quanto questi appassionati stessero solo sforzandosi di accettare i soli giochi che avevano a disposizione e quanto invece apprezzassero davvero tutto quel “guess the verb” e la necessità di provare tutto con tutto in ogni luogo, lo lascio decidere a voi... Del resto gran parte del gaming a quel tempo era ancora in una fase embrionale e richiedeva che i giocatori si immaginassero che quegli ammassi primitivi di frustrazioni a cui stavano giocando fossero già le storie interattive immersive che si potevano scorgere all'orizzonte, in un futuro ormai prossimo. E questo può forse iniziare a spiegare tutta quella curiosa animosità dell'epoca d'oro dei giochi d'avventura, che si manifestava col rifiuto (presente ancora oggi nei più nostalgici) di gridare allo scandalo. C'è poi da aggiungere che a quei tempi anche la stampa specializzata non era mai troppo critica nei confronti del software, legata com'era ai publisher da un intreccio di interessi reciproci.  Quel che so è che, durante gli anni '80, come bambino appassionato dei giochi d'avventura (o, almeno, dell'idea che allora avevo di essi), mi infuriavo spesso contro la dura realtà che avevo davanti. E non credo di essere stato il solo.

E i game designer? Ho già scritto qui e altrove del perché si arrivasse a ideare dei gameplay come quello di The Wizard and the Princess: la mancanza di comprensione delle “regole base” del game design, la tecnologia primitiva, nonché la pura e semplice inesperienza degli stessi game designer.  Certo (come ho già avuto modo di ripetere più volte), con un parser e un world model del livello di quello di Scott Adams o delle Hi-Res-Adventures, era difficile mettere in piedi degli enigmi che offrissero una buona sfida e che al tempo stesso non fossero iniqui; con tali strumenti, passare da un enigma complicato a uno impossibile era questione di un battito di ciglia. Ci sono però anche altre considerazioni in merito, che forse sono meno ovvie. Considerate ad esempio che Ken e Roberta vendevano The Wizard and the Princess per 32,95 dollari. Per quel prezzo dovevano garantire ai loro giocatori diverse ore di gioco. Ma al tempo stesso c'era un limite ferreo nella quantità di contenuto che potevano stipare su un singolo floppy disk e su un computer a 48K (The Wizard and the Princess sarà anche stato un gioco insolitamente grande per gli standard del 1980, ma con una soluzione alla mano può pur sempre essere portato a termine in mezz'ora – e gran parte del tempo viene comunque impiegato ad aspettare che le immagini si siano caricate e disegnate a schermo). La soluzione più ovvia era quella di creare un gioco difficile, così che i giocatori fossero letteralmente costretti a passare ore incespicando su ogni singolo blocco di contenuto vero e proprio. In seguito, con la pirateria che diventava sempre più un problema, forse alcuni game designer iniziarono a vedere negli enigmi quasi irrisolvibili una soluzione al problema, perché in questo modo potevano almeno costringere i pirati a comprarsi i libri degli indizi. La Sierra stessa alla fine degli anni '80 dichiarò più volte che le vendite dei libri degli indizi spesso superavano quelle dei relativi giochi. Quello che, ovviamente, ometteva di dichiarare era che questo era un evidente incentivo a creare giochi iniqui, pur di guadagnare qualcosa anche dai pirati, andando così ad aumentare i profitti complessivi di ogni gioco.

Il vero pericolo di un pessimo game design, che esso dipenda dalla pigrizia, dall'avarizia, o semplicemente dalla rigidità (“i giochi d'avventura sono così”), è che i giocatori si stufino di subire gli abusi del gioco e passino ad altro. E se altri generi iniziano a loro volta a offrire esperienze di gioco affascinanti e ricche di narrazione, quel pericolo diventa mortale. Per tutti gli anni '80 i game designer potevano contare su un pubblico passivo di giocatori, catturato quanto basta dall'ideale del gioco d'avventura e dalla tecnologia utilizzata per dargli vita, da accettare di buon grado gli abusi di questi giochi. Ma quando le cose iniziarono a cambiare... Ma così stiamo andando troppo, troppo avanti nel tempo.

Per ora basterà dire che, nonostante i suoi difetti, The Wizard and the Princess fu un successo ancora maggiore di Mystery House. Le classifiche di vendita di quel Settembre della rivista Softalk già lo davano come il secondo software più venduto dell'Apple II, dietro solo a VisiCalc, il colosso del settore business. Rimase costantemente nella top ten di tutto l'anno successivo, arrivando a vendere oltre 60.000 copie, surclassando quindi le vendite di Mystery House (10.000 copie). Alla fine dell'anno Ken e Roberta avevano un gran numero di altri prodotti sul mercato sotto l'etichetta On-Line Systems e aveva affittato il loro primo ufficio vicino alla loro nuova casa a Coarsegold. Il paziente John Williams rinunciò a una promettente carriera come rappresentante del primo distributore di software del mondo per diventare il Dipendente N° 1 della On-Line Systems, dove il suo salario annuo corrispondeva all'incirca a quello che guadagnava al mese nel settore della distribuzione. In un modo molto concreto The Wizard and the Princess aveva fatto la società che avrebbe presto raggiunto la fama mondiale come Sierra Online.

Se volete provare di persona The Wizard and the Princess ho qui l'immagine di un disco che potete caricare nel vostro emulatore preferito. Adesso lasceremo la On-Line Systems per un po', per poi tornarci più avanti, e in quell'occasione prometto che non tratterò altrettanto aspramente le loro altre opere.

Prossimamente: un altro gruppo di vecchi amici che abbiamo già incontrato in un post precedente.

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!

Mystery House - Parte 2
The Digital Antiquarian (traduzione ufficiale italiana)

Mystery House è, secondo il canone, la "prima avventura grafica". Per capire se questa affermazione è corretta, il primo passo è stabilire cos'è un'avventura grafica.

Oggi il termine è generalmente utilizzato per riferirsi ai giochi controllati tramite mouse, nei quali l'utente manipola l'ambiente cliccando sugli "hotspot" di un'immagine (che rappresenta il luogo in cui si trova il suo avatar). Questa però è più un'impostazione di base del genere che una vera e propria definizione; e infatti ricadono generalmente nella categoria anche altri tipi di interazioni. Urge quindi fare di meglio. E, soprattutto, dobbiamo stare particolarmente attenti nel decidere dove collocare il confine fra avventura grafica e avventura testuale. Infatti, qualche anno dopo il punto in cui siamo arrivati con questo blog (1980), sarebbero uscite molte avventure testuali che accompagnavano le proprie descrizioni testuali con delle immagini. Queste immagini non erano però interattive, tanto è vero che spesso erano anche completamente opzionali: il purista poteva semplicemente disattivarle e giocare in modalità completamente testuale, senza alcuna conseguenza. Giochi di questo tipo tuttavia sono meglio definiti come avventure testuali illustrate piuttosto che come avventure grafiche. Quest'ultimo termine implica infatti che la grafica sia essenziale per l'esperienza di gioco, e non una semplice aggiunta ausiliaria. Già questo, a ben vedere, può essere un buon inizio di definizione. A questo aggiungiamo che la grafica dovrebbe essere interattiva, oggetto cioè di manipolazione da parte del giocatore e non delle semplici illustrazioni “da libro delle fiabe”.
Proviamo così:

Un'avventura grafica è una forma di narrativa ludica che ha molte similitudini con l'avventura testuale (anche detta interactive fiction), e all'azione basata sui riflessi favorisce gli enigmi e lo sviluppo della storia. Tuttavia il giocatore e il programma comunicano fra loro principalmente attraverso immagini, invece che attraverso il testo. Queste immagini sono tendenzialmente interattive -sono cioè oggetto di manipolazione da parte del giocatore- e essenziali all'esperienza dell'opera.

Dati questi requisiti, il mio primo istinto dopo averlo ripreso in mano dopo tanti anni è stato quello di scartare al volo l'idea che Mystery House potesse essere la prima avventura grafica. Era evidente -pensavo- che fosse la prima avventura testuale illustrata (il che di per sé sarebbe stata comunque un'evoluzione significativa!), il cui nucleo principale era però ancora quello di una “semplice” avventura testuale. Cavolo, se mi sbagliavo! Mystery House salta a piè pari il passo logicamente successivo del genere (l'avventura testuale illustrata, appunto) per fare qualcosa di molto più audace: gran parte del nucleo dell'esperienza si gioca infatti non a livello testuale ma a livello grafico.

Lasciate che vi faccia vedere cosa intendo. Qui siamo all'inizio del gioco, appena entrati nel salone d'ingresso della magione.

Sei in un salone d'ingresso. Alcune porte conducono a est, ovest e sud. Una scalinata sale verso l'alto.

Quella nota in basso a sinistra (molto convenientemente etichettata “NOTA” a caratteri giganti) non viene descritta da nessuna parte nel testo: sappiamo che esiste solo attraverso l'immagine.E adesso osservate cosa accade quando la raccogliamo.

Sparisce! Queste non sono semplici immagini statiche, ma è vera grafica interattiva. E, quando leggiamo la nota, ancora una volta le conseguenze non appaiono nel testo, ma nella parte di schermo dedicata alla grafica.

IN QUESTA CASA SONO NASCOSTI DEI GIOIELLI PREZIOSI. CHI LI TROVA, SE LI TIENE.

E poi, se portiamo la nota altrove e ce la lasciamo, essa appare immediatamente nella scena in cui la lasciamo.

Per quanto oggi ci venga da ridere di fronte alle immagini stilizzate che sembrano scarabocchi di bambini, questa era roba notevole, davvero notevole all'epoca. Qui i Williams stavano sviluppano il prototipo di un nuovissimo paradigma dei giochi d'avventura, quando le avventure testuali erano ancora nella loro infanzia! La sola novità tecnologica poteva vendere molte migliaia di copie!

Il che è una vera fortuna, perché il gioco vero e proprio non è niente di più di quello che ci possiamo aspettare, considerando l'inesperienza di Roberta. È una specie di giallo, ma un giallo stranamente statico; appena abbandoniamo il salone d''ingresso, cinque delle sette persone che vi abbiamo incontrato vengono immediatamente sparse per la casa sotto forma di cadaveri, senza darci alcuna possibilità di evitarne la morte. Possiamo solo ispezionare tutto spostandoci attraverso i passaggi segreti e i labirinti tipici dei giochi d'avventura, finché non ci ritroviamo allo scontro finale con l'assassino (la cui identità è sempre stata palese): non c'è nessun giallo da risolvere, a meno che contare chi è vivo e constatare chi (all'apice dell'avventura) sta cercando di ucciderci non significhi risolvere un giallo. The Count, che all'epoca era ancora il paradigma della narrativa ludica dinamica, non aveva assolutamente nulla da temere. E infatti, quasi che lei stessa avesse dei dubbi sul genere scelto, Roberta ci infila dentro anche la sotto-trama della caccia al tesoro attraverso l'indizio della nota di cui sopra, riportandoci così sul terreno delle avventure più tradizionali. L'effetto finale rende Mystery House un piccolo gioco spietato e un po' macabro, che nella sua assurdità esibisce un certo humour nero: ce ne andiamo in giro scoprendo un cadavere dietro l'altro, ma (in pieno stile da vero protagonista di un gioco d'avventura) non ci lasciamo minimamente distrarre da tutto ciò nella nostra caccia ai gioielli.

Sei nel cortile recintato sul retro. La recinzione costeggia il lato della casa proseguendo in direzione  nord. Qui c'è un cadavere.

[…] capelli biondi sul suo vestito. Sei in una piccola camera da letto. Qui c'è un cadavere.

La grafica a volte crea dei problemi perfino peggiori di quelli tipici del periodo, fra cui anche quello che forse è uno dei labirinti più crudeli mai visti in un gioco d'avventura. Perfino la navigazione “normale” è una lotta continua: le istruzioni del gioco ci dicono che il nord è tipicamente nella parte alta dello schermo, il sud in basso, ecc., ma poi il gioco stesso viola queste linee guida da subito (anzi, letteralmente dalla prima schermata!). Il risultato è che non siamo mai veramente sicuri di quale sia la direzione verso cui siamo voltati e quindi non è mai possibile orientarsi correttamente. Non che questo ci potesse essere particolarmente utile: questo è un gioco d'avventura classico, in cui nessuna location è allineata correttamente con le altre, nemmeno fosse la creazione di un architetto Vittoriano con una passione per M.C. Escher!

In particolare la sala da pranzo è un'autentica sala degli orrori da esaminare in dettaglio.

L'oggetto sul tavolo è una candela, disegnata in modo un po' rozzo ma tutto sommato identificabile. Quella... cosa... triangolare sulla parete in fondo dovrebbe rappresentare un foro nella parete che, senza nessuna ragione apparente, dovrebbe contenere una chiave essenziale per proseguire. Se proviamo a interagire con il foro mentre trasportiamo la candela o i fiammiferi accessi, inciampiamo immediatamente, incendiando il tappeto e morendo, a meno che non si abbia con noi una brocca d'acqua e che non si azzecchi, in un singolo turno, la sintassi necessaria per usarla sul fuoco.

Inciampi sul tappeto e cadi. Oh, oh, con la tua candela hai innescato un incendio!

Dimenticavo: stavolta il nord è a sinistra e il sud è a destra, ma ovviamente l'unico modo per scoprirlo è provando e sbagliando.

Uno degli “enigmi” principali consiste nello spostare (con il comando TO MOVE) un armadietto in cucina, senza che ci sia nessuna ragione apparente per farlo e nonostante il gioco fino a quel momento avesse cocciutamente negato di conoscere quel verbo.

Dietro, la parete è stata chiusa con dei mattoni.
Sei nella cucina. Ci sono un frigo, una stufa e un armadietto.

Dopo essersi aperti la strada oltre l'apertura murata che abbiamo appena scoperto, nel vecchio passaggio segreto in disuso, troviamo (in modo del tutto illogico) una vittima appena assassinata. E la mimesi va a farsi benedire.

In conclusione: no, Mystery House non è un grande gioco... Anzi, a tratti ci appare come un'esilarante collezione dei peggiori cliché dei giochi d'avventura. Tuttavia, alla luce della sua genealogia e delle sue innovazioni formali molto concrete, probabilmente mi sono già dilungato fin troppo sui suoi numerosi errori.  La maggior parte dei suoi contemporanei non erano poi molto meglio, e non stavano nemmeno inventando un paradigma di giochi di avventura completamente nuovo (certo, dall'altro lato però potrei rimproverare a Roberta il fatto di aver continuato a progettare enigmi altrettanto pessimi per molto tempo ancora, quando ormai avrebbe dovuto aver imparato a fare di meglio – ma questo è materiale per post futuri...).

Se volete provare di persona Mystery House, vi suggerisco assolutamente di considerarlo un pezzo di storia, piuttosto che una vera e propria esperienza di gioco o di narrativa. In altre parole: usate una soluzione, che vi permetterà di ridere (invece che di piangere) di fronte alle sue assurdità.
Il modo migliore di giocarci è tramite Java sul Virtual Apple II website.

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

Articoli precedenti:

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

Due diverse culture di avventurieri
Microsoft Adventure
La Narrativa Ludica già nota come Storygame
L'Ascesa dei Giochi Esperienziali
Dungeons And Dragons
Una Definizione per i Giochi di Ruolo per Computer
Dal Tavolo al Computer
- I Primi Giochi di Ruolo per Computer
- Temple of Apshai
- Un 1980 Indaffarato
- L'Interactive Fiction di Robert Lafore
- Cestinando il Trash del TRS-80
- Jobs e Woz
- L'Apple II
- Eamon, Parte 1
- Un Viaggio nel Fantastico Mondo di Eamon
- Eamon, Parte 2
- Il mio Problema con Eamon
- Ken e Roberta
- Mystery House - Parte 1



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!

Intervista all'autore e gameplay di Crysys - Il tocco del caos

A seguito della recensione pubblicata di Crysys, avventura testuale per MS-Dos del 1986, siamo riusciti a contattare l'autore dell'avventura Mario Pettenghi ed ne è scaturita una bella chiacchierata.

Dopo 30 anni qualcuno gioca al tuo gioco e ne scrive una recensione. Cosa ne hai pensato?

Posso pensare solo il meglio. Ho letto la recensione e l'ho apprezzata moltissimo. Primo per la pazienza grazie alla quale siete riusciti a utilizzare questo gioco e secondo per il viaggio nel tempo in cui mi avete coinvolto.

Sorprende con piacere incontrare nuovi amici che a millenni di distanza condividono ancora il piacere delle adventure testuali.

Grazie anche per i giudizi emessi davvero troppo positivi. Il gioco era appena appena passabile ma il progetto che c'era dietro, ovvero un ambiente di sviluppo per adv, era di buona qualità per l'epoca.

Allora perchè non ci spieghi meglio questo progetto sviluppato in Basic?

L'avventura testuale Crysys uscì allegata per la prima volta sulla rivista per PC IBM compatibili MS-Dos: PC Disk nel lontano 1986.
Noi abbiamo ritrovato su internet una copertina; purtroppo non si tratta dell'edizione originale ma di una versione ripubblicata dall'editore per conto dell'Olivetti.

Perdona un tocco d'orgoglio nerd, l'avventura non era esattamente sviluppata in Basic, ma in in linguaggio intermedio creato da zero da un malefico trio (Mario, Andrea e l'altro Mario) durante le ore libere nel servizio militare in tempi di processori 8086 con 256 KB di Ram e di primi compilatori C. Parser, elaborazione degli oggetti, inventario erano gestiti in un linguaggio compilato, compattissimo, tokenizzato e veloce (l'obiettivo era inizialmente di competere con Infocom e Level 9 con avventure da miliardi di locazioni e in un secondo tempo conquistare la Terra, eravamo giovani e modesti). Il compilatore Basic era usato come una specie di loader iniziale, se ricordo bene. Non so a che punto realizzammo l'avventura che hai provato: nel corso del tempo ciascuno di noi tre aggiunse pezzi in C, gestori di personaggi (oggi li chiamano AI NPC) e mille moduli inverosimili. Il work in progress del nostro ambiente per la creazione di avventure, per la cronaca, non fu mai terminato.

Da cosa avete preso spunto per progettare il vostro ambiente?

L'idea dell'ambiente era nata sulla scia di un articolo pubblicato su Byte del maggio 1987, «An Adventure Authoring System» (chi mastica qualcosa di programmazione può leggerlo qui). I concetti espressi vennero interpretati, metabolizzati e coniugati con le risorse a disposizione (Olivetti M24 con 8086 a 8 MHz), con le nostre competenze (Basic, C, Assembler Z80 e 8088) e con una marea di tempo libero. Bei tempi.

C'è ancora qualche traccia fisica dell'ambiente di sviluppo che avevate creato?

Dell'ambiente forse potrebbe esserci qualche sorgente, non so di quale versione, su floppy disc da 5 pollici e mezzo, formattati Dos 3.X, in una cantina buia nella zona nord di Milano. Purtroppo sono protetti da un basilisco, resistente alla magia, aiutato da un esercito di zombie. Serve una torcia, un amuleto e un lettore di floppy. Nessuna speranza di funzionamento o di riutilizzo e in tutta sincerità non ne vale molto la pena. Non era di certo un'opera d'arte e nemmeno un lavoro terminato.

Video del gameplay registrato da Leonardo Boselli sul suo canale Twitch:

Quali erano i progetti per le altre due AT che avrebbero completato la trilogia?

Ehm, le altre due avventure erano ambientate in altri due mondi/pianeti un po' più estesi, sempre con tematiche fantasy con tanta roba ispirata dal ciclo fantasy del Campione Eterno di Moorcook (Elric, Corum, Hawkmoon). Se fa sorridere oggi, negli anni '70/'80 era la cosa più prossima ad Halo, Skyrim, Diablo o simili, per coinvolgimento.

Nell'era di internet, le AT sono facilmente disponibili su siti come il nostro, ma all'epoca come avete pubblicato la vostra avventura?

Crysys era stato pubblicato su una rivista mensile con floppy allegato, PC Disk, edita ai tempi da Editronica. Avrebbe dovuto essere una serie di più avventure a cadenza irregolare (sì, il pezzo d'ambra sarebbe servito a qualcosa, ma morire se mi ricordo a cosa, nella seconda parte). Ci fu un cambio di editore, la testata passò al Gruppo Editoriale JCE, le adventure testuali non riscossero molto interesse tra i responsabili della casa editrice e in modo un po' passivo il progetto si scolorì e non venne completato. Non uso la parola 'purtroppo', se noti. Il genere, come sappiamo, era già malaticcio di suo e le prime avventure grafiche avrebbero dato il colpo di grazia, almeno per un pubblico 'da edicola'.

Avete fatto altre avventure?

No, nessun altra avventura pubblica. Furono messe insieme una decina di piccole, piccolissime mini avventure per il collaudo dell'ambiente di sviluppo sfruttando decine di poveri amici malcapitati. (Non sapete quanti non riescono a trovare una chiave nascosta sotto uno zerbino).

Di te cosa ci dici, giochi ancora alle AT?

Sì, ogni tanto gioco ancora alle AT. Molto sporadicamente, su emulatori impolverati (CP/M, Dos, ZX Spectrum). Riconosco che prevale la nostalgia sulla bontà dell'intrattenimento.
Mi sono tolto qualche soddisfazione seguendo i walkthrough di giochi che avevo abbandonato (Zork 2 o 3, l'irrisolvibile Valkyrie 17, Snowball, qualcosa ancora più vecchio di Scott Adams....). Non ho seguito con attenzione quelle basate sugli interpreti Infocom, solo qualche prova nei momenti di astinenza.

Hai detto che hai scritto l'avventura insieme ad altri due autori, sai fine hanno fatto?

Con gli altri due autori-amici ci siamo persi di vista. Accomunati casualmente dal servizio militare, ciascuno viveva in città diverse. Uno si occupa professionalmente di videoproduzioni per qualche rete televisiva, il secondo credo abbia lavorato come sviluppatore e system designer per un po' negli Stati Uniti e poi sia tornato in Italia, e lavori sempre in ambiente informatico. Colposamente persi di vista, senza alcun motivo, dopo tante promesse di risentirci.

Da cosa è nata l'idea per questa AT?

L'ispirazione viene da due cicli diversi di romanzi fantasy. Purtroppo sono quasi introvabili anche se ogni tanto appaiono su eBay. Il primo è il ciclo C.J. Cherryl (I fuochi di Azeroth - La saga di Morgaine la regina bianca - https://it.m.wikipedia.org/wiki/C._J._Cherryh ) il secondo è il ciclo di Elric scritto da Michael Moorcook.

Ringraziamo Mario per il tempo dedicatoci e per aver creato questa bella avventura! Se volete fargli domande o giocare Crysis con noi, ci vediamo sull'OGI Forum, dove stiamo continuando a fargli domande!

Guida alla programmazione con Inform 6
Programmiamo avventure testuali!

Questi articoli si trovano pubblicati anche su livello99.it: senza la proposta avanzatami dal proprietario del sito, questo progetto, che pure qualche volta mi era passato per la testa, non sarebbe stato possibile.

[ogni tanto rileggendo gli articoli mi capita di trovare errori/refusi: i pdf che si trovano qui non sono periodicamente aggiornati, mentre su livello99.it si trovano sempre gli articoli corretti]

UN NUOVO MANUALE?

Primo articolo: Programmiamo avventure testuali! - (download pdf)

Secondo articolo: L'essenziale per cominciare - (download pdf)
-> soluzione esercizio proposto

Terzo articoloAlberi... ma non piante! - (download pdf)
-> soluzione esercizio proposto

Quarto articolo: Scatole cinesi - (download pdf)
-> soluzione primo esercizio proposto (teletrasporto)
-> soluzione secondo esercizio proposto (ladro)

Quinto articoloEditing di testo - (download pdf)

Sesto articoloCammina cammina - (download pdf)
-> soluzione esercizio

Settimo articoloScenografia portami via - (downlaod pdf)

Ottavo articoloNon aprite quella porta! - (download pdf)
-> soluzione esercizio

Nono articoloLe "frecce" al nostro arco - (download pdf)
-> soluzione esercizio

Decimo articoloC'è chi vince, c'è chi perde, noi programmiamo casomai - (download pdf)

Undicesimo articoloAncora sul punteggio (punteggio negativo e rango dell'avventuriero) - (download pdf)
-> esercizio proposto [presto disponibile]
-> soluzione esercizio proposto [presto disponibile]

Dodicesimo articoloStringhe! - (download pdf)
-> soluzione esercizio

Tredicesimo articoloCicli! - (download pdf)

Quattordicesimo articoloCogli la prima mela (per vedere di nascosto l'effetto che fa) - (download pdf)
-> elenco verbi (tratti dal manuale di Vincenzo Scarpa) [presto disponibile]
-> soluzioni

Questi articoli e tutti i loro esempi (soluzioni agli esercizi incluse) sono copyright © 2015 di Mariano Sassi
Possono essere liberamente distribuiti in formato elettronico o in copie cartacee a condizione che:
(i) le copie (o parti di esse) ricavate e distribuite siano uguali, in tutto e per tutto, agli originali
(ii) non si traggano profitti dalle copie (o parti di esse) ricavate e distribuite
(iii) venga sempre indicata la fonte con nome e cognome e/o questo sito di riferimento
Non mi assumo alcuna responsabilità per errori o omissioni contenuti negli articoli, o per danni
risultanti dall’utilizzo improprio delle informazioni contenute in essi.

AV 3X10 - Quando uccisi il troll con la spada

Titolo:
Quando uccisi il troll con la spada
Serie:
Archeologia Videoludica
Durata:
1 h 37 min.
Pubblicato il:
16 giugno 2013

Nuovo e affascinante episodio di Archeologia Videoludica, tutto creato a colpi di parser! Il protagonista del nostro racconto è infatti Zork, una delle prime avventure testuali prodotte da Infocom e pietra angolare della storia videoludica.

Siamo nel 1980 e dopo la creazione del magico impero sotterraneo il mondo dei videogames non sarebbe mai stato più come prima, perso fra oscuri labirinti, inquietanti nemici e magici puzzle; vi racconteremo così le sue origini, la sua storia e la sua diffusione che riuscì a superare addirittura la limitazione di non essere mai stato (finora) tradotto in italiano.

Alla tastiera virtuale un interessante trio composto da Simone "AT" Pizzi, Alex "Z-Machine" Raccuglia e Roberto "il Grue" Bertoni, accompagnati da Marco Vallarino, una delle più promettenti penne della scena attuale e autore di Darkiss, un titolo dedicato al mondo dei vampiri che vi invitiamo a provare.

Guest stars dell'episodio uno dei maestri italiani delle avventure testuali, Enrico Colombini insieme e Paolo Gabriele Sfredda, super appassionato di tutto quello che sia Interactive Fiction.

Accendete quindi le vostre macchine virtuali e mettetevi comodi ad ascoltare la storia che, ancora una volta, entra ad alte frequenze nelle vostre cuffie; come sempre, non mancate di raccontarci di voi e delle vostre impressioni sull'Ogi Forum!

Errata corrige

Ovviamente Infocom è americana, nonostante quanto professato in trasmissione. Ci scusiamo per l'errore non voluto.

IN QUESTO EPISODIO

Il mondo nelle parole

Raccontiamo brevemente le origini di Infocom, la software house per antonomasia quando si parla di avventure testuali e mondi fantastici; ci addentreremo all'interno delle pieghe della sua storia, di quando in una remota parte del Mit la leggenda ebbe inizio.

You're standing in an open field west of a white house...

Zork cosa ha rappresentato per una generazione di videogiocatori? Aiutati da Marco Vallarino, ripercorriamo le emozioni dietro un semplice parser, le sue novità e le potenzialità di un linguaggio che non smette mai di stupire.

Sotto l'Impero

Ma alla fine cosa c'era sotto quella dannata casa? Qual è lo scopo di questo viaggio? In maniera forse frammentaria, ma ricca di vividi ricordi, la mitica ciurma di Archeologia Videoludica vi racconta quello che non avreste mai voluto sapere. Almeno prima di aver conosciuto Zork.

Z-Machine, il linguaggio universale

Chi meglio del mitico Alex Raccuglia poteva portarci a conoscere una delle innovazioni più potenti all'interno della storia videoludica? Parliamo ovviamente della Z- Machine e della sua incredibile flessibilità che ne hanno fatto una delle pietre angolari dello sviluppo delle avventure in tutto il mondo.

Il grue nascosto

Non potevamo che chiudere, orfani del mitico Distruggitore, con tutta una serie di chicche, note e meno note, dedicato al mondo di Zork e al suo essere ancora vivido riferimento per la cultura popolare di chi è cresciuto pane e parser.

Altri links

La traduzione di Zork a cura di Oldgamesitalia
Dietro le quinte della traduzione di Zork (contributo speciale by Whovian)
La pagina Wikipedia di Zork
Un ottimo sito per iniziare a parlare di Zork e affini
Darkiss l'avventura di Marco Vallarino
Il sito di Enrico Colombini
Il sito di Paolo Gabriele Saffredda