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

Ormai persino i lettori più distratti avranno capito cosa bolle in pentola, quale segreto si annida tra le pagine polverose di OldGamesItalia. Dopo la gloriosa traduzione di Zork I - The Great Undreground Empire, è in cantiere la localizzazione del secondo capitolo della fortunata trilogia di Infocom.
E quale modo migliore di celebrarne la pubblicazione che pubblicare gli articoli del nostro Antiquario Digitale dedicati proprio alla genesi di Zork e di Infocom? Ed è per l'appunto dell'effettiva nascita di questa mitica azienda di videogiochi, agli albori dell'era dei microcomputer, che tratterà l'articolo di oggi.
 
Ma prima, l'immancabile indice degli articoli del ciclo Infocom:
 
La Nascita della Infocom
ZIL e la Z-Machine
Come Vendemmo Zork
Giochi a Parser
Esplorando Zork, Parte 1
Esplorando Zork, Parte 2
Esplorando Zork, Parte 3
Infocom: Come Cavarsela da Soli
Zork II, Parte 1
Zork II, Parte 2
Lo Zork User Group
Zork III, Parte 1
Zork III, Parte 2
 
Buona lettura avventurieri... e portate le lanterne!
 
Festuceto
 
Mentre il Dynamic Modeling Group completava gli ultimi ritocchi su Zork e finalmente se ne congedava, al MIT si iniziava ad avvertire la fine di un’era. Marc Blank stava per laurearsi in medicina e stava per iniziare il suo internato a Pittsburgh, cosa che avrebbe reso impossibile continuare la sua opera di "hackeraggio" intensivo al MIT, nonostante le sue capacità apparentemente sovrumane. Altri ancora stavano ultimando i loro programmi di laurea al MIT, oppure (a forza di attardarsi all'università) stavano esaurendo le giustificazioni per ritardare ancora l'inizio delle loro “vere” carriere, con dei veri stipendi. Stava insomma per iniziare un esodo generazionale, non solo dal Dynamic Modeling Group ma proprio dal Laboratory for Computer e dall'AI Lab del MIT in generale. Le pressioni del mondo esterno avevano infine fatto breccia nell'utopia hacker del MIT, pressioni che negli anni immediatamente successivi, l'avrebbero cambiato per sempre. Gran parte di questo cambiamento originò però dall'invenzione dei microcomputer.
 
La maggior parte di coloro che frequentava gli ambienti dell’hacking istituzionale, tipo il MIT, all’inizio non era particolarmente entusiasta di quella che veniva chiamata la rivoluzione dei PC. Il che non deve sorprenderci. Quei primi microcomputer erano delle macchine con limiti assurdi. Gli “hacker casalinghi” che le comprarono (spesso costruendosele da soli) erano eccitati dalla semplice idea di avere accesso illimitato a un qualcosa che, almeno lontanamente, rispondesse alla definizione di “computer”. Invece i privilegiati che occupavano un posto in un’istituzione tipo il MIT, non solo avevano accesso illimitato (o quasi) ai suoi sistemi, ma tali sistemi erano anche abbastanza potenti da poter farci davvero qualcosa. Che fascino poteva avere un Altair o anche un TRS-80 in confronto ai sofisticati sistemi operativi come il TOPS-10 o il TOPS-20 o l’Incompatible Timesharing System, con linguaggi di programmazione ben strutturati come il LISP e l’MDL, con ricerche nei campi dell’intelligenza artificiale e del linguaggio naturale, e che avevano perfino dei giochi in rete come Maze, Trivia [il gioco a quiz di cui abbiamo già parlato; ndAncient] e, ovviamente, Zork? Il mondo dei microcomputer ai loro occhi doveva sembrare irrimediabilmente privo di cultura e di educazione, privo di quella vera tradizione di hacking che ormai affondava le sue radici in oltre venti anni di esperienza. Come si poteva pensare di scrivere dei programmi complessi usando il BASIC? Quando molti degli hacker istituzionali si degnarono di accorgersi delle nuove macchine, fu con atteggiamento sprezzante; Stu Galley decretò che il motto non ufficiale del Dynamic Modeling Group diventasse: “Noi odiamo i micro!”. Consideravano i microcomputer come poco più che dei giocattoli, che del resto era grossomodo la reazione avuta da gran parte della popolazione.
 
Già nella primavera del 1979, tuttavia, stava diventando via via più chiaro, a tutti coloro che volevano vederlo, che quelle piccole macchine avevano i loro usi. WordStar, il primo word processor per microcomputer davvero utilizzabile, era disponibile già da un anno, e stava portando sempre più macchine basate sul CP/M negli uffici e perfino negli studi degli scrittori. Alla West Coast Computer Faire di quel maggio, Dan Bricklin mostrò pubblicamente per la prima volta VisiCalc, il primo foglio elettronico del mondo, che avrebbe rivoluzionato la contabilità e la progettazione finanziaria. “Come hai potuto fare senza?”, chiedeva la prima pubblicità che ne anticipava la pubblicazione, con un'iperbole che (fu subito chiaro) si sarebbe rivelata assai preveggente; qualche anno più tardi, milioni di persone si chiederanno esattamente la stessa cosa. A differenza di WordStar e perfino di AdventureLand di Scott Adams, VisiCalc non era una versione più limitata di un concept sviluppato sui computer istituzionali e poi implementato sull’hardware dei microcomputer. Esso era stato concepito, progettato, e implementato interamente sull’Apple II; la prima idea autenticamente nuova nata su un microcomputer, il simbolo di un imminente cambio della guardia.
 
I microcomputer portarono molti, molti più utenti nel mondo dei computer di quanti non ce ne fossero mai stati. Il che portò molti più investimenti privati nel settore, guidati da una nuova realtà: con questa roba si potevano fare soldi veri. E questa consapevolezza portò dei grandi cambiamenti al MIT e nelle altre istituzioni di hacking “puro”. È (tristemente) famosa la spaccatura in due che avvenne durante l’inverno e la primavera del 1979 all’interno dell’AI Lab in seguito alla disputa fra Richard Greenblatt (che sostanzialmente all’interno del MIT era il decano della tradizionale etica degli hacker) e un più pragmatico amministratore di nome Russell Noftsker. Insieme a un piccolo team di altri hacker e di ingegneri informatici, Greenblatt aveva sviluppato un piccolo computer a utente singolo, una sorta di “boutique micro”, il primo di quelle che sarebbero poi state chiamate “workstation”, ottimizzato per far girare il LISP. Credendo che il progetto potesse avere un vero potenziale commerciale, Noftsker avvicinò Greenblatt con la proposta di creare una società che lo producesse. Greenblatt inizialmente si disse d’accordo, ma ben presto si dimostrò (almeno dal punto di vista di Noftsker)  indisponibile a sacrificare anche il più piccolo dei principi degli hacker dinanzi alla realtà degli affari. I due si lasciarono in malo modo, con Noftsker che portò con sé gran parte dell’AI Lab per implementare il concept originale di Greenblatt attraverso la Symbolics, Inc. Sentendosi disilluso e tradito, alla fine anche Greenblatt se ne andò, per formare una sua società, di minor successo, la Lisp Machines.
 
Non è che nessuno del MIT, prima di allora, avesse mai fondato una società, né che il commercio non si sia mai mischiato con l’idealismo di quegli hacker. Gli stessi fondatori della DEC, Ken Olson e Harlan Anderson, erano stati due allievi del MIT, che nella metà degli anni ‘50 si erano occupati, come studenti, del progetto di base di quella che sarebbe poi diventata la prima macchina della DEC, il PDP-1. Da allora il MIT ha sempre mantenuto una relazione privilegiata con la DEC, testando il loro hardware e, cosa ancora più importante, sviluppando del software estremamente essenziale per le macchine della società; una relazione che era (a seconda di come la si guarda) o una miniera d’oro per gli hacker che dava loro continuo accesso alle ultime tecnologie, oppure un brillante piano della DEC per mettere al proprio servizio alcune delle menti migliori dell’informatica di quella generazione senza pagare loro un centesimo. Nonostante questo, ciò che stava accadendo al MIT nel 1979 sembrava qualitativamente diverso. Questi hacker erano quasi tutti programmatori di software, dopotutto, e il mercato dei microcomputer stava dimostrando che adesso era possibile vendere autonomamente il software, in opere preconfezionate, proprio come avviene con un disco o con un libro. Un uomo saggio una volta ha detto: “il denaro cambia tutto”. Molti hacker del MIT erano eccitati all’idea del possibile lucro, come risulta evidente dal fatto che i più scelsero di seguire Noftsker fuori dall’università, piuttosto che l’idealistico Greenblatt. Solo una manciata di loro, come Marvin Minsky e il cocciutissimo Richard Stallman, restarono indietro e continuarono a seguire fedelmente la vecchia etica degli hacker.
 
I fondatori della Infocom non erano fra gli irriducibili. Come si intuisce già dal loro gesto di aggiungere una protezione (oggi suona quasi ridicolo scriverlo) all’Incompatible Timesharing System per proteggere il codice sorgente del loro Zork (una cosa che avrebbe fatto innalzare le urla di protesta di Stallman almeno su due diversi livelli), la loro devozione all’etica degli hacker era quantomeno negoziabile. E infatti Al Vezza e il Dynamic Modeling Group stavano rimuginando su possibili applicazioni commerciali per le creazioni del gruppo già dal 1976. Alla fine del semestre primaverile del 1979, tuttavia, sembrò palese che se questa versione del Dynamic Modeling Group (sul punto di sparpagliarsi ai proverbiali quattro venti) voleva fare qualcosa di commerciale, quello era il momento giusto per iniziare. E del resto molti altri al MIT stavano facendo la stessa identica cosa, no? Non aveva senso restare da soli in un laboratorio vuoto, come accadde letteralmente al povero Richard Stallman. In ogni caso, era così che Al Vezza vedeva la situazione e i colleghi da lui diretti (ansiosi di restare connessi e tutt’altro che contrari all’idea di aumentare i propri modesti stipendi universitari) accettarono di buon grado.
 
E così la Infocom venne ufficialmente fondata il 22 Giugno 1979, con dieci azionisti. Fra questi c’erano tre dei quattro hacker che avevano lavorato a Zork:  Tim Anderson, Dave Lebling, e Marc Blank (appena diventato dottore e già pendolare dal suo internato medico a Pittsburgh). Insieme a loro c’erano anche altri cinque membri (attuali o passati) del Dynamic Modeling Group: Mike Broos, Scott Cutler, Stu Galley, Joel Berez, Chris Reeve. E poi c’era lo stesso Vezza e anche Licklider, che accettò di unirsi al gruppo in una sorta di ruolo di consigliere, lo stesso che aveva rivestito al Dynamic Modeling Group del MIT. Oguno di loro raggranellò ogni finanziamento che poteva ottenere, da 400 $ fino a 2.000 $, e in cambio ricevette una proporzionale quota di azioni della nuova società. I fondi iniziali ammontavano a 11.500 $. Il nome della società era inevitabilmente vago, tanto più se consideriamo che nessuno sapeva cosa avrebbe prodotto quella società (se mai avesse prodotto qualcosa). Le parole composte da due termini troncati e vagamente futuristici erano estremamente in voga fra le società tecnologiche dell’epoca (Microsoft, CompuWare, EduWare) e la Infocom seguì la tendenza, scegliendo il nome su cui “tutti avevano meno obiezioni”.
 
 
Come dovrebbe essere chiaro da quanto sopra, non si può certo dire che la Infocom iniziò sotto i migliori auspici. La definirei una “startup da garage”, se non fosse che loro non avevano nemmeno un garage. Per alcuni mesi la Infocom esistette più come una società astratta sospesa in un limbo, che come una vera impresa in affari. Non ebbe nemmeno il suo primo indirizzo postale (una cassetta postale) fino al Marzo del 1980. Inutile dire che nei mesi successivi nessuno dei soci stava lasciando il proprio lavoro, mentre, di tanto in tanto, si incontravano per discutere il da farsi. Ad agosto, Mike Broos si era già stancato dell’andazzo e uscì dal progetto, lasciando quindi nove soci. Tutti furono concordi sul fatto che avevano bisogno di qualcosa da pubblicare in modo relativamente veloce, per far decollare la società. Solo allora sarebbero potuti seguire dei progetti più ambiziosi. Il problema era cosa avrebbero potuto fare per quel loro primo progetto.
 
Gli hacker passarono in rassegna i loro vecchi progetti del MIT, in cerca di idee. Continuavano a tornare sui giochi. C’era quel gioco a quiz, ma sarebbe stato difficile inserire abbastanza domande su un singolo floppy disk per dare un senso alla cosa. Più intrigante era il gioco chiamato Maze. I giochi arcade erano esplosi in quegli anni. Se la Infocom avesse potuto creare una versione di Maze per i cabinati, avrebbero avuto un qualcosa di unico, senza precedenti. Per farlo però sarebbe stato necessario un progetto ingegneristico enorme, sul lato hardware oltre che su quello software. I soci della Infocom erano tutti in gamba, ma erano tutti hacker di software e non di hardware, e di soldi ce n’erano ben pochi. E poi, ovviamente, c’era Zork… ma non c’era nessun modo di infilare un gioco d’avventura da 1 MB in un microcomputer da 32 K o 48 K. E poi ad Al Vezza non piaceva affatto l’idea di entrare nel settore dei giochi, perché temeva che ciò avrebbe potuto compromettere il nome della compagnia, anche se si fosse trattato solo di accumulare dei fondi iniziali per avviare le attività. E così ci furono abbondanti discussioni su altre idee, più legate al mondo degli affari, sempre tratte dalla storia dei progetti del Dynamic Modeling Group: un sistema di indicizzazione dei documenti, un sistema di email, un sistema di elaborazione testi.
 
Nel frattempo, Blank viveva a Pittsburgh ed era piuttosto scontento di ritrovarsi tagliato fuori dai vecchi tempi dell’hacking al MIT. Per fortuna aveva almeno una vecchia connessione con il MIT: Joel Berez, che prima della laurea nel 1977 aveva lavorato al Dynamic Modeling Group. Egli aveva trascorso gli ultimi due anni a Pittsburgh, lavorando nella ditta di famiglia (esperienza che forse convinse gli altri a nominarlo Presidente della Infocom nel 1979). Blank e Berez presero l’abitudine di ritrovarsi insieme per mangiare cinese (alimento alla base della dieta di ogni hacker) e per rimembrare i vecchi tempi. E tutte quelle loro conversazioni continuavano a ritornare su Zork. Era davvero impossibile immaginarsi di portare il gioco su microcomputer? In poco tempo le conversazioni passarono dal nostalgico al tecnico. Ma, come iniziarono a parlare delle questioni tecniche, si affacciarono altre sfide, anche al di là della mera capacità computazionale dei microcomputer.
 
Se anche avessero potuto in qualche modo portare Zork su microcomputer, quale avrebbero scelto? Il TRS-80 era di gran lunga quello più venduto, ma l’Apple II (la Cadillac della trinità del 1977) stava iniziando a guadagnare terreno, grazie all’aiuto del nuovo modello II Plus e di VisiCalc. Ma l’anno prossimo, e quello dopo ancora… chi poteva dirlo? E poi tutte queste macchine erano irrimediabilmente incompatibili l’una con le altre, il che significava che per raggiungere le diverse piattaforme sarebbe stato necessario implementare Zork (e ogni altro futuro gioco d’avventura si decidesse di sviluppare) di nuovo, ogni volta, su ciascuna di tali macchine. Blank e Berez si misero alla ricerca di un linguaggio di alto livello, che fosse abbastanza portabile e adeguato per implementare un nuovo Zork, ma non ne trovarono. Il BASIC era... beh, era il BASIC, e non era nemmeno particolarmente uniforme da microcomputer a microcomputer. All’orizzonte c’era una nuova, promettente implementazione di un più portabile Pascal per Apple II, ma non si parlava di nulla di simile per le altre piattaforme.
 
E così, se volevano essere in grado di vendere il proprio gioco a tutto il mercato dei microcomputer, anziché solo a una fetta dello stesso, si sarebbero dovuti inventare un sistema di gestione dei dati che fosse facilmente portabile, che potesse essere fatto funzionare su differenti microcomputer attraverso un interprete appositamente scritto per ogni modello. Ovviamente creare ogni singolo interprete sarebbe stato impegnativo, ma sarebbe comunque stato uno sforzo più modesto e, qualora la Infocom avesse deciso di fare altri giochi dopo Zork, il risparmio di energie sarebbe rapidamente diventato estremamente significativo. Nel giungere a questa conclusione, avevano sostanzialmente seguito una linea di pensiero già abbondantemente battuta da Scott Adams e dalla Automated Simulations.
 
Ma c’era un altro problema ancora: attualmente Zork esisteva solo su MDL, un linguaggio che ovviamente non era implementato sui microcomputer. Se non volevano riscrivere da zero l’intero gioco (del resto l’obbiettivo di tutto questo non era esattamente quello di tirar fuori un prodotto rapidamente e con una certa facilità?), dovevano anche trovare un modo per far girare quel codice sui microcomputer.
 
Quelli che avevano fra le mani erano un bel po’ di problemi. La prossima volta vedremo come li risolsero (in modo assolutamente brillante).

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


Consulta l'indice per leggere gli articoli precedenti

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

 

DunjonQuest
The Digital Antiquarian (traduzione ufficiale italiana)

Non si può enfatizzare abbastanza quanto i war games e i giochi di ruolo da tavolo (e in particolare, ovviamente, Dungeons and Dragons della TSR) abbiano influenzato le prime narrative ludiche su computer. A volte tale influenza è del tutto palese, come nel caso di giochi tipo Eamon che cercavano esplicitamente di trasportare su computer l'esperienza del D&D. Altre volte però tale influenza è meno apparente.

A differenza dei tipici giochi da tavolo, o perfino dei war game, il D&D e i suoi contemporanei non erano commercializzati come prodotti singoli, ma come delle vere e proprie raccolte di esperienze, quasi uno stile di vita. Solo per iniziare a giocare con la punta di diamante, l'Advanced Dungones & Dragons, si dovevano acquistare tre grandi volumi dalla copertina rigida (Monster Manual, Players Handbook, e Dungeon Masters Guide), a cui si aggiunsero presto molti altri volumi, che descrivevano nuovi mostri, nuovi tesori, nuovi dei, nuove classi di personaggio, e nuove regole sempre più complesse per nuotare, per creare oggetti, per muoversi nelle ombre, per rubare, e -ovviamente- per combattere. Ma, soprattutto, c'erano i moduli d'avventura: avventure preconfezionate, vere e proprie narrative ludiche che potevano essere messe in scena utilizzando il sistema di gioco di D&D. Ne uscivano a dozzine, meticolosamente catalogate con un sistema alfanumerico che permetteva ai collezionisti compulsivi di tenerne traccia; una trilogia di moduli dedicati ai giganti fu etichettata da “G1” a “G3”, una serie di moduli creata nel Regno Unito fu etichettata “UK” [che sta per “United Kingdom”; ndAncient]. A parte i vari vantaggi ludici, questo sistema era indubbiamente il sogno di ogni addetto alle vendite. Perché limitarsi a vendere un solo gioco ai tuoi clienti, quando puoi incatenarli a un intero universo in continua espansione di prodotti?

La strategia di marketing della TSR (basata sulla filosofia di “un solo gioco / molti prodotti”) e il suo zelo per la catalogazione possono essere ritrovati anche fra quei primi sviluppatori di giochi per computer che non stavano provando esplicitamente ad adattare le regole del D&D ai loro mondi digitali. Scott Adams, per esempio, numerò tutte le sue avventure, arrivando così a una dozzina di giochi canonici (altre avventure, presumibilmente non scritte di proprio pugno dal maestro, furono invece pubblicate dalla Adventure International come delle specie di opere apocrife ufficiali sotto l'etichetta “OtherVentures”). I giocatori venivano incoraggiati a giocarle in ordine, visto che aumentavano gradualmente di difficoltà; in questo modo il giocatore principiante poteva affilarsi i denti con opere relativamente “forgiving” tipo Adventureland e Pirate Adventure, per poi gettarsi nei giochi successivi assurdamente difficili tipo Ghost Town e Savage Island. La On-Line Systems adottò un modello simile, sottotitolando retroattivamente Mystery House in Hi-Res Adventure #1 dopo aver pubblicato la Hi-Res Adventure #2 (The Wizard and the Princess). Il gioco successivo Mission: Asteroid, apparso all'inizio nel 1981, fu battezzato Hi-Res Adventure #0 (nonostante la cronologia delle uscite) perché era stato pensato come gioco per principianti, con un po' meno assurdità ed enigmi iniqui del solito. A tutti gli effetti queste similitudini con l'approccio del D&D erano qualcosa di più di un semplice fenomeno di marketing. Del resto entrambe le linee di giochi erano basate su motori riutilizzabili. Nello stesso modo in cui un gruppo di giocatori viveva intorno al tavolo molte avventure diverse usando le regole alla base del D&D, così le linee di avventure di Scott Adams o le Hi-Res Adventures erano essenzialmente delle regole base (il motore di gioco) applicate a molte narrative ludiche diverse.

Tuttavia, fra gli sviluppatori che abbiamo esaminato fin qui, quelli che imitavano in modo più palese il modello del D&D erano -logicamente- quelli che provenivano direttamente dalla cultura del D&D: Donald Brown con il sistema di Eamon, e le Automated Simulations, gli sviluppatori della linea DunjonQuest che era iniziata con Temple of Apshai. J.W. Connelley, il principale sviluppatore del motore dell'Automated Simulations, aveva progettato per Temple of Apshai un motore riutilizzabile che leggeva i file di dati che rappresentavano i livelli del dungeon che si esplorava. Proprio come accadde per Scott Adams e per la On-Line Systems, questo approccio da un lato rese il gioco più facile da convertire (e infatti le versioni per tutte le principali macchine del 1979 -TRS-80, Apple II, Commodore PET- furono pubblicate quello stesso anno), e dall'altro lato velocizzò lo sviluppo di nuove iterazioni del medesimo concept. Tali iterazioni furono etichettate come un set unico di esperienze, che prese il nome di DunjonQuest. Il pittoresco appellativo dalla dizione medievale fu probabilmente scelto per evitare conflitti con la litigiosissima TSR, che, oltre alle regole del D&D, stava commercializzando anche un gioco da tavolo chiamato semplicemente Dungeon!

E la Automated Systems non fece certo mancare tali iterazioni! Altri due titoli della collana DunjonQuest apparvero lo stesso anno di Temple of Apshai. Sia Datestones of Ryn che Morloc’s Tower facevano parte di quelle che la Automated Simulations chiamò MicroQuests, nelle quali gli elementi di costruzione del personaggio erano completamente assenti. Al loro posto il giocatore doveva guidare un personaggio pregenerato attraverso un ambiente molto più piccolo. Ci si aspettava che il giocatore affrontasse più volte l'avventura, cercando di conseguire risultati sempre migliori. Nel 1980 la Automated Simulations pubblicò invece il “vero” seguito di Temple of Apshai, Hellfire Warrior, che conteneva i livelli dal quinto all'ottavo del labirinto iniziato col gioco precedente. Sempre quell'anno pubblicarono anche due titoli più modesti, Rescue at Rigel e Star Warrior, le prime e uniche uscite di una nuova serie, StarQuest, che catapultava il sistema DunjonQuest nello spazio.

Almeno secondo una prospettiva moderna, c'è una sorta di dissonanza cognitiva in queste serie, se le esaminiamo nel loro complesso. I manuali spingevano molto sull'aspetto sperimentale di questi giochi, come ben dimostrato da questo estratto del manuale di Hellfire Warrior:

Quali che siano il tuo background e le tue esperienze precedenti, ti invitiamo a proiettare nel “dunjon” non solo il tuo personaggio, ma anche tutto te stesso. Ti invitiamo a perderti nel labirinto. A sentire la polvere sotto i tuoi piedi. Ad ascoltare il suono di passi non umani che si avvicinano o il lamento di un'anima persa. Lascia che l'odore di zolfo assalga le tue narici. Brucia al caldo delle fiamme dell'inferno, e gela sopra un ponte di ghiaccio. Passa le dita in un cumulo di monete d'oro e immergiti in una pozza d'acqua magica.
Entra nel mondo di DunjonQuest.

Nonostante tutto questo, nessuno di questi giochi aveva la benché minima trama. Temple of Apshai e Hellfire Warrior non hanno nemmeno una fine vera e propria, ma solo dei dungeon che si rigenerano all'infinito da esplorare e un personaggio giocante da migliorare in eterno. Mentre le MicroQuests ricompensano i giocatori solo con un insoddisfacente punteggio finale al posto di un epilogo vero e proprio. Sebbene il background narrativo del suo manuale sia ideato con un'attenzione insolita, Datestones of Ryn ha un limite temporale di soli 20 minuti, che gli dà più un feeling da gioco d'azione, giocabile all'infinito e quasi privo di contesto, piuttosto che da gioco di ruolo per computer. Invece il gameplay della serie nel suo complesso, oggi, ci balza all'occhio per le sue similitudini con i roguelike, dei dungeon crawl senza storia (o, almeno, con pochissima storia) attraverso labirinti generati casualmente. Questa però sarebbe una lettura anacronistica: Rogue, il capostipite del genere, in realtà è uscito un anno dopo Temple of Apshai.

Credo che tutte queste stranezze possano essere spiegate se comprendiamo che Jon Freeman, il principale designer dietro il sistema, stava puntando a creare un tipo di narrativa ludica diverso da quella delle avventure testuali di Scott Adams e da quella tipica della On-Line Systems. Lui sperava che, dati un background, una descrizione degli ambienti, un set di regole per controllare ciò che vi accadeva, e una buona dosa di immaginazione da parte del giocatore, dal gioco emergesse autonomamente una narrativa ludica. In altre parole, usando un termine che appartiene ad un'era molto successiva, stava tentando di creare una narrativa emergente. Per comprendere meglio il suo approccio, ho pensato di dare una breve occhiata da vicino a uno dei suoi giochi, Rescue at Rigel

Rescue at Rigel trae ispirazione dalla classica space opera, un genere che è stato recentemente riportato in vita dal fenomenale successo dei primi due film di Star Wars [l'articolo è stato scritto nel 2011, quindi l'autore si riferisce alla seconda trilogia di Guerre Stellari; ndAncient].

Nell'arena della vostra immaginazione, non tutti i nostri eroi (o le nostre eroine!) indossano armature nere o di uno scintillante argento, né prendono a mazzate dei barbari nemici su dei moli sferzati dal vento, né affrontano dei macabri destini per mano di depravati adepti le cui arti nere erano già vecchie quando il mondo era giovane. La fantascienza ci fa viaggiare su navi stellari con nomi come Enterprise, Hooligan, Little Giant, Millenium Falcon, Nemesis, Nostromo, Sisu, Skylark, e Solar Queen. Navi che viaggiano su mari stellati, che non sono percorsi da tempeste o infestati da demoni, ma che non per questo sono meno spaventosi. Navi che ci fanno approdare su nuovi mondi impavidi le cui forme, i cui panorami e i cui suoni sono più plausibili (ma non meno sbalorditivi) di quelli sperimentati da Sinbad.

In questo titolo il giocatore assume il ruolo di Sudden Smith, un classico ed energico eroe pulp. Sta per teletrasportarsi nella base di una razza di alieni insettoidi conosciuti col nome di Tollah, che hanno catturato un gruppo di scienziati per le loro “ricerche” e fra questi c'è anche la fidanzata di Sudden. I Tollah sono uno dei pochissimi accenni ad eventi di un mondo più ampio che troverete nei primissimi videogiochi, al di là delle opere di fantasy e science-fiction. La casta che comanda i Tollah sono gli “High Tollah”, un chiaro riferimento allo Ayatollah Khomeyni, che a quel tempo aveva recentemente preso il potere in Iran e che teneva in ostaggio 52 Americani [“High Tollah”, cioé “Alto Tollah”, si pronuncia infatti in modo molto simile a Ayatollah; ndAncient]. Gli “High Tollah” ci dice il manuale, “sono altezzosi, autoritari, intolleranti, ottusi, privi di immaginazione e inflessibili.” Alla luce di tutto questo, è palese quale sia stata l'ispirazione per questo scenario di salvataggio degli scienziati.

Il gameplay si sviluppa intorno all'esplorazione della base dei Tollah, convenientemente strutturata come un labirinto, respingendo i Tollah e i robot della sicurezza, mentre cerchiamo i dieci scienziati che vi sono tenuti in ostaggio. Si tratta sostanzialmente, come in tanti altri giochi di ruolo per computer, di un gioco di gestione delle risorse: Sudden ha un numero limitato di medikit, di munizioni, e soprattutto una riserva limitata di energia all'interno del suo zaino che deve essere usata per tutto (dallo sparare agli Tollah, fino al teletrasportare gli scienziati al sicuro). Quel che è peggio è che Sudden ha soltanto 60 minuti di tempo reale per salvare il maggior numero possibile di scienziati e teletrasportarsi al sicuro. Freeman fa di tutto per rendere il gioco un motore di eccitante narrativa emergente. Ad esempio, se Sudden finisce completamente l'energia, ha comunque un'ultima possibile via di fuga: se riesce a tornare nei 60 minuti al punto in cui lo ha depositato il teletrasporto, un altro teletrasporto automatico lo riporterà in salvo. È facile immaginarsi una situazione disperata, che pare uscita direttamente da una storia di Guerre Stellari o di Dominic Flandry, con il giocatore che torna sui suoi passi, in mezzo al fuoco dei laser, mentre il tempo scorre e i Tollah gli sono alle calcagna. Di certo ci possiamo immaginare che Freeman si fosse immaginato tutto questo.

Ma per vivere queste storie è necessaria una notevole dedizione e una fervida immaginazione da parte del giocatore, come potrà probabilmente convenire chiunque abbia osservato l'orrendo screenshot di cui sopra. Effettivamente i giochi della serie DunjonQuest sembrano proprio una sorta di ibrido fra l'esperienza di un gdr da tavolo e di uno digitale, in cui ciò che emerge direttamente dall'immaginazione del giocatore è importante quanto quello offerto dal gioco stesso. È per questo che probabilmente è stata una mossa saggia per la Automated Simulations quella di usare come target del marketing di DunjonQuest proprio i giocatori di ruolo cartaceo. Del resto loro sono abituati a rimboccarsi le maniche e a usare la loro immaginazione per inventare delle narrative soddisfacenti. La Automated Simulations pubblicizzò ampiamente DunjonQuest sulla rivista Dragon Magazine della TSR, e (con una mossa che non potrebbe essere più indicativa della tipologia di pubblico che pensavano potesse apprezzare DunjonQuest) arrivarono persino a regalare il gioco da tavolo strategico chiamato Sticks and Stones con ogni acquisto di un gioco della serie DunjonQuest.

Negli ultimi mesi del 1980 la Automated Simulations cambiò il suo nome nel meno prosaico Epyx, adottando il motto: “Computer games thinkers play” [traducibile all'incirca come “Videogiochi a cui giocano le persone che pensano”; ndAncient]. I giochi della serie DunjonQuest continuarono comunque a uscire per altri due anni. Fra le ultime pubblicazioni ci furono anche un paio di espansioni per Temple of Apshai e Hellfire Warrior, che credo siano i primi esempi del genere tra i giochi commerciali per computer. Invece l'utilizzo più strano e creativo dell'engine di DunjonQuest arrivò nel 1981 con Crush, Crumble, and Chomp!: The Great Movie Monster Game, nel quale il giocatore assumeva il controllo di Godzilla (anzi, no, di Goshzilla!), o di qualche altro mostro famoso lanciato nella distruzione di una città. Per un esame dettagliato di tutta la serie di DunjonQuest, che alla fine si compose di una dozzina di titoli, potete leggere questo articolo di Hardcore Gaming 101.

Crush, Crumble, and Chomp! fu l'ultimo lavoro di Freeman per la Epyx. Alla West Coast Computer Faire of 1980 incontrò infatti una collega programmatrice chiamata Anne Westfall e di lì a poco i due iniziarono a frequentarsi. Westfall si unì alla Epyx per un po', andando a lavorare come programmatrice su alcuni degli ultimi giochi di DunjonQuest. Lei e Freeman però ben presto si stufarono del disinteresse di Connelley nel miglioramento dell'engine di DunjonQuest. Scritto in BASIC sull'ormai vetusto TRS-80 Model I, tale engine era sempre stato tremendamente lento e ormai iniziava a sembrare davvero datato nei porting per le piattaforme più moderne e capaci. In più Freeman, un designer irrequieto e creativo, si stava annoiando delle continue iterazioni del solito concept di DunjonQuest; perfino creare Crush, Crumble, and Chomp! aveva richiesto una dura battaglia da parte sua... Alla fine del 1981 Freeman e Westfall lasciarono la Epyx per creare una casa di sviluppo indipendente, la Free Fall Associates, della quale avrò molto altro da dire in futuro. E, dopo un paio di ultime pubblicazioni per DunjonQuest, la Epyx si trasformò da “Computer games thinkers play” in qualcosa di molto diverso, e anche di questo avrò molto da dire in futuro. Con incassi buoni, ma mai enormi, neppure al massimo del proprio splendore, i giochi della serie DunjonQuest sfiguravano abbastanza nel confronto con la nuova generazione di giochi di ruolo per computer, dei quali -come avrete immaginato- avrò molto altro da dire in futuro.

Se volete sperimentare l'esperienza di DunjonQuest, posso fornirvi un pacchetto con un immagine per Apple II che include Temple of Apshai, Rescue at Rigel, Morloc’s Tower, e Datestones of Ryn, oltre ai relativi manuali.

La prossima volta inizieremo a esplorare un'opera con una profondità tematica senza precedenti, che fa già drizzare tutte le mie antenne di studioso di letteratura.

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!

Un Viaggio nel Fantastico Mondo di Eamon
The Digital Antiquarian (traduzione ufficiale italiana)

 
Vi va di unirvi a me in una vera avventura di Eamon per vedere come funzionava davvero? Sì? Non ne avevo dubbi!
Eamon è una raccolta di programmi, scritti in BASIC e legati assieme da un nastro adesivo virtuale. Un'idea ingegnosa considerate le limitazioni tipiche del BASIC per un computer a 8 bit, ma al tempo stesso anche mostruosa se la guardiamo alla luce delle moderne pratiche di buona programmazione. La sua struttura fra l'altro ci ricorda un altro dei primi GdR scritti in BASIC, che abbiamo già esaminato tempo fa: Temple of Apshai.
 
Tutte le utility contenute nel dischetto principale di Eamon godono di una cornice narrativa che maschera le loro funzionalità molto concrete. All'avvio la prima scena che ci dà il benvenuto è quella di una “sala dell'amministrazione” (ebbene sì, la burocrazia se la passa bene anche nei regni fantasy...).
 
 
Ti trovi nelle stanze esterne del salone della Gilda dei Liberi Avventurieri. Molti uomini e donne stanno tracannando birra, ridendo, e cantando a voce alta.
Sul lato nord della stanza c'è un bugigattolo con una scrivania. Sulla scrivania c'è un cartello che dice: 'Registratevi qui o sarà peggio per voi'.
Ti avvicini alla scrivania o ti unisci agli altri uomini che bevano birra?
 
Se scegliete di non andare alla scrivania come vi è stato suggerito di fare, i risultati sono piuttosto miseri... Ecco qui il primo assaggio dello sconcertante piacere che Donald Brown prova nell'uccidere i propri giocatori nei modi più arbitrari. Non oso immaginare che razza di Dungeon Master poteva essere...
 
 
Mentre fai per avvicinarti agli altri uomini, senti una spada che ti trafigge la schiena e odi qualcuno dire: 'Devi imparare a seguire le istruzioni!'
 
Tutti i nostri personaggi ancora in vita sono contenuti in un file di dati all'interno della “master list”. Se decidiamo di seguire le istruzioni, possiamo sceglierne uno dalla sala della gilda semplicemente digitandone il nome.
 
 
Vieni accolto da un robusto irlandese che ti guarda di traverso e ti chiede: 'Come ti chiami?'
 
Se inseriamo un nome non presente fra i nostri avventurieri in vita, ci viene offerta la possibilità di creare un nuovo personaggio. Viene così caricato un secondo programma scritto in BASIC (“New Adventurer” [“Nuovo Avventuriero”]) e possiamo proseguire.
 
 
Dopo un po' ti guarda e dice: 'Qui non c'è il tuo nome. Me lo hai già dato?'
Come rispondi? SI'
Si batte il palmo di mano sulla fronte e dice: 'Ah, devi essere nuovo! Dammi solo un minuto e farò venire qualcuno a occuparsi di te.'
 
Per quanto la discendenza di Eamon da Dungeons and Dragons sia assolutamente palese, le sue regole non sono una semplice riproduzione di quel sistema, non fosse altro perché la dura realtà di un computer con 48 k rendeva assolutamente necessaria una pesante semplificazione delle stesse. Nel nostro caso tutte le complessità dei personaggi di D&D sono state ridotte a tre soli punteggi di caratteristiche generati casualmente: resistenza, agilità, e carisma.
 
 
L'irlandese ti dice: 'Per prima cosa devo sapere se sei maschio o femmina.'
MASCHIO
L'irlandese si allontana e arriva un uomo alto, probabilmente di discendenza elfica.Ti studia per un momento e dice: 'Ecco qua un libretto con le istruzioni che devi leggere, e poi le tue caratteristiche primarie, che sono:
 Resistenza – 22
 Agilità – 20
 Carisma – 29 
 
Il sistema non consente al giocatore nessun ruolo nella creazione del personaggio, se non la scelta del nome e del sesso. Tre “tiri di dado” sfortunati possono consegnarci un personaggio ingiocabile, ma anche un tiro fortunato o due al posto sbagliato possono consegnarcene uno che non siamo interessati a giocare. 
Dei problemi simili nella creazione dei personaggi nel D&D pen and paper portarono rapidamente all'introduzione di regole ad hoc fatte in casa (che in seguito furono adottate anche ufficialmente), con l'obbiettivo di mitigare gli effetti della fortuna e di dare al giocatore maggiori opportunità di scelta in questo passaggio cruciale, che è destinato a incidere sull'esperienza di gioco per giorni, settimane, o addirittura per mesi di gioco futuro. In modo del tutto analogo, se non perfino più semplice, uno dei primi programmi aggiuntivi più comuni di Eamon fu l'utility “suicidio”: dal nome un po' morboso ma dalla grande utilità, essa permetteva al giocatore di sbarazzarsi dei personaggi deboli, o altrimenti inaccettabili, e di provare a crearne di nuovi da capo.
Che si crei un nuovo personaggio o che si giochi con uno che già esiste, il nostro personaggio viene tolto dal file che contiene tutti i personaggi esistenti e viene collocato in un file che contiene solo il personaggio attualmente attivo (“The Adventurer”). Dopo l'immancabile citazione nerd di Star Trek, si avvia un terzo programma scritto in BASIC, “Main Hall”. Questo legge in “The Adventurer” (e infatti ognuno di questi passaggi lascia un file di dati in giro, essendo questo all'epoca l'unico modo pratico per far sì che tutti questi programmi potessero interloquire fra loro) e noi ci ritroviamo nel programma principale di Eamon, ancora una volta mascherato dietro una propria componente narrativa.
 
 
L'uomo dietro il bancone si riprende le istruzioni e dice: 'È ora che la tua vita abbia inizio'. Fa uno strano gesto con la mano e dice: 'Lunga vita e prosperità'.
Ti avventuri nella sala principale.
Mentre cammini per la sala, capisci di poter fare sei cose:
1) Imbarcarti in un'avventura
2) Visitare il negozio di armi, per comprare armi e/o armature
3) Pagare uno stregone che ti insegni degli incantesimi
4) Cercare il banchiere per depositare o ritirare dell'oro
5) Esaminare le tue caratteristiche
6) Abbandonare temporaneamente questo universo.
 
A differenza di Temple of Apshai, Eamon ha un sistema rudimentale di magia basato su quattro incantesimi: esplosione, guarigione, velocità, e potere. I primi tre funzionano esattamente come ci si aspetterebbe; l'ultimo invece è un'interessante scappatoia, pensata per fare ciò che il designer di ogni avventura vuole che faccia.
La “Main Hall” inoltre ha un personaggio particolarmente infelice, Shylock il banchiere.
 
 
 
Non hai difficoltà a individuare Shylock McFenney, il banchiere del luogo, grazie al suo pancione.
Attiri la sua attenzione e lui si avvicina e ti dice: 'Beh, Jimmy, ragazzo mio, che piacere vederti! Vuoi fare un deposito o vuoi ritirare dei soldi?'
DEPOSITO
Shylock fa un gran sorriso e dice: 'Ben per te! Quanto vuoi depositare?'
20
Shylock prende i tuoi soldi, li mette nella sua sacca, ne ascolta il tintinnio, poi ti ringrazia, e se ne va.
 
Qui mi sento di poter chiudere un occhio a favore di Brown, perché dubito che sapesse che sorta di bagaglio storico e culturale il suo Shylock si stesse trascinando dietro... E poi, se proprio avesse voluto ispirarsi all'antisemitismo di qualcuno, è facile immaginare molte persone peggiori di Shakespeare a cui attingere...
In ogni caso, scegliamo l'opzione 1 e gettiamoci nell'avventura.
 
 
Inserisci il dischetto con l'avventura (o lascia questo dischetto per la 'Beginners Cave') nel lettore e poi premi 'C'
 
Anche noi, come ogni aspirante giocatore di Eamon da tempo immemore, inizieremo la nostra esperienza con l'avventura inclusa nel dischetto principale, la “Beginners Cave” di Brown.
 
Come ci si può ben immaginare, questa è la parte più complessa di Eamon. 
Proprio prima che la “Main Hall” ci richieda di inserire il dischetto con lo scenario da giocare, il gioco cancella completamente il personaggio dal dischetto principale. Quando il giocatore inserisce il disco con lo scenario, il suo attuale personaggio viene registrato in un file ottimisticamente chiamato “Fresh Meat” [“carne fresca”]. A questo punto il programma cerca un altro file sul dischetto dello scenario, “Eamon.name”, che contiene il nome di un altro programma BASIC da lanciare, il quale a sua volta contiene l'avventura vera e propria. Brown e i successivi curatori di Eamon fornivano un framework iniziale per questo programma, che a tutti gli effetti può essere considerato il primo engine riutilizzabile per avventure che sia mai stato ideato con tale preciso scopo e che sia mai stato reso disponibile al pubblico.  Di base esso consente al giocatore di spostarsi per una rete di stanze (i cui contenuti e le cui connessioni sono contenute nel file “Eamon.rooms”, i cui nomi sono contenuti in “Eamon.room names”, e le cui descrizioni sono contenute in “Eamon.descriptions”); di combattere dei mostri (i cui attributi sono in “Eamon.monsters”); e di raccogliere oggetti (descritti in  “Eamon.artifacts”). Questi ultimi sono utili sia come tesori (buoni per essere rivenduti in cambio di oro nella main hall), che come armi (buone per uccidere i mostri nei vari scenari così come per essere scambiate con dell'oro nella main hall). Brown forniva anche delle utility per riempire di dati questi file, ma utilizzando unicamente queste si sarebbe potuto creare solo delle avventure molto basiche (oltre che scritte in BASIC...). Per introdurre delle interazioni più complesse (come -per citare un esempio preso dalla documentazione fornita da Brown- una spada che casualmente teletrasporta chi la usa in una stanza a caso) il programmatore deve modificare direttamente il codice BASIC del framework iniziale. Così facendo si ha a disposizione un numero infinito di possibilità, anche se ottenibili solo in questo modo poco elegante. Brown si immaginava scenari molto diversi fra loro, come un'avventura di Eamon in cui il giocatore “guida un esercito in battaglia, con il morale dei soldati influenzato direttamente dal suo punteggio di carisma!”
 
Oggi però affronteremo un'avventura di Eamon piuttosto semplice.
 
 
Non hai difficoltà a trovare un cavallo da... ehm... prendere in presto, per raggiungere la tua prima avventura. Segui diversi cartelli per giungere alla grotta del principiante.
Sei davanti all'ingresso della grotta. A sud, sopra il cunicolo d'ingresso, un cartello dice: 'Solo Principianti'. La strada a nord riporta alla città.
Mentre sei lì davanti, vedi uscire il “Knight Marshal” per ispezionarti.
Alla fine il “Knight Marshal” dice 'Puoi procedere' e si allontana.
 
Nel mio primo post su Eamon l'ho definito un GdR per computer mascherato da avventura testuale. Quest'impressione si fa ancora più netta se digitiamo qualcosa non compreso dal semplice parser a due parole del gioco (cosa assai facile da fare...). In questo caso il gioco ci restituisce un elenco dei comandi disponibili.
 
 
Un tale elenco è qualcosa che non si vede spesso nelle avventure testuali più tradizionali e ci dice molto su quale fosse il vero focus di Brown: per lui il parser era solo una modalità per inserire i comandi nel suo programma, più efficiente di un menù alla luce della memoria limitata e dello spazio ristretto sul monitor di cui poteva disporre.
A questo punto possiamo fare un parallelismo con i giochi di “narrativa interattiva” di Robert Lafore, che, come abbiamo visto, sono dei giochi narrativi basati su scelte predeterminate (sullo stile dei Librigame) e mascherati da avventure testuali. Il focus del primo Eamon è tutto sul character building e sull'uccisione dei mostri, e non sulla risoluzione di enigmi. Quindi la sua somiglianza con Adventure e con gli sforzi di Scott Adams è più una casualità della storia che il frutto di un intento simile. Questo però significa che le problematiche legate alla necessità di azzeccare i verbi giusti, nonché le altre frustrazioni tipiche dei classici parser old-school, sono in gran parte assenti in Eamon. Ma dall'altro lato è anche vero che la maggior parte dei tentativi di fare qualcosa di diverso dallo spostarsi e dall'attaccare dà generalmente scarsi risultati.
 
 
Qui c'è l'eremita.
Un guerriero umano si erge davanti a te, armato di spada lunga e scudo. Sul suo scudo c'è un adesivo con scritto: 'Ciao! Sono Heinrich!'
DICI CIAO
Okay, 'Ciao'
L'eremita attacca Heinrich
 -- Manca.
Heinrich attacca Jimmy
 -- Manca.
 
È proprio quando la “Beginners Cave” si fa un po' più ambiziosa, che i risultati ci fanno desiderare che non lo avesse fatto... A un certo punto ci si imbatte in un libro luminescente e sinistro. Se ciò avvenisse in una seduta dal vivo di D&D (o anche di un moderno GdR su computer), avremmo a disposizione tutta una serie di strumenti per indagarlo meglio: potremmo lanciare incantesimi di “individuazione del magico” o di “individuazione del male”, potremmo portarlo da un amico mago di alto livello, ecc. Qui invece abbiamo solo due opzioni: o leggerlo temerariamente, oppure lasciarlo stare (restando per sempre col dubbio di che cosa fosse). Se decidiamo di leggerlo, succede rapidamente il peggio:
 
 
Appena leggi il libro, avverti una strana sensazione che ti sopraffà. Comprendi di colpo che ti stai trasformando in un piccolo pesce.
Sbatti la coda tre volte e poi muori.
 
Ecco qua un altro esempio di come la narrativa ludica degli albori produca le peggiori iniquità contro il giocatore, quando sceglie di indulgere in possibilità narrative (del resto oggetti magici del genere sono spesso la base delle avventure di D&D) che semplicemente la sottostante tecnologia non poteva ancora supportare.
A ulteriore conferma di quanto stiamo dicendo, per uscire vincitori dalla “Beginners Cave” dobbiamo scoprire un passaggio segreto digitando ESAMINA esattamente nel posto giusto.
 
 
ESAMINA
Sei in un cunicolo che va a nord e a sud. I lati del cunicolo sono frastagliati e irregolari. Da sud proviene la luce di una torcia.
Hai trovato un cunicolo nascosto che si dirama a est!
 
Quando lo si fa, si scopre un tempio segreto e scopriamo che apparentemente la nostra missione (a cui mai si era accennato prima d'ora) è sempre stata quella di salvare “la figlia non troppo sveglia del Duca Luxom”. Ah, beh, che missione sarebbe mai stata senza una principessa (o... com'è che si chiama una duchessa prima di diventare una duchessa?) da salvare?
 
 
 
Ti trovi nel tempio. Le pareti sono coperte da immagini di azioni eroiche. Qui ci sono due altari, uno coperto con una pittura dorata e l'altro macchiato di sangue. L'unica uscita conduce a ovest.
Qui c'è l'eremita.
C'è un uomo enorme in abbigliamento religioso e uno sguardo pazzo negli occhi. Nella mano destra stringe una mazza.
Vedi una bella ragazza in un fluente abito bianco. La riconosci come Cynthia, la figlia non troppo sveglia del Duca Luxom.
Qui ci sono numerose spezie rare.
 
Mentre consegni i tuoi tesori a Sam Slicker, colui che nella zona acquista questo genere di cose, lui esamina ciò che gli hai portato e ti paga 5.125 monete d'oro.
In più ricevi una ricompensa di 290 monete d'oro per aver riportato Cynthia sana e salva.
 
Se sopravviviamo fino all'uscita, il nostro personaggio viene copiato di nuovo sul disco principale, insieme a ogni miglioramento delle caratteristiche conseguito, all'esperienza accumulata e a qualunque tesoro abbia trovato. Se invece non sopravvive, il personaggio è perso per sempre – come ricorderete infatti era stato cancellato dal dischetto principale prima dell'inizio dell'avventura.  
Di recente ho giocato anche ad alcune altre delle prime avventure di Eamon: “The Zephyr Riverventure” (Adventure #4), scritta da un dipendente del Computer Emporium, Jim Jacobson; e “The Death Star” (Adventure #6), anche questa scritta da Brown in persona. Entrambe sono molto più grandi della “Beginners Cave”, ma  presentano un miscuglio simile di mappatura, di combattimento, e di sporadiche morti improvvise per tenere il giocatore sempre sulle spine. “Riverventure” invece sembra ispirata a un film dell'epoca, Apocalypse Now.
 
 
Il tuo prossimo compito è grande. Un famoso scienziato (il Prof. Axom) è stato rapito 3 mesi fa. La Società per la Preservazione degli Scienziati (SoPrSc) ha offerto una ricompensa per il salvataggio del Professor Axom (che oltretutto è anche un tuo amico).
Si vocifera che l'infame Guerriero Nero (che vive da qualche parte lungo il Fiume Zyphur) sia responsabile del rapimento. Devi seguire il fiume, trovare il professore, e riportarlo indietro... vivo!
Ora andrai sul molo, dove inizierà la tua avventura.
 
“The Death Star” invece è basata sullo stesso secondo capitolo di Star Wars che ha ispirato Dog Star Adventure, ed è interessante perché è la prima avventura di Eamon a spingere il sistema in un'ambientazione completamente diversa.
 
 
 
Appena abbandoni la Main Hall, avverti improvvisamente un insolito dolore allo stomaco, come se ti avessero rivoltato da capo ai piedi. Quando riacquisti consapevolezza, ti trovi al timone di una nave spaziale! Capisci di aver attraversato un varco fra le realtà!
 
Cercando nuovi 'ricordi', comprendi la tua situazione, che è tutt'altro che buona!
Sei a bordo del Millenium Falcon, che è stato appena trascinato nella malvagia macchina di distruzione dell'Impero, la Morte Nera! Per scappare dovrai trovare e distruggere l'equipaggiamento nella sezione del macchinario del raggio traente o nella stanza dei motori.
Sei equipaggiato con una spada laser.
 
Ciò che mi interessa di più, almeno per ora, è capire quale sia il posto di Eamon nella storia degli albori della narrativa ludica su computer; da qui tutta l'attenzione che ho dedicato a queste primissime incarnazioni del suo sistema. È però doveroso segnalare che il livello di sofisticatezza di molte delle successive avventure di Eamon è assai più alto di questi primi tentativi. È per questo che ciò che sto per dire non deve essere preso come un giudizio definitivo sul sistema.
 
Detto questo, ci sono alcuni aspetti problematici in Eamon che mi sembrano endemici al sistema, anche lasciando da parte la centralità occupata dal sistema casuale di combattimento (che solitamente si riduce all'osservare il lancio di dadi virtuali sperando per il meglio). Nel consentire ai giocatori di far vivere tutta una serie di avventure ai loro personaggi, Brown sperava chiaramente di duplicare il feeling di una tipica campagna di D&D, nella quale i giocatori rivestano il ruolo dei propri personaggi attraverso un'intera serie di gesta eroiche, accrescendo al contempo il proprio potere, finché non sopravviene la morte o il pensionamento. Tuttavia in Eamon la morte è fin troppo casuale e arriva al minimo capriccio del designer. I pericoli del combattimento sono probabilmente meno problematici, anche se le avventure di Eamon presentavano un bilanciamento solo molto approssimativo della difficoltà, probabilmente perché in assenza di precisi livelli di avanzamento dei  personaggi era molto difficile poter predisporre un sistema in grado di scalare in modo coerente la difficoltà. Non ci meravigliamo quindi se i programmi per “barare” (che consentivano di salvare i personaggi o di resuscitarli) furono rapidamente inclusi direttamente sul dischetto principale del gioco. Tali programmi possono alleggerire di molto le tribolazioni del giocatore, ma in un certo senso si pongono anche un po' in antitesi con l'idea che sta al centro di Eamon.
 
Intendo finire questa serie andando quanto prima ad analizzare la storia di Eamon dopo Brown. Se volete provarlo in prima persona, il sito Eamon Adventurer’s Guild è  sicuramente il posto migliore da cui iniziare. Oltre alle immagini dei dischetti di tutte le avventure di Eamon (che possono essere lanciate con un emulatore per Apple II), è possibile avere un'idea del gioco anche tramite una applet Java online. È possibile giocare in questo modo al dischetto principale e alla “Beginners Cave”, a “The Zephyr Riverventure” [Link non disponibile, NdEditor] e a “Death Star” [Link non disponibile, NdEditor], oltre a centinaia di altre avventure.
 
NOTA DI THE ANCIENT ONE:Da Dicembre 2017, grazie al lavoro di Keith Dechant, è possibile giocare a Eamon direttamente da web senza bisogno di emulatori. Il sistema sembra funzionare bene e, sebbene non ci siano ancora tutte le avventure create per il gioco originale, molte sono già in corso di inserimento. Potete provarlo cliccando qui.Segnalo per finire anche un simpatico porting per iOS, per chi volesse giocarci in mobilità

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



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

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

 
Oggigiorno i videogiochi possono essere tutti categorizzati in una manciata, ormai relativamente stabile, di generi: sparatutto in prima persona, giochi di strategia in tempo reale, avventure punta-e-clicca, action RPG, avventure testuali, ecc. Sporadicamente appare un gioco completamente originale che riesce a creare un nuovo genere (come è successo con "Diner Dash" e il genere dei giochi di “time-management” a metà degli anni 2000), ma subito gli fanno seguito varianti, perfezionamenti, e cloni... e gradualmente lo scenario si stabilizza di nuovo. Una delle cose che rende così interessante studiare gli albori dei videogiochi è che i generi esistevano solo in senso molto lato; le cose si inventavano mentre le si creava, con conseguenti sovrapposizioni di gameplay, che oggi possono apparire strane agli occhi del giocatore odierno. Eppure, a volte, questi esperimenti possono sorprenderci per quanto funzionano bene, spingendoci a chiederci se i game designer di oggi (legati come sono ai generi) non abbiano perso per strada una certa preziosa libertà.
Un perfetto esempio di quello che sto dicendo è Eamon, che utilizza le meccaniche delle interfacce delle avventure testuali, sostituendo in larga misura la risoluzione di enigmi con il combattimento, e introducendo un'idea mutuata da Dungeons & Dragons, e cioè quella di una campagna estesa nel quale il giocatore guida un singolo personaggio, in costante evoluzione, attraverso una serie di avventure singole.
Essendo in continuo sviluppo da oltre venti anni, ed essendo un sistema che ancora oggi vede qualche sprazzo di sporadica attività, Eamon è uno dei titoli più insoliti e a suo modo affascinanti della storia dei videogiochi. Per essere sopravvissuto così a lungo, la storia delle sue origini è sorprendentemente oscura, in parte perché l'uomo che l'ha creato, Donald Brown, per ragioni personali si è rifiutato di parlarne per quasi trent'anni. Nel preparare questo post ho rispettato la sua scelta, più volte ribadita, di essere lasciato in pace, ma ho comunque contattato un'altra persona che è stata coinvolta fin dall'inizio e che ha giocato un ruolo fondamentale nell'evoluzione di Eamon,  John Nelson, il quale si è sobbarcato il lavoro di sviluppo del sistema dopo Brown e ha fondato il  National Eamon User’s Club. Grazie a Nelson, e alla mia solita abitudine di disseppellire ogni singolo documento storico che riesco a trovare, sono riuscito a diradare almeno in parte la nebbia intorno a questo titolo. 
Ma prima di entrare nei dettagli, voglio spiegarvi cosa fosse Eamon e come funzionava. Anche se ci sono stati alcuni tentativi di portarlo su altre macchine [di cui uno recente, e decisamente interessante, che permette di giocarlo da browser; ndAncient], la sua incarnazione di gran lunga più famosa è quella per il computer per il quale Brown lo creò: l'Apple II. Il cuore del sistema era il “Master Diskette”, che conteneva una utility di creazione del personaggio, un negozio di armi, armature, e incantesimi, una banca in cui depositare l'oro fra le avventure, e la prima semplice avventura (la “Beginner’s Cave”). Questo “Master Diskette” era però il punto di lancio per molte altre avventure, che mentre sto scrivendo [2011; ndAncient] sono oltre 250. E, anche se molte di queste hanno tante delle caratteristiche delle tipiche avventure testuali, ci sono due grosse differenze che le separano dai giochi sulla scia di Scott Adams: la prima è che il giocatore può importare il suo personaggio con cui giocarle, utilizzando il suo equipaggiamento e i suoi punteggi di abilità; la seconda è che in esse gli enigmi predeterminati sono in gran parte sostituiti dai dilemmi tattici dei combattimenti simulati. In altre parole, nella mia linea “simulazioni vs design predeterminato” le avventure di Eamon ricadano molto più a sinistra perfino delle avventure testuali old-school, e quindi molto vicine al punto occupato dai GdR old-school.
 
Per il giocatore moderno infatti le avventure di Eamon sono sostanzialmente dei GdR per computer camuffati da avventure testuali. Ed effettivamente Eamon è segnato dall'influenza di D&D un po' ovunque. L'idea di una “campagna” di lungo termine con un personaggio in costante evoluzione viene chiaramente da lì, così come l'attenzione posta sul combattimento piuttosto che sulle sfide cerebrali. Da questo punto di vista, e da altri ancora, assomiglia moltissimo alla serie Dunjonquest delle Automated Simulations, di cui  Temple of Apshai era il primo capitolo (e del resto il sistema di Dunjonquest veniva appunto pubblicizzato come un sistema di regole per il quale il giocatore avrebbe comprato degli scenari da giocare, proprio come era solito fare con i moduli d'avventura per la sua campagna “pen & paper” di D&D). Brown è chiaramente più interessato a ricreare al computer l'esperienza di una campagna di D&D, piuttosto che a cimentarsi con una narrazione auto-sufficiente (che poi nel tempo sarebbe diventata la moderna interactive fiction). E, proprio da questo punto di vista, ci appare come un affascinante esempio di strada non intrapresa (almeno fino a poco tempo fa: S. John Ross e Victor Gijsbers hanno nuovamente fatto degli esperimenti con il combattimento tattico nell'IF, con dei risultati che potrebbero stupirvi. Non a caso entrambi sono giunti all'IF dal mondo dei GdR “pen & paper”) [vale la pena notare che dal 2011 ci sono stati anche altri esperimenti interessanti in questo senso, l'ultimo dei quali è La Stirpe di Soulcanto del nostro Flay4Fight; ndAncient].
 
Tuttavia Eamon rappresenta al tempo stesso anche l'origine di una strada che invece è stata imboccata con decisione e che ci conduce dritto fino ai giorni nostri. È infatti il primo sistema pensato specificatamente per la creazione di avventure testuali. Tutti quelli che (per parafrasare Robert Wyatt) non riuscivano a comprendere perché ci si dovesse limitare a giocarle invece di crearle in prima persona, ora avevano uno strumento per farlo. Può sembrare strano dipingere Eamon come il progenitore di Inform 7 e di TADS 3, ma è esattamente questo. Anzi, a ben vedere, è stato proprio il primo programma per la creazione di giochi di qualunque tipo a venir distribuito al pubblico.
 
Brown, all'epoca in cui creò Eamon, era uno studente della Drake University di Des Moines. E mentre un paio di foto degli annuari scolastici lo ritraggono mentre fa capolino dalla fila di dietro delle foto di gruppo del suo dormitorio, ci appare un po' come un pesce fuori d'acqua in mezzo a un gruppo di ragazzi festaioli. Nessuna menzione speciale lo contraddistingue nei due annuari e non si è nemmeno scomodato a posare per la foto individuale. Non è chiaro se si sia mai laureato. È chiaro però che gli interessi di Brown erano altrove; in due altri posti, per la precisione. 
Suo padre aveva acquistato un Apple II molto presto. Brown ne fu istantaneamente catturato, dedicando moltissime ore a esplorare le possibilità che quella piccola macchina offriva. Poco dopo un tizio chiamato Richard Skeie aprì un negozio a Des Moines chiamato Computer Emporium. Esso si spingeva oltre la semplice vendita di hardware e software, ospitando un club di computer che si ritrovava molto frequentemente proprio nei locali del negozio, diventando un punto di ritrovo per i primi appassionati di microcomputer di Des Moines (e in particolare per gli appassionati dell'Apple II). Brown ben presto iniziò a passarci un sacco di tempo, discutendo progetti e possibilità, scambiando software, e socializzando con altre persone che come lui erano smanettoni appassionati di tecnologia.
L'altra influenza che contribuì alla nascita di Eamon viene dalla cultura dei wargame e dei GdR da tavolo, che negli Stati Uniti d'America medio-occidentali era particolarmente forte. Tramite un vecchio amico di nome  Bill Fesselmeyer, Brown si immerse completamente in Dungeons and Dragons. Ma Fesselmeyer (e di lì a poco anche Brown) spinsero le loro fantasie medievali oltre il gioco, attraverso la Society for Creative Anachronism.
 
Nata alla Berkeley University nel 1966 come una “protesta spontanea contro il ventesimo secolo”, La SCA era un club altamente strutturato (o, direbbero alcuni, uno stile di vita) dedito a far rivivere il medioevo. Ancora viva e vegeta, nelle sue fila annoverava autori fantasy come  Diana Paxson (che potrebbe anche essere considerata una specie di fondatrice della SCA) e Marion Zimmer Bradley. Dal sito web del club:
 
La Society for Creative Anachronism, o SCA, è un'organizzazione internazionale dedita a ricercare e a ricreare le arti, i mestieri, e le tradizioni dell'Europa pre-17esimo secolo.

I membri della SCA studiano e prendono parte a varie attività, fra cui: combattimento, tiro con l'arco, attività equestri, sfilate in costume, cucina, lavorazione dei metalli, lavorazione del legno, musica, danza, calligrafia, tessitura, e molto altro ancora. Se veniva fatto nel Medioevo o nel Rinascimento, allora è probabile che nella SCA ci sia qualcuno interessato a rifarlo oggi.

Quel che rende la SCA diversa da una lezione di storia del primo anno è la partecipazione attiva nel processo di apprendimento. Per imparare come ci si vestiva in quel periodo, si fanno ricerche, poi ci si cuce gli abiti e li si indossa in prima persona. Per imparare come si combatteva, si indossa un'armatura (che si potrebbe persino aver costruito da soli) e si apprende come difendersi da un nemico. Per imparare la produzione di alcolici, si produce (e si assaggia!) il proprio vino, il proprio sidro, o la propria birra.
 
Questa introduzione pone l'accento sull'aspetto del “ricreare la storia” tipico della SCA, ma si percepisce bene che anche l'elemento di gioco di ruolo è altrettanto importante, ed era anche l'aspetto che maggiormente attirava i fan di D&D come Fesselmeyer e Brown. 
L'idea dietro la struttura dell'organizzazione era quella di dividere il Nord America in “reami”, ognuno guidato da un re e da una regina. Da loro discendeva quindi una ragnatela di baroni e duchi, contee e roccaforti. Ogni membro si sceglieva un nome medievale e molti ideavano anche un elaborato personaggio fittizio con tanto di stemma. Il re e la regina venivano scelti in ogni reame tramite il fragore delle armi in un grande Torneo per la Corona. Ed effettivamente i duelli cavallereschi giocavano un ruolo predominante nella SCA: John Nelson mi ha raccontato di essersi fermato un giorno a casa di Brown, trovando lui e Fesselmeyer “intenti in un duello di spade nel soggiorno”. Molto della SCA assomiglia a un esempio di lunghissimo termine del moderno genere dei giochi di ruolo dal vivo (“live-action role-playing games” - LARPs), a loro volta nati in larga misura dalla tradizione dei GdR da tavolo. Non ci dobbiamo quindi meravigliare se Fesselmeyer, Brown,e molti altri appassionati di D&D, trovassero ugualmente intrigante la SCA; e certo una grande parte degli iscritti era composta da giocatori abituali di D&D, tanto più in quel ricettacolo del gaming che furono gli Stati Uniti d'America medio-occidentali degli anni '70.
 
Se Brown è il padre di Eamon, Fesselmeyer (che morì in un incidente d'auto mentre andava a un'incoronazione della SCA nel 1984) ne è il padrino, perché fu lui a spingere Brown a combinare i suoi due interessi in un sistema per giocare di ruolo su computer. 
Brown probabilmente iniziò a distribuire Eamon tramite il Computer Emporium, ad un certo punto nella seconda metà del 1979. Da subito collocò Eamon nel pubblico dominio: il Computer Emporium lo “vendeva” con i suoi scenari su dischetti al costo dei supporti su cui era contenuto.
 
Nella pratica il concetto dietro Eamon si rivelò al tempo stesso eccitante e problematico. Ma di questo parlerò nel prossimo post, quando osserverò più da vicino come è costruito Eamon e cosa significasse giocare a una delle sue prime avventure.

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



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

L'Interactive Fiction di Robert Lafore
The Digital Antiquarian (traduzione ufficiale italiana)

Domanda veloce: chi ha coniato per primo il termine interactive fiction? E perché?

Presupponendo che sappiate la risposta e presupponendo che anche voi siate dei tipetti loquaci come me, probabilmente avrete risposto qualcosa del genere:

Il termine ha avuto origine molti anni dopo la nascita del genere che descrive, all'inizio degli anni 80, con una società chiamata Infocom. A quel tempo i giochi di questo tipo erano comunemente noti come "giochi d'avventura" o "avventure testuali", con quest'ultimo termine che serviva a distinguerle dai giochi narrativi con grafica che stavano iniziando a spartirsi il mercato con i titoli meramente testuali. A dire il vero entrambi i termini sono usati comunemente ancora oggi, anche se ormai connotano un genere piuttosto "old-school", che pone la maggior parte della sua enfasi sugli aspetti ludici, invece che sulle potenzialità letterarie di questa tipologia. La Infocom decise che "interactive fiction" era il termine che descriveva meglio il suo obbiettivo di creare una vera e propria nuova forma di letteratura e -dopo la fine di questa società- di quel termine se n'è appropriata la moderna comunità di storyteller testuali (che da molti punti di vista si considerano gli eredi della tradizione della Infocom).

Questo è ciò che ho scritto cinque anni fa [era quindi il 2006 NdT] nella mia storia dell'interactive fiction. Credo che descriva ancora piuttosto bene il motivo per cui la Infocom ha rimpiazzato il termine "avventura testuale" con IF; tuttavia questa risposta non è accurata almeno da un importante punto di vista: il termine non è stato creato dalla Infocom. È stato infatti coniato da un tizio chiamato Robert Lafore, che aveva fondato una società omonima nel 1979 e che aveva pubblicato software dal 1980 al 1982 attraverso la Adventure International di Scott Adams. Quando Lafore arrivò alla  Adventure International, aveva già tre titoli pronti: Local Call for Death e Two Heads of the Coin sono due gialli palesemente ispirati rispettivamente a Lord Peter Wimsey di Dorothy L. Sayers e allo Sherlock Holmes  di Arthur Conan Doyle, mentre invece Six Micro-Stories ci presenta sei brevi storielle con ambientazioni e generi diversi fra loro. Più o meno nel corso dell'anno successivo ne scrisse altre due: His Majesty’s Ship Impetuous (nello spirito dei romanzi di Horatio Hornblower di C.S. Forester) e Dragons of Hong Kong (nello spirito dei gialli orientali di Fu Manchu, scritti da Sax Rohmer).

Per comprendere l'idea che aveva Lafore dell'interactive fiction, iniziamo con l'analizzare il materiale pubblicitario dei suoi giochi. Dopo averci chiesto di "entrare in una nuova dimensione della letteratura", la pubblicità della Adventure International proseguiva così:

Tradizionalmente la letteratura è stata un medium a senso unico. Le informazioni scorrevano dal racconto al lettore; punto. L'interactive fiction cambia tutto questo, consentendo al lettore di partecipare attivamente alla storia.

Il computer ti presenta la scena: una situazione fittizia, che apprendi leggendola dal terminale. A quel punto tu diventi il personaggio della storia: quando viene il tuo turno di parlare, tu scrivi la tua risposta. Il dialogo con gli altri personaggi, e perfino la trama, a quel punto dipenderanno da ciò che dirai.

Wow. Nessun altro "gioco" per computer prima di allora aveva osato confrontare la propria storia con quella di un romanzo. Il testo di cui sopra, tenuto distinto dal programma vero e proprio che affermava di descrivere, ci mostra una vera visione del futuro della narrativa ludica.

Ma come sa chiunque abbia un minimo di esperienza con le pubblicità dei primi giochi per computer, la realtà spesso non coincideva con la retorica pubblicitaria, con quest'ultima che spesso sembrava più rappresentare un'aspirazione che il prodotto vero e proprio, corrispondendo più al gioco che gli autori avrebbero voluto creare piuttosto che ai limiti tecnici imposti dai processori a 8 bit e alle loro minuscole memorie.

Ecco qui una partita completa della prima delle sei storielle di Six Micro-Stories: “The Fatal Admission”:

The Fatal Admission

 

Una coraggiosa avventura nel cuore del Terzo Reich

È l'oscuro Inverno del 1942, dalla Manica fino al Caucaso l'aquila nazista stringe l'Europa in un pugno di ferro. Tu sei Jimmy Maher, un americano che lavora per l'O.S.S., la nostra agenzia di spie super-segreta. Ti hanno paracadutato nel cuore del Terzo Reich di Hitler, dove la tua missione è ottenere informazioni in qualunque modo.
Cortese e pieno di risorse, non hai difficoltà a convincere i nazisti che sei il colonnello Hans Braun, un asso pluri-decorato della Luftwaffe. Ti muovi liberamente ai più alti livelli della società nazista, dove apprendi incredibili segreti sui nazisti, che poi comunichi a Washington via radio.

Tutto va alla perfezione e sei certo che la tua copertura sia assolutamente sicura, finché una sera non ti ritrovi a una sontuosa cena di gala, proprio davanti al temibile Ammiraglio Kurtz, capo della Gestapo.
Ti fissa con un penetrante sguardo blu di ghiaccio e per la prima volta inizi a preoccuparti. Possibile che sappia chi sei veramente? O forse lo sospetta e basta?

ADMIRAL KURTZ: Und so, Colonel Braun, si sta divertendo?

("Colonel Braun" in realtà è ovviamente Jimmy Maher)

MR MAHER: _

MR MAHER: Molto, grazie

ADMIRAL KURTZ: Mi fa piacere sentirlo, Colonnello. Mi dica, se ho capito bene, lei è con la 57esima Squadriglia di Dusseldorf. Per caso conosce il Capitano Eiderdown? È un mio vecchio compagno di scuola.

(Ti fissa di nuovo con il suo sguardo di ghiaccio. Perché te lo chiede? È una specie di trappola? Adesso vorresti esserti candidato per un compito meno pericoloso, tipo i sommergibili.)

MR MAHER: _

MR MAHER: Mi dispiace, non lo conosco.

ADMIRAL KURTZ: Non mi sorprende, visto che non esiste una persona con quel nome. Ma non c'è nemmeno un 57esimo Squadrone, né a Dusseldorf, né altrove. Eppure lei, Colonnello, ha lasciato intendere che esistesse!!! Credo che lei sia un impostore, Colonnello, e per quanto lei sia stato un perfetto commensale, temo di doverla mettere sotto arresto. Guardie!!! Arrestate quest'uomo. È un nemico del Reich.

Vieni trascinato via dai soldati con le temute insegne della testa della morte delle SS sulle loro sinistre uniformi nere, e all'alba vieni giustiziato.

(PREMI -ENTER- PER PROSEGUIRE)

È doveroso precisare che questa non è l'opera migliore di Lafore; cercherò quindi di essere clemente. Mettiamo da parte il fatto che un ammiraglio sarebbe potuto essere solo nella Kriegsmarine e non nella Gestapo, oltre al fatto che evidentemente Lafore non conosce minimamente il tedesco. E lasciamo pure da parte l'illogicità della premessa della svolta nella storia (se davvero ho impersonato il Colonnello Braun per così tanto tempo, come è possibile che non sappia a quale Squadrone appartenevo?). E lasciamo da parte anche l'ingiustizia di dover imparare morendo, che caratterizza l'intera esperienza di gioco. Mi limiterò semplicemente a esaminare come funziona il programma.

A questo punto nessuno di voi resterà sorpreso nello scoprire che il programma non decodifica in nessun modo significativo le risposte del giocatore, ma anzi si limita a ricercare dei semplici schemi all'interno degli input del giocatore, un po' sullo stile di quello che faceva Eliza, ma perfino senza i suoi accorgimenti più sofisticati. Ed è per questo che si rivela inevitabilmente molto semplice far "inciampare" il programma, intenzionalmente o non. Considerate ad esempio la seguente domanda dell'ammiraglio sul Capitano Eiderdown:

MR MAHER: Non solo lo conosco, ma lo adoro!

ADMIRAL KURTZ: Non mi sorprende, visto che non esiste una persona con quel nome.

[...]

(PREMI -ENTER- PER PROSEGUIRE)

Quello che è successo è che il programma ha trovato il "NON" all'interno dell'input del giocatore e quindi ha scartato tutto il resto, presupponendo di essere in presenza di una risposta negativa. Purtroppo non si tratta di un incidente isolato. Proviamo a rispondere di nuovo alla domanda trabocchetto sul 57esimo Squadrone e a sopravvivere a questo passaggio.

MR MAHER: Non esiste nessun 57esimo Squadrone

ADMIRAL KURTZ: Proprio così! La stavo semplicemente mettendo alla prova; spero che mi perdonerà per questa piccola formalità. Vede, figlio mio, lei mi piace. Lei è la persona che stavo cercando come mio corriere personale. Ho molti documenti top secret e sento istintivamente di potermi fidare di lei per la loro consegna. È disposto ad accettare questo incarico?

Ottimo! Ora possiamo accettare il nuovo incarico e apprendere ancora altri succosi segreti dei Nazisti.

MR MAHER: Ne sarei onorato

ADMIRAL KURTZ: Per favore, Colonnello, non meni il can per l'aia. Il tempo è importante. Ho un appuntamento con un bel pilota di carrarmato... Cioè... volevo dire con una bella fraulein. Intende accettare l'incarico, oppure no?

Ooops. Stavolta il programma non è proprio riuscito a comprenderci (che però è sempre meglio di un fraintendimento, credo).

ADMIRAL KURTZ: Per favore, Colonnello, non meni il can per l'aia. Il tempo è importante. Ho un appuntamento con una bella pilota di carrarmato... Cioè, una bella fraulein. Intende accettare l'incarico, oppure no?

MR MAHER: Sì

ADMIRAL KURTZ: Molto bene!!! Inizieremo domani.

Così passi il resto della guerra con questa cornucopia dell'intelligenza militare. Il tuo contributo allo sforzo bellico sarà riconosciuto come insostituibile dal Generale Eisenhower e dopo la Giornata della Vittoria ti viene riconosciuta dal governo americano una pensione enorme.

Evidentemente le risposte semplici sono le migliori.

Le varie storielle di Six Micro-Stories usano in modo diverso il testo inserito dal giocatore. Forse la più complessa e tecnicamente interessante di questa raccolta è quella chiamata “Encounter in the Park”, nella quale si deve provare a ottenere un appuntamento con una ragazza incontrata per caso al parco. Funziona come una versione con obbiettivo di Eliza, seppure piuttosto primitiva. Qualora la connessione non sia già evidente di per sé, il nome di colei che ci interessa è proprio -ma lo avrete già immaginato- Eliza. 

Svoltato l'angolo davanti a te, lei scivola su un tratto bagnato e cade; in modo abbastanza aggraziato, ma fa cadere i libri che stava portando. È l'opportunità che aspettavi, forse l'opportunità di tutta una vita. Ti lanci in avanti e raccogli i suoi libri, mentre lei si rialza. Noti che uno dei libri è "Coppie" di John Updike.

JIMMY: Ecco a lei, signorina.

LA DONNA: Grazie.
(La sua espressione non è né incoraggiante, né non. La tua prossima affermazione potrebbe essere determinante.)

La soluzione finale è il gelato; basta menzionarlo e Eliza lascia cadere i suoi sofisticati orpelli da lettrice di Updike e precipita in un sottomissione da studentessa (le implicazioni di un tale comportamento in una società paternalistica come la nostra è meglio lasciarle agli esperti di sociologia).

JIMMY: Posso comprarti un gelato?

LA DONNA: Che bello! Adoro il gelato! Dammi un caramellato al caffè e farò tutto quel che vuoi!

La ragazza, palesemente interessata a te, accetta di andare a una lettura di poesie al Caffè No Name. A sera siete già buoni amici. La settimana successiva, dopo aver buttato al vento le vostre vite precedenti, sei disteso accanto a lei su una spiaggia di Bali, dove resterai per sempre in uno stato di cosmica beatitudine.

Un'altra storiella invece è poco più di un quiz a risposta multipla sulla vecchissima questione della definizione di arte.

DOTT. ZEROUGH: Ecco qua la domanda: cos'è l'arte? Risponda con attenzione, Sig. Maher.

MR MAHER: Bellezza.

DOTT. ZEROUGH: Sta facendo un errore fondamentale, Sig. Maher. La maggior parte delle persone concordano che certi fenomeni naturali (come i tramonti) sono belli, eppure quelli non vengono chiamati arte, perché in loro non c'è nessun artista immediatamente riconoscibile. Quindi l'arte può certamente essere bella, ma non c'è nessuna connessione necessaria fra arte e bellezza.
Mi dispiace, ma non posso promuoverla in questo esame. In bocca al lupo con le lezioni di composizione floreale.

E poi c'è quella nichilistica, in cui qualunque cosa noi scriviamo non fa alcuna differenza:

Voli alla latitudine e longitudine di Chicago, ma anche lì c'è solo l'oceano sotto di te e il silenzio su tutte le frequenze radio.
Decidi quindi che è giunto il momento di fare  un qualche annuncio appropriato ai passeggeri. Attivi l'altoparlante e prendi il microfono.

CAPITAN MAHER: Sembra che...

Prima che tu abbia finito di parlare, l'intero aeroplano (inclusi te, la ciurma, e i passeggeri) svanisce nel nulla, lasciando solo il mare strano e vuoto.

Quando ha scritto questa, Lafore o era di cattivo umore, oppure era giunto a una qualche verità esistenziale che il resto di noi non può sopportare di conoscere – scegliete voi.

Ma queste sono eccezioni. Se guardiamo oltre il parser, per studiare le opzioni a disposizione del giocatore (sia lodato il BASIC!), scopriamo che il resto delle storielle -oltre alle infinitamente più appetibili storie complete- sono in realtà delle narrazioni a scelta multipla in cui il giocatore può scegliere (solitamente) da due o (sporadicamente) tre, quattro, o cinque opzioni, sempre e solo in una serie di punti decisionali predefiniti. In altre parole queste in realtà sono storie del tipo  "choose-your-own-adventure" / narrativa iper-testuale / narrativa basata su scelte (scegliete voi il termine che preferite). Sono molto più simili ai Librigame (che nel 1980 già iniziavano a inondare le librerie) di quanto non lo siano alle avventure testuali di Scott Adams, o -tanto più- all'interactive fiction che la Infocom avrebbe iniziato a pubblicare di lì a poco. È solo che la loro vera natura è oscurata dal frustrante "parser" stile Eliza, che ci costringe a un ulteriore strato di congetture a ogni decisione che dobbiamo prendere. Ovviamente si può anche spendere qualche parola a favore del parser: almeno teoricamente infatti permettere al giocatore di prendere decisioni "con le proprie parole" potrebbe essere funzionale al farlo immedesimare ancora di più con la storia e il ruolo che vi svolge; in pratica però i fraintendimenti sono talmente tanto numerosi da farci dimenticare qualunque aspetto positivo.

Per farvi vedere quanto ridicolamente posso spingermi in là pur di dimostrare di aver ragione, ho reimplementanto His Majesty’s Ship Impetuous  (che considero la migliore fra le storie lunghe di Lafore) utilizzando il sistema ChoiceScript (ok, è vero, effettivamente avevo già maturato la decisione di provare  ChoiceScript, e questo progetto si è rivelato la scusa perfetta...). Se vi va di giocarlo, scoprirete che in questa forma è un'opera ben più completa e soddisfacente di quelle che ho illustrato sopra, seppur non del tutto priva di alcuni dei loro problemi di design (infatti, per ottenere un risultato ottimale, è comunque necessario imparare dai propri errori letali). La scrittura di Lafore resta comunque acuta e perfetta per il genere, e la storia nel suo complesso è ben ideata: essa rappresenta probabilmente il pezzo di narrativa scritto con maggior competenza che avesse mai ornato gli schermi di un computer al 1980. E le sue ottime qualità risaltano ancora di più una volta liberate dagli orpelli stile Eliza. Senza considerare poi che è un titolo storicamente molto più interessante se osservato in questa luce, considerato che la narrativa a scelta multipla non era ancora arrivata sui computer prima dell'opera di Lafore.

Non voglio nemmeno provare a formulare una teoria dettagliata della narrativa a scelta multipla, anche perché Sam Kabo Ashwell lo sta già facendo, un passo alla volta, in una stupefacente analisi di varie opere di questo genere – una serie che non teme confronti con niente di quello che potrei direi io in questa sede. Voglio però sottolineare che la narrativa a parser e quella a scelta multipla sono molto diverse fra loro, nonostante siano continuamente confuse; il primo a fare questo errore fu forse proprio Lafore, ma di certo non è stato l'ultimo. Per esempio il newsgroup su Usenet che è stato per tanti anni il centro della discussione sull'IF (rec.arts.int-fiction) fu fondato in origine da degli appassionati di ipertesti, per poi essere invaso e cooptato dal popolo delle avventure testuali. E ancora oggi anche l'interessantissimo progetto Varytale [ormai defunto: ndAncient] si definisce "interactive fiction". La  Choice of Games non si spinge tanto in là, ma incoraggia comunque attivamente i suoi autori a presentare i loro giochi scritti in ChoiceScript alle competizioni di IF; il che personalmente non mi infastidisce più di tanto, ma contribuisce forse  a portare due insiemi diversi di aspettative in rotta di collisione, senza che nessuno dei due ne abbia un vero vantaggio.

La principale differenza formale fra i due generi sta nella granularità delle scelte offerte al giocatore. L'IF basata sul parser si sviluppa tramite “micro azioni”: raccogliere e lasciare oggetti, spostarsi da uno spazio circoscritto a un altro, armeggiare con quel lucchetto esattamente nel modo giusto per far aprire la porta. La narrativa basata su scelte multiple invece si sviluppa (quando è eseguita al meglio) tramite grandi decisioni distintive: scendere in guerra con l'Eastasia o con l'Eurasia, provare a cercare un modo per rientrare nella Caverna del Tempo oppure rinunciarci. Anche quando le scelte che ci vengono presentate hanno una granularità apparentemente simile a un'opera di IF a parser (come quando si tratta di scegliere se svoltare a sinistra o a destra nel dungeon che stiamo esplorando), a tali scelte devono comunque seguire delle vere conseguenze. Una singola scelta in una narrativa basata su scelte multiple può racchiudere in sé l'equivalente di migliaia di turni di un'opera di IF a parser – o anche un intero gioco. Quando gli autori combinano insieme una struttura basata sulle scelte con un livello di granularità da IF a parser, i risultati sono quasi sempre sfortunati: guardate per esempio Trap Cave della IFComp del 2009 (che ha cercato di incastrare l'esplorazione di una caverna in stile Adventure in un formato a scelte multiple), oppure  guardate l'analisi di Ashwell del librogame Fighting Fantasy. Una narrativa a scelta multipla per avere successo deve necessariamente dare al suo giocatore una vera “agency” sulla narrazione – e lo deve fare a un livello alto e autenticamente distintivo, permettendo di scegliere la direzione in cui si muove la trama. L'interactive fiction basata sul parser non ha un tale limite; può accontentarsi di lasciare il giocatore allegramente alla prese con i dettagli, mentre lo guida per mano lungo un arco narrativo sostanzialmente su binari.

Poiché possono raccontare larghi archi di storia in un balzo, potremmo essere tentati di concludere che i giochi basati su scelte multiple consentano di narrare storie più profonde e più ricche. In un certo senso questo è vero, specie nel contesto del 1980: allora sarebbe stato impossibile racchiudere anche solo il 10% della storia di His Majesty’s Ship Impetuous in un gioco sullo stile di quelli di Scott Adams. È anche vero però che le narrazioni a scelta multipla generalmente non vertono tanto sullo sfidare il giocatore con enigmi e dilemmi tattici, quanto piuttosto sull'esperienza “pura” della storia. Dave Albert, un recensore dell'epoca di His Majesty’s Ship Impetuous  -che scriveva per la rivista SoftSide-, molto argutamente ha rilevato le seguenti qualità, e nel farlo ha riassunto bene anche le gioie della narrazione a scelta multipla e alcune delle frustrazioni legate alla primissima implementazione della stessa che ne fece Lafore:

Lafore ha provato a scrivere una storia aperta, con diversi possibili finali, e ha provato a strutturarla in modo tale che il lettore/giocatore non sia consapevole dell'importanza delle decisioni che prende. Se nelle storie precedenti al giocatore era permesso fare qualunque domanda gli venisse in mente (spesso con risultati incongrui e confondenti), in Impetuos ci vengono presentate solo decisioni del tipo "sì/no". Non si può aggirare in alcun modo questa struttura e per il programma è un bene che sia così. Non ci sono enigmi da risolvere, ma solo una storia da sviluppare. Il fine ultimo è sopravvivere e a stabilire se ci riuscirete saranno le decisioni che prenderete. Tuttavia non potete sapere in anticipo qual è la condotta che può garantirvi il successo. Nel programma ci sono abbastanza passaggi critici (decisioni) da mantenervi nell'incertezza delle conseguenze delle vostre azioni anche dopo numerose partite. Il che aumenta di moltissimo il valore del programma.

Non definirei così positivamente come fa Albert tutte le specifiche scelte di design presenti in Impetuous, ma credo che nel complesso la sua riflessione stia in piedi. Le opere a scelte multiple incoraggiano il giocatore a guardarle dall'alto, come un burattinaio che manipola non solo i fili del burattino, ma anche quelli della trama vera e propria; notate che non a caso Impetuous è scritto in terza persona passato.  Il giocatore manipola la storia, ma non sempre si sente DENTRO la storia. Alcune delle ultime opere a scelta multipla hanno addirittura definitivamente separato del tutto il giocatore da un suo avatar dentro il mondo di gioco. L'IF a parser invece eccelle nel metterti PROPRIO DENTRO LA STORIA, immerso nella realtà virtuale che stai esplorando.

Entrambi gli approcci sono validi per raccontare tipi diversi di storie, per creare tipi diversi di esperienze; ed entrambi possono essere usati in modo terribilmente sbagliato. Troppe opere a scelta multipla fanno sentire il giocatore così separato dall'azione da fargli smettere di essere coinvolto in ciò che succede (questo è -mi duole ammetterlo- esattamente come mi sento io quando gioco anche i più moderni fra i giochi ChoiceScript, ed è questa la ragione principale del perché il mio cuore appartiene fermamente al campo dei giochi a parser); troppe opere a parser, specialmente le prime, sono invece talmente rognose da risultare soltanto frustranti.

Senza le frustrazioni del parser, Impetuous è un'opera che funziona abbastanza bene, scritta con un adeguato livello di astrazione per la forma della narrativa a scelta multipla utilizzata. Se anche molte delle sue scelte sono in realtà false (perché non hanno conseguenze vere sulla trama), il gioco riesce a nasconderle bene quanto basta per non farlo comprendere al giocatore, almeno non durante la sua prima partita, mentre al tempo stesso ci sono abbastanza scelte significative da tenere alto l'interesse del giocatore nelle partite seguenti. Ma, soprattutto (e in modo assolutamente sorprendente, specie se consideriamo la struttura dei primi Librigame cartacei [e anche di tanti successivi... ndAncient]), non ci sono scelte arbitrarie e prive di adeguato contesto (svolto a sinistra oppure a destra?), e nessuna scelta che conduce a una morte prematura di punto in bianco. Certo alcune delle sue posizioni etiche sono discutibili (come ad esempio il modo in cui premia il gettarsi a testa bassa nella battaglia, invece di un approccio più ponderato), ma forse questo è anche quello che ci si aspetta dagli stilemi del genere a cui appartiene la sua storia.

Uno degli aspetti più divertenti e/o sconcertati di scrivere questo blog è stato che a volte mi sono trovato a rendere onore a dei pionieri che non hanno alcuna idea di esserlo. Lafore (dopo aver scritto Dragons of Hong Kong) scambiò la sua azienda di “entertainment-software” per una carriera (lunga, ricca di successi, e tutt'ora in corso) come autore di libri tecnici. Sono pronto a scommettere che non ha alcuna idea che il termine da lui coniato così tanti anni fa è ancora vivo e vegeto, mentre le opere in cui lo ha concretizzato sono state in larga parte dimenticate.

Per rimediare almeno in parte a quest'ultimo problema, date un'occhiata alla mia implementazione di His Majesty’s Ship Impetuous. Ritengo che in questo formato funzioni abbastanza bene e che sia più divertente e ben scritta di quanto non ci si aspetterebbe (e il merito di questo, ovviamente, è tutto di Lafore).

Se invece volete giocare le versioni originali di Six Micro-Stories o di His Majesty’s Ship Impetuous, potete fare anche questo.

1. Scaricate il mio "Robert Lafore starter pack".
2. Avviate l'emulatore sdltrs.
3. Premete F7, poi caricate “newdos.dsk” nel floppy drive 0, e quindi o “microstories.dsk” oppure “impetuous.dsk” nel floppy drive 1.
4. Riavviate l'emulatore premendo F10.
5. Al prompt DOS, scivete BASIC.
6. Digitate LOAD “STORY:1″ per Six Micro-Stories; oppure LOAD “STORY1:1” per His Majesty’s Ship Impetuous.
7. Digitate RUN.

La prossima volta darò un'occhiata alla situazione in evoluzione dell'industria dei computer nel 1980 – e inizierò ad eseguire un lesto (si spera) cambio di piattaforma.

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


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

Temple of Apshai
The Digital Antiquarian (traduzione ufficiale italiana)

 
Nel 1978 un tizio chiamato Jim Connelley acquistò un Commodore PET pensando che gli sarebbe stato d'aiuto nella gestione della campagna di Dungeons and Dragons che stava conducendo. Quando finalmente lo ebbe a casa, forse realizzando che l'utilità di quella meraviglia a 8 K era quantomeno limitata, fu assalito dal rimorso per i soldi spesi. Così, poiché amava i giochi, gli venne l'idea di scriverne uno per quella macchina: anche se non avesse venduto abbastanza copie da farci un vero guadagno, se non altro avrebbe potuto usare quel progetto per detrarre l'acquisto del PET dalle sue tasse a titolo di "business expense". Sfortunatamente però Connelley si rivelò migliore come programmatore che come game designer, e così i suoi primi tentativi non portarono a niente di concreto. Si decise così a chiedere aiuto a uno dei suoi giocatori di D&D, Jon Freeman. Costui era nella situazione diametralmente opposta: aveva lavorato per diversi anni come giornalista freelance di giochi ed era particolarmente portato per il game design, ma non aveva nessuna nozione di programmazione. Fra i due fu subito celebrato un matrimonio di convenienza.
 
Il primo frutto di questa unione apparve già prima della fine dell'anno: si trattava di un gioco di strategia spaziale chiamato Starfleet Orion. Per poterlo pubblicare Connelley e Freeman dettero vita alla Automated Simulations, il primo publisher della storia dedicato esclusivamente ai videogiochi. Starfleet Orion ha un aspetto alquanto bizzarro se lo guardiamo con gli occhi di oggi, perché sembra più un “construction set” con un pizzico di valenza ludica, piuttosto che un videogioco vero e proprio. Il suo manuale traccia un elaborato background per giustificare una dozzina di scenari di battaglie spaziali fra due razze aliene. La disposizione e l'ordine di battaglia per ognuno dei due schieramenti ci viene dato, in pieno stile wargame da tavolo, nel manuale; quindi il primo passo, prima di poter giocare davvero, consiste nell'inserire a mano tutti questi dati in un programma, per poi salvarlo su una cassetta vuota usando un programma separato chiamato BUILDER. Con un tocco che per le sensibilità odierne è particolarmente assurdo, nel manuale troviamo anche il codice sorgente del gioco in BASIC, qualora il giocatore volesse ritoccarlo o la cassetta che lo conteneva  si rovinasse. Starfleet Orion non solo era pensato per due giocatori, ma richiedeva anche un ingente investimento di tempo: il manuale stimava che lo scenario finale avrebbe richiesto circa sei ore per essere giocato, ovviamente senza nessuna possibilità di salvare.  Freeman e Connelley risolsero almeno in parte il primo problema con Invasion Orion (un sequel più accessibile che prevedeva la possibilità di giocare da soli), che fu pubblicato all'inizio del 1979.
 
 
Ma la loro pubblicazione più significativa del 1979 li portò lontani dallo spazio, giù nei meandri di  un dungeon. Per Temple of Apshai fecero entrare anche un terzo socio, preso direttamente dal loro gruppo di D&D,  Jeff Johnson, affinché li aiutasse con un progetto ancora più ambizioso. Temple of Apshai sarebbe dovuto essere infatti un vero e proprio GDR per computer, che attingesse alla tradizione dei giochi su PLATO (tipo dnd), ma che al tempo stesso pagasse un esplicito omaggio alla più autentica esperienza del vero D&D da tavolo, che li aveva fatti conoscere. Non a caso il manuale si apre con una descrizione del gioco esperienziale che è tratta direttamente dalla loro esperienza di gioco dal vivo:
 
"I giochi di ruolo non vengono "giocati", quanto piuttosto "vissuti". Invece che manipolare un esercito di pedine su una scacchiera astratta ma visibile, o invece che seguire una singola pedina intorno ad un percorso predefinito prendendo 200 dollari ogni volta che si passa dal VIA, nei GdR ti avventuri in un mondo sconosciuto con una singola pedina, il tuo alter ego dentro il gioco (un personaggio che viene da un mondo di demoni e tenebre, di draghi e di nani). Attraverso gli occhi di questo personaggio vedi una scena che ci viene descritta a voce "dall'autore" dell'avventura – e nient'altro. Non c'è scacchiera e non c'è nessun evento fortuito da pescare dal mazzo; il paesaggio immaginario esiste solo negli appunti del creatore del mondo (comunemente definito "arbitro" o "dunjonmaster") e -gradualmente- nell'immaginazione tua e dei tuoi compagni. Ti imbarchi in una missione in cerca di gloria e di fortuna in compagnia di altri giocatori/personaggi, dove sei sia il protagonista che il lettore di una storia epica che stai contribuendo a creare. Il tuo personaggio fa tutto ciò che tu desideri che egli faccia, secondo le sue umane (o quasi umane) capacità e i capricci della fortuna. Combatti, scappa, chiedi una tregua; prendi la strada a sinistra, o quella a destra: la scelta è solo tua. Puoi scalare la montagna, oppure girarci attorno, ma poiché in cima potrebbe esserci una roccia, oppure un uovo di roc, oppure un roc vero e proprio, potrai trovare sfide e conflitti anche senza dover combattere contro i tuoi compagni giocatori, che solitamente saranno sulla tua stessa barca (magari anche letteralmente)".
 
 
Come i giochi della serie Orion, anche Temple of Apshai mette in primo piano i suoi aspetti esperienziali. I giochi come dnd diventavano rapidamente degli esercizi astratti di tattica e strategia, in cui era necessario riservare ben poca attenzione alle premesse narrative che avrebbero dovuto giustificare la nostra esplorazione del dungeon. Temple of Apshai invece fa tutto il possibile per non farci adottare un tale atteggiamento mentale. Tenta esplicitamente di farci calare nei suoi cunicoli umidi in vari modi: cercando di fare proseliti con l'introduzione di cui sopra; utilizzando un ampio background volto a giustificare l'esistenza del dungeon che stiamo esplorando; descrivendo il personaggio che siamo liberi di utilizzare come il nostro alter ego (“Brian Hammerhand”); e -soprattutto- utilizzando tutta una serie di descrizioni delle stanze che visiteremo, simili a quelle di un modulo d'avventura di D&D, che al giocatore è richiesto di leggere dal manuale mano a mano che esplora il dungeon:
 
"Stanza Uno – La pietra levigata del pavimento del corridoio mostra che nella sua costruzione sono state utilizzate tecniche piuttosto avanzate. Subito al di là della porta uno scheletro è disteso sul pavimento, la mano scheletrica -ancora stretta su un pugnale rugginoso- è allungata verso la salvezza dell'uscita. Un debole fragore può essere sentito provenire dall'altra estremità del cunicolo".
 
A differenza di altri dei primi dungeon crawl, i cui dungeon erano generati casualmente (o ideati talmente a casaccio che era come se lo fossero stati), i labirinti di Temple of Apshai sono costruiti per trasmettere la sensazione di un luogo reale, anche se ciò significa che i suoi mostri sono in gran parte limitati ai tipici abitanti delle fogne (ratti giganti e vari insetti giganti) e, nei livelli inferiori che ospitano il tempio vero e proprio, a non morti vari.  
 
A essere onesti, l'aver posto tutto questo accento sulla componente esperienziale appare un po' ridicolo per le moderne sensibilità, perché... beh, tanto per iniziare ecco l'aspetto del gioco nella sua originale incarnazione per TRS-80:
 
 
Il fatto che questa grafica risulti un po' deludente non è però colpa dei designer di  Temple of Apshai. Il TRS-80 era limitato al bianco e nero (e non, è bene precisarlo, alla scala di grigi – proprio due soli colori: bianco e nero). E poi non aveva delle vere e proprie capacità grafiche così come le intendiamo oggi, ma solo grafica a caratteri testuali (oltre ai 64 glifi comunemente utilizzati in Inglese, includeva altre 64 tile grafiche, ognuna con una semplice forma astratta al posto del glifo di un carattere. Combinando i due tipi di glifi insieme, era possibile costruire immagini più grandi, pur restando all'interno di quella che era essenzialmente una modalità di visualizzazione meramente testuale). Alla luce di una modalità di visualizzazione del genere e di un computer dotato di soli  16 K e basato su cassette, Temple of Apshai può essere considerato una notevole impresa tecnica.
 
Anche le regole del gioco portano il segno di un game designer d'esperienza. In realtà non attingono così massicciamente al D&D come ci si potrebbe aspettare, date le origini del gioco e il lungo elogio dell'esperienza "pen and paper" che caratterizza il manuale. Anche se le sei caratteristiche base dei personaggi sono presenti proprio come ci si aspetterebbe, e anche se esse sono rappresentate da un punteggio variabile da 3 a 8 proprio come nel D&D classico, il combattimento e il movimento sono sostanzialmente originali: un sistema "pseudo-real-time" che dimostra l'intenzione di sfruttare le capacità uniche del computer, piuttosto che limitarsi a tradurre in codice le regole del gioco "pen and paper". E infatti Temple of Apshai, come gioco, funziona perfino meglio di quello che ci si aspetterebbe: c'è vera tensione mentre si attraversa il labirinto, dovendo decidere se sfidare la sorte e continuare ad avanzare, oppure se voltarsi e ritirare verso l'uscita, impauriti dalla possibile apparizione di un altro mostro errante mentre -a fatica e gravemente feriti- ripercorriamo i nostri passi, avendo magari sfidato la sorte più del necessario. L'esperienza trasmette una sensazione viscerale, che tanti dungeon crawler successivi non riusciranno a catturare. Ciò dipende, in parte dal gameplay in tempo reale, ma anche da altre scelte che non hanno un corrispettivo nel D&D da tavolo. Mano a mano che il vostro personaggio perde salute, per esempio, si muove più lentamente, si affatica prima e diventa meno efficiente, dimostrando quindi il suo stato in modo decisamente palpabile. Il design di Freeman è particolarmente intelligente, e da tanti punti di vista risulta perfino originale (anche rispetto a tanti giochi che lo seguiranno). 
 
Ma ci sono dei limiti a ciò che anche un bravo game designer può fare su un TRS-80 da 16 K. Possiamo certamente perdonare facilmente l'assenza totale di magia nel gioco: sostanzialmente il giocatore può impersonare soltanto l'equivalente della classe del guerriero di D&D. Più penalizzante è il fatto che le due componenti del gioco, "Inkeeper" ["Taverniere"] (che veniva usato per la gestione del personaggio) e  “DunjonMaster” (dove si svolgeva invece l'esperienza esplorativa nel labirinto) in realtà non comunicano davvero fra loro. Ci si aspetta infatti che il giocatore tenga traccia autonomamente per ogni spedizione delle sue caratteristiche e degli oggetti che trova nel labirinto, per poi inserirli manualmente quando rientra in Innkeeper! A questo va poi aggiunto che, anziché essere collegati fra loro, i quattro livelli del dungeon hanno accessi separati: niente impedisce al giocatore di inserire un super personaggio in Innkeeper e iniziare la sua esplorazione già dal livello 4. E del resto non è che l'esplorazione metodica abbia uno scopo preciso, dato che non c'è assolutamente nessun modo per vincere; nonostante tutta la sua enfasi sulla componente esperienziale, in Temple of Apshai non esiste alcuna conclusione vera e propria. Ci si limita a esplorare, livellare, e ad accumulare... finché non ci si stufa.
 
 
Eppure, pur con tutte le sue limitazioni tecniche, Temple of Apshai ha un suo strano fascino. Piuttosto che presentarci una storia, si aspetta che il giocatore lo utilizzi per costruire una storia che esiste tanto nella sua immaginazione, quanto nel computer. "Certo che puoi 'barare' creando un personaggio con tutte le statistiche a 18" sembra dirci, "ma dove starebbe il divertimento?". Allo stesso modo, se il gioco non ha un finale vero e proprio come abbiamo ormai imparato ad aspettarci, ciò non impedisce al giocatore di inventarsene uno tutto suo. Infatti nel livello 4 c'è un incontro che ha tutto l'aspetto di un vero climax; oppure il giocatore può semplicemente fissarsi lo scopo di visitare tutte le stanze e raccogliere ogni singolo tesoro che contengono. Temple of Apshai si aspetta che tu collabori con lui, per contribuire a creare il divertimento. Del resto Freeman, riferendosi ad una campagna di GDR da tavolo, ha scritto: "Non ha mai termine, se non temporaneamente: non c'è una vittoria finale, nessuno scopo per giocare se non il gioco in sé, e nessun fine ultimo se non il continuo sviluppo del tuo personaggio." E quindi perché mai l'equivalente informatico dovrebbe essere diverso? E infatti, se viene giocato come avrebbero voluto i suoi designer, Temple of Apshai non restituisce il feeling di un vero e proprio gioco per computer, quanto piuttosto quello di un ibrido: un GDR in solitario assistito dal computer, anziché un GdR su computer.
 
In un articolo sulla rivista Byte, Freeman descrive le differenze fra l'approccio simulativo alla narrativa (che è tipico dei GdR) e la preferenza delle avventure testuali per il design predefinito, lasciando però un alone di dubbio su dove cada la propria preferenza:
 

"Non c'è vero gioco di ruolo, per esempio, nella famiglia di Adventure e di Zork: il protagonista siete voi, solo immerso in un'ambientazione strana. I giochi di questo tipo si concentrano sul trasmettere la sensazione di un'azione senza confini: non solo c'è una moltitudine di comandi disponibili (tipicamente molti di più dei circa diciotto di  Dunjonquest), ma essi non vi vengono resi noti in anticipo, ma solo tramite la sperimentazione dentro il gioco. Può quindi rivelarsi particolarmente difficile trovare la chiave giusta, il momento giusto, e il comando giusto per inserirla nella giusta serratura; però, quando lo avrete fatto, la porta si aprirà – sempre. È per questo che un gioco come Adventure in realtà è un grande puzzle che, una volta risolto, perde completamente di interesse.
 
La serie di Dunjonquest impiega invece un approccio diverso. Per prima cosa tutte le situazioni sono definite principalmente in modo grafico, e non testuale: vedi ciò che succede e non ti limiti a esserne informato. Poi -ed è un aspetto ancora più importante per il nostro discorso attuale- anche se certi giochi di Dunjonquest (come  Morloc’s Tower) hanno uno scopo preciso (trovare ed uccidere Morloc, lo stregone pazzo e sfuggente), se andiamo a vedere nel dettaglio si tratta sempre di giochi molto aperti. Detto in termini più generali, non ci sono risposte "giuste": l'esito di ogni evento è probabilistico, non predeterminato.
 
Brian Hammerhand, il protagonista/alter ego assegnato al giocatore di Morloc’s Tower e di The Datestones of Ryn, ad esempio, può uccidere un lupo crudele nove volte su dieci, ma ogni volta può uscire dallo scontro illeso, ma anche dilaniato e allo stremo delle forze – senza considerare poi che c'è sempre quella decima volta... A questo va aggiunto che l'esatto esito di ogni scontro dipende sia dalla tattica scelta, che dai tratti specifici del personaggio che interpretiamo. L'esperienza è diversa a ogni partita e molto diversa per ogni nuovo personaggio che vi facciamo avventurare. Questo è gioco di ruolo: uscire da sé stessi, per mettersi nella pelle di un altro essere (anche se immaginario)."
 
L'affermazione secondo cui un approccio simulativo porta al gioco di ruolo, mentre un approccio basato su scelte predefinite non lo fa, ci deve però apparire altamente sospetta – anche se dobbiamo riconoscere che all'epoca in cui  Freeman scriveva questo passaggio, i protagonisti delle avventure testuali erano universalmente del tipo "avventuriero senza nome e senza volto". Tuttavia è indubbio che la tensione fra i due diversi approcci descritti da Freeman rimanga intatta fino ai giorni nostri con la narrativa ludica, spesso anche all'interno di uno stesso tipo di game design.  E infatti ritorneremo molte altre volte su questo argomento nel prosieguo di questo nostro piccolo viaggio nella storia. 
 
Se volete sperimentare di persona Temple of Apshai, ecco qua le istruzioni con cui partire. Notate, tuttavia, che vi servirà la pazienza di un santo: per le sensibilità moderne la versione originale per TRS-80 è quasi ingiocabile a causa della sua leeeeentissima velocità di aggiornamento dello schermo e della sua divisione in due metà del programma di cui ho parlato prima.
 
 
2. Avviate sdltrs emulator.
3. Premete F7, poi caricate “newdos.dsk” sul floppy drive 0 e “apshai.dsk” sul floppy drive 1.
4. Riavviate l'emulatore premendo F10.
5. Al prompt DOS digitate BASIC.
6. Digitate LOAD “INN:1”.
7. Digitate RUN.
 
Il manuale e la "quick reference card" nel file zip di cui sopra dovrebbero accompagnarvi con successo nei passi successivi.
 
In futuro continueremo ad occuparci dello sviluppo dei GdR su computer, ma la prossima volta torneremo alle avventure testuali, per scoprire in cosa era impegnato il nostro vecchio amico Scott Adams all'inizio degli anni '80.

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



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