The Ancient One
20/01/2020
Prodi Avventurieri, vi siete infine ripresi dai bagordi delle festività natalizie? Io no! Ho ancora l'olezzo appiccicoso e penetrante di Grue e capitone nei peli della barba... Ma non importa, perché l'Avventura chiama! E noi, rispondiamo... Sempre! Riemersi dalle profondità del Regno Sotterraneo di Zork è già il momento di scoprire le origini dell'ineluttabile seguito del capolavoro di Infocom, ma, attenzione, solo per questa volta, ci concederemo la libertà di compiere un balzo nella cronologia del Blog del "The Digital Antiquarian", proprio per seguire il percorso che abbiamo tracciato e che porterà a Zork II e persino a ... Zork III (come già rivelato nella nostra lista degli articoli). Ma non temete, una volta concluso il ciclo degli articoli Infocom, riprenderemo la normale cronologia, recuperando tutti gli articoli "saltati" (il nostro traduttore, The Ancient One, rinchiuso in una stamberga da mesi, ne ha già tradotti a migliaia, perdendo così moglie e lavoro... ma è il giusto prezzo della gloria eterna!). Ora vi lascio alla vostra meritata lettura, la prima di un anno speciale per noi avventurieri! L'ineffabile lista degli articoli del ciclo Infocom: – 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 Stringete la cinghia e prendete la lanterna...si riparte per un lungo viaggio! Festuceto |
Con Zork ormai sugli scaffali e pronto a diventare un grande successo commerciale, per la Infocom era giunto il momento di pensare all’inevitabile seguito. Il compito di prepararlo ricadde su Dave Lebling. A prima vista poteva apparire un compito abbastanza lineare: doveva solo prendere la metà dell’originale Zork per PDP-10 (la metà che non era finita nella versione PC), etichettarla come Zork II, e avrebbe finito. In realtà però le cose erano un po’ più complicate di così. Come minimo, il nuovo gioco aveva bisogno di una ristrutturazione. Per esempio, lo scopo della versione per PDP-10 di Zork (così come della successiva versione PC del primo capitolo) era quello di raccogliere un insieme di tesori all’interno di quella casa bianca dinanzi alla quale il giocatore aveva iniziato la propria partita. Tuttavia tale casa bianca non poteva esistere in Zork II. Forse spinto inizialmente dalla necessità, Lebling iniziò a mettere mano al design originale. E ben presto, ispirato dalla nuova tecnologia ZIL (che la Infocom aveva sviluppato per portare Zork su PC, e che era una tecnologia molto più flessibile, molto più potente, e più semplice con cui lavorare rispetto all’MDL che invece stava dietro all’originale Zork), Lebling iniziò a dargli una forma drasticamente nuova, mischiando elementi presi dall’originale con nuove aree, nuovi enigmi, e nuovi personaggi. Finì con l’usare solo una metà del materiale rimasto dalla versione PDP-10, e tale materiale a sua volta componeva circa una metà di Zork II; l’altra metà sarebbe stata nuova. Questo fa di Lebling il primo “implementatore” a creare consapevolmente un gioco della Infocom destinato alla vendita come prodotto commerciale sul mercato PC.
Vista dal mondo esterno, la Infocom stava iniziando a mettere le basi di quei tratti distintivi che la gente ben presto avrebbe imparato ad amare non meno dei loro giochi, basata su un’inclusività amichevole e spensierata, che faceva sì che chi comprava i loro giochi si sentisse un po’ membro di un “club di persone intelligenti”. E l’organizzatore e guida di tale club, anziché essere uno dei creatori di Zork o uno dei soci della Infocom, era Mike Dornbrook, appena laureato in biologia al MIT, che aveva conosciuto Zork solo nel 1980, e che era stato il primo e più importante beta tester della versione PC.
Più di chiunque altro alla Infocom, Dornbrook credeva in Zork, convinto che fosse molto di più di un interessante esercizio di hacking, o di un modo per raggranellare un po’ di soldi facili in vista di prodotti più seri, o anche di più di un “semplice” gioco divertente. Considerava Zork come qualcosa di completamente nuovo, qualcosa che nel suo piccolo poteva cambiare il mondo. E così incoraggiò vivamente la Infocom a costruire una community intorno a questa nascente forma d’arte. Su sua richiesta, la primissima versione di Zork includeva il seguente messaggio, scritto su un appunto all’interno dello studio dell’artista:
Congratulations! You are the privileged owner of a genuine ZORK Great Underground Empire (Part I), a self contained and self maintaining universe. As a legitimate owner, you have available to you both the Movement Assistance Planner (MAP) and Hierarchical Information for Novice Treasure Seekers (HINTS). For information about these and other services, send a stamped, self-addressed, business-size envelope to: Infocom, Inc. GUE I Maintenance Division PO Box 120, Kendall Station Cambridge, Mass. 02142 |
A quei tempi, unirsi al club delle persone intelligenti era ancora piuttosto complicato. La lettera con l’indirizzo già scritto di cui sopra sarebbe stata ritirata da Stu Galley, che ogni giorno si recava diligentemente alle poste. A quel punto, egli spediva un foglio in cui si proponeva l’acquisto di una mappa, oltre che il definitivo servizio di indizi su misura: per un paio di dollari l’uno, la Infocom avrebbe risposto personalmente a tutte le domande!
La mappa era un adattamento dell’originale di Lebling, creato da Dave Ardito, un artista amico di Galley, che abbellì le linee e i rettangoli con degli orpelli di natura opportunamente avventurosa. Dornbrook, che aveva già esperienza di stampa, usò i suoi privilegi di ex alunno del MIT per stampare le mappe, nel cuore della notte, su una grande stampante normalmente destinata alla produzione di manifesti e di volantini per gli eventi del campus. In cerca d’aiuto, arruolò il suo compagno di stanza, Steve Meretzky.
Anche Meretzky era un ex studente del MIT, laureato nel 1979 in gestione delle costruzioni. Pur avendo frequentato la più importante università informatica del mondo, Meretzky non aveva alcuna intenzione di entrare a far parte di quel mondo. “Detestava” i computer e gli hacker. Nella sua intervista in Get Lamp, Dornbrook parla del primo approccio di Steve Meretzky con Zork. Dornbrook stava testando il gioco e si era fatto prestare un TRS-80, portandolo nel loro appartamento, dove lo aveva collocato sul tavolo della cucina.
Lui [Meretzky], rientrando a casa, vide il computer e disse: “Lungi da me!”, con quel tono che solo Steve sapeva usare. Cercai di dirgli: “Steve, questo ti piacerà!”. Cercavo di spiegargli come iniziare a giocarci e lui si mise le mani sulle orecchie e iniziò a urlare per non sentirmi. Ma evidentemente sentì quanto bastava. Nel corso delle successive settimane, quando tornavo a casa e mi accingevo a rimettermi a fare il beta testing, mi accorgevo che la tastiera era stata spostata di qualche centimetro o che i miei appunti erano stati leggermente mossi. Compresi che Steve ci stava giocando, ma non voleva ammetterlo. Una notte alla fine scoppiò e mi disse: “Va bene! Va bene! Mi serve un indizio!”. Lì iniziò il tracollo di Steve. |
Di lì a poco Meretzky si candidò come beta tester e si unì a Dornbrook noi suoi progetti legati alla Infocom.
Fra gli extra di Get Lamp c’è un’ottima intervista a David Shaw, uno studente del MIT che scriveva sul giornale del campus, i cui uffici si trovavano proprio sopra la stampante che Dornbrook e Meretzky usavano di nascosto. Shaw era sorpreso dal fatto che la stampante “sembrava fosse sempre in funzione”, anche quando non c’erano nuovi eventi da promuovere: “Là sotto c’erano sempre i soliti due o tre tizi. Stampavano qualcosa che chiaramente non era il manifesto di un film, ed erano estremamente vaghi sull’oggetto del loro continuo stampare.” Un giorno Shaw trovò una “pila di scarti” delle mappe di Zork stampate da Dornbrook e Meretzky e comprese finalmente quel che stava accadendo.
Se le mappe erano uno sforzo di squadra, gli indizi ricadevano interamente su Dornbrook. Rispondeva a mano, su carta comune. Dopo un po’ si rese conto che si trattava di un impegno alquanto profittevole, seppure a volte noioso: molte delle richieste che riceveva erano solo variazioni di una manciata di identiche domande, e quindi predisporre delle risposte personalizzate non richiedeva poi tutto quel tempo che ci si sarebbe potuti aspettare (visitate la sezione della Infocom della Gallery of Undiscovered Entities per vedere delle scansioni della mappe originali e, meglio ancora, un paio di risposte scritte a mano da Dornbrook).
Poi Dornbrook fu accettato a un Master in “business administration” presso l’Università di Chicago, che sarebbe iniziato nell’ultimo semestre dell’anno; questo significava, ovviamente, che avrebbe dovuto lasciare Boston, rinunciando ai suoi contatti quotidiani con il gruppo della Infocom. Nessuno si sentiva in grado di rimpiazzare Dornbrook, che a questo punto era diventato (se non formalmente, di certo nei fatti) il capo delle pubbliche relazioni della Infocom. Dornbrook, preoccupato di ciò che sarebbe potuto accadere ai “suoi” fedeli clienti, cercò di convincere il Presidente Joel Berez ad assumere un dipendente che lo sostituisse. Impossibile, rispose Berez; semplicemente, l’azienda non aveva abbastanza risorse per poter impiegare una persona che si dedicasse esclusivamente ai rapporti con i clienti. Fu così che Dornbrook avanzò un’altra idea: avrebbe creato lui una nuova società, lo Zork Users Group, per vendere hint, mappe, memorabilia, e perfino i giochi della Infocom a un prezzo leggermente scontato per attirare nuovi membri del suo club, che lui avrebbe gestito da Chicago fra una lezione e l’altra. In cambio la Infocom si sarebbe liberata di questo complicato fardello. Avrebbero potuto semplicemente girare le richieste di aiuto a Dornbrook, preoccupandosi solo di fare più giochi, e migliori. Berez si disse d’accordo e lo Zork Users Group nacque ufficialmente nell’Ottobre del 1981. Avrebbe raggiunto i 20.000 membri, ma di questo parlerò meglio in futuro.
Per gran parte del 1981, la Infocom aveva dato per scontato che la Personal Software (il publisher del primo Zork) avrebbe pubblicato anche Zork II. Dopotutto Zork era stato un vero successo. Ed effettivamente la Personal Software rispose positivamente quando la Infocom gli parlò per la prima volta di Zork II nell’Aprile di quell’anno. Le due società dovevano addirittura firmare un contratto in Giugno. Ma un paio di mesi dopo, improvvisamente, la Personal Software si ritirò dall’accordo. E in più annunciò anche che avrebbe ritirato il primo Zork. "Cosa era accaduto?" si chiesero alla Infocom.
Quel che era accaduto, ovviamente, non poteva che essere VisiCalc. Dan Fylstra, fondatore della Personal Software, aveva fatto crescere la creazione di Dan Bricklin e Bob Frankston, donando loro un Apple II su cui sviluppare la loro idea. Pubblicato nell’Ottobre del 1979, VisiCalc trasformò l’industria dei microcomputer. E trasformò anche il suo publisher. La Personal Software, che fino ad allora era nota come publisher di giochi e di programmi per hobbisti, divenne di colpo “il publisher di VisiCalc”, una delle compagnie emergenti più promettenti della nazione. Per quanto fosse stato grande il successo di Zork, non era niente in confronto a VisiCalc. Già nel 1981 i giochi e il software per hobbisti costituivano meno del 10% del fatturato della Personal Software. C’è poco da meravigliarsi se spesso la Infocom avvertiva che la Personal Software avesse cambiato idea sul proprio gioco. In più, ora che l’IBM PC era all’orizzonte, la Personal Software si ritrovò corteggiata da giganti come la stessa “Big Blue”, che avevano bisogno che VisiCalc fosse disponibile anche sul loro nuovo computer. Quando anche la Microsoft iniziò a fare lo stesso, la Personal Software cominciò a trasformarsi, lasciandosi alle spalle le sue radici hacker e hobbistiche, per focalizzarsi sul mercato di VisiCalc e del software professionale, che in quel periodo stava letteralmente esplodendo. Per la prima volta iniziarono a sviluppare software internamente, sfornando tutta una linea di programmi pensati per capitalizzare il massimo profitto possibile dal nome di VisiCalc: VisiDex, VisiPlot, VisiTrend, VisiTerm, VisiFile. L’anno successivo, la Personal Software completò la propria “Visificazione”, cambiando nome in VisiCorp, ormai incamminati verso l’annichilimento in una gigantesca “VisiBotta”, che avrebbe prodotto uno dei più grandi fallimenti nella storia del software.
Secondo il nuovo paradigma aziendale, Zork non solo non era necessario, ma era addirittura potenzialmente pericoloso. I giochi erano l’anatema del nuovo esercito di clienti dai colletti bianchi, che di colpo avevano iniziato a comprare i PC. Le società come la Personal Software, che volevano rifornirli ed essere prese seriamente, nonostante le loro ambigue origini di hacker, iniziarono a tenersi alla larga da ogni cosa che fosse anche solo lontanamente legata all’entertainment. Tutta la linea di videogiochi sarebbe stata soppressa, vittima di quella stessa paranoia che teneva sveglio la notte Al Vezza.
Questa reazione mise la Infocom dinanzi a un bivio. Non che la cosa fosse particolarmente tragica: non mancavano di certo publisher più che lieti di metterli sotto contratto, adesso che avevano un gioco di grande successo all’attivo. Il problema era che non erano più sicuri che fosse quella la direzione in cui volevano andare. Anche se c’era certamente un certo prestigio nell’essere pubblicati dal più grande publisher del mondo, alla Infocom non sono mai stati davvero soddisfatti della Personal Software. Si sono sempre sentiti una bassa priorità. Il terribile packaging del “barbaro” di Zork portava a chiedersi se qualcuno alla Personal Software si fosse mai preso la briga di giocarci, e tutti gli sforzi pubblicitari erano apparsi sbrigativi e superficiali. Di certo la Personal Software non si era mai mostrata interessata ad aiutare la Infocom e Dornbrook a costruire una base fedele di clientela. Se davvero intendeva fare di Infocom il brand delle migliori avventure testuali del mercato, perché mai avrebbe dovuto tenere il logo di un’altra società sugli scatolati dei suoi giochi?
Ma, ovviamente, diventare un publisher significava per la Infocom diventare una “vera” società, anziché restare una società che faceva affari tramite una casella postale, con più personale dipendente e molti più soldi investiti. Dinanzi alla scelta fra mantenere la Infocom come una profittevole e piccola attività secondaria, o “provarci”, beh, i fondatori della Infocom scelsero questa seconda possibilità.
Diversi di loro contrassero un mutuo di rilevante entità per finanziare questo cambiamento. E assunsero anche un tizio chiamato Mort Rosenthal come direttore del marketing. Durò meno di un anno alla Infocom, facendosi licenziare per aver oltrepassato le proprie mansioni quando offrì i giochi della Infocom a Radio Shack con un ingente sconto pur di portarli in tutti i negozi della catena. Prima di allora però aveva fatto faville, e non solo nel marketing. Affarista di natura, secondo quanto racconta Stu Galley, egli riuscì ad assicurarsi: “un impianto di produzione in condivisione di tempo a Randolph, un’agenzia pubblicitaria a Watertown, un servizio di raccolta ordini in New Jersey, un fornitore di dischetti in California, e così via”, tutto nel giro di qualche settimana. Trovò anche il loro primo minuscolo ufficio sopra la storica Faneuil Hall Marketplace di Boston [“La Culla della Libertà”, in onore dei numerosi discorsi che vi sono stati tenuti da celebri indipendentisti americani; ndAncient]. I primi due dipendenti stipendiati che vi andarono a lavorare furono Berez, la principale mente affarista della società, e Marc Blanc, l’architetto della Z-Machine, che ormai da più di un anno aveva già lasciato il suo internato medico trasferendosi a Boston per far parte della rischiosa partita.
Mostrando un istinto del tutto sorprendente in un manipolo di hacker, la Infocom strinse un ultimo accordo con la Personal Software: avrebbe ricomprato le restanti copie di Zork, per impedire che esse inondassero il mercato a prezzi scontanti, svalutando così il marchio di Zork. Dovevano far uscire Zork II in tempo per Natale, e quindi lavorarono freneticamente al fianco della compagnia pubblicitaria, che Rosenthal aveva trovato, per dare un nuovo look alla serie. Lo stile che idearono era certamente molto più appropriato ed elegante del vecchio barbaro della Personal Software. E infatti ancora oggi è il “volto” ufficiale di Zork.
Ironicamente, per una società che produceva giochi testuali, il livello di raffinatezza visiva dei prodotti Infocom li contraddistingueva, già a partire dal logo classico dell’azienda, che debuttò già in questa occasione e che resterà un punto fermo per il resto della vita della società. Ma, parlando di testo, nelle pubblicità e nel packaging di Zork II troviamo già quel tono che i fan della Infocom impareranno a conoscere: un’atmosfera apparentemente casual e spiritosa, che però rifletteva un’immensa cura per i dettagli; il tutto in un’epoca dove la maggior parte dei publisher sembra non preoccuparsi nemmeno dell’ortografia dei suoi prodotti. Rispetto a tutti gli altri, la Infocom è sempre apparsa un po’ più di classe, un po’ più brillante, e un po’ più adulta. Ed è un'immagine che sicuramente gli ha giovato.
La prossima volta accetteremo l’invito qui sopra e ci tufferemo in Zork II, che riuscì per davvero a uscire in tempo per Natale.
The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto
Consulta l'indice per leggere gli articoli precedenti
Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!
The Ancient One
13/11/2019
Bentrovati fedeli lettori di OldGamesItalia e del Digital Antiquarian, vi siete mai chiesti come sia possibile giocare a Zork sui moderni computer e tablet? Nulla di più semplice: per prima cosa, come ogni avventuriero che si rispetti, munitevi di foglio e matita, poi scaricate la nostra epica traduzione di Zork, infine procuratevi un interprete di Z-Machine. La Z-Machine, ecco, è solo grazie alla mitica "Macchina Z" se Zork e la sua ricca eredità sono stati convertiti per una moltitudine di piattaforme e giocati da milioni di persone per decenni fino ai giorni nostri, un'impresa che nel 1979 era quasi impossibile... ma non per Joel Berez e Marc Blank L'Antiquario ci trasporta in quel delicato momento della storia di Infocom. La rassicurante lista degli articoli del ciclo Infocom: – Lo ZIL e la Z-Machine – Come Vendettero Zork – Giochi col Parser – Esplorando Zork, Parte 1 – Esplorando Zork, Parte 2 – Esplorando Zork, Parte 3 – Infocom: Come Cavarsela da Soli – Zork II, Parte 1 – Zork II, Parte 2 – Lo Zork User Group – Zork III, Parte 1 – Zork III, Parte 2 Buona lettura avventurieri... e non perdete la bussola! Festuceto |
Quando ci siamo lasciati l’ultima volta, Marc Blank e Joel Berez stavano valutando come portare Zork sui microcomputer. In realtà stavano cercando di risolvere tre problemi interconnessi. A costo di risultare pedante, lasciate che ve li riassuma:
1. Come portare Zork (un gioco enorme, che consumava 1 MB di memoria sul PDP-10) sui microcomputer di fascia più bassa che avevano selezionato: Apple II o TRS-80 con 32 K di RAM e un singolo floppy-disk.
2. Come farlo in modo che fosse facilmente convertibile per altre piattaforme, affinché fosse il più indolore possibile trasportare Zork non solo sull’Apple II e sul TRS-80, ma anche (se tutto fosse andato bene) sulle molte altre piattaforme incompatibili, presenti e future.
3. Come usare il codice sorgente esistente di Zork in MDL come base per una nuova versione per microcomputer, piuttosto che dover ripartire da zero e implementare da capo il gioco su un qualche nuovo ambiente di programmazione.
Volendo potete considerare questo elenco come una classifica di problemi in ordine di importanza, da “assolutamente essenziale” fino a “non sarebbe male”. Ma non è strettamente necessario, perché -come vedremo di qui a poco- Blank e Berez (col successivo aiuto degli altri) riuscirono a risolverli tutti in modo assolutamente brillante. Vorrei potermi occupare singolarmente di ognuno di questi problemi, ma (come sa chiunque si sia cimentato con delle complicate mansioni di programmazione) le soluzioni tendono a intrecciarsi l’una con l’altra. Quindi mi limiterò a chiedervi di tenere a mente questi tre obbiettivi, mentre io vi spiegherò come funzionava nel suo insieme il progetto di Blank e Berez.
Quando ci troviamo davanti a un gioco troppo grande per essere accomodato in un nuovo ambiente, la soluzione più ovvia sarebbe quella di rendere semplicemente il gioco più piccolo, rimuovendo dei contenuti. E questa è appunto una di quelle cose che la Infocom fece con Zork. Stu Galley:
| Dave esaminò la sua mappa completa di Zork e tracciò un confine intorno a una porzione della stessa che includeva circa 100 location: tutte le stanze all’aperto e un’ampia sezione intorno alla Round Room. Lo scopo era quello di creare uno Zork più piccolo, che rientrasse nei limiti fissati dal progetto di Joel e Marc. Tutto quello che restava fuori sarebbe stato messo da parte per un altro gioco, da realizzare in un altro momento. |
Dimezzando il mondo di Zork, la Infocom potette ridurre drasticamente le dimensioni del gioco. 191 stanze divennero 110; 211 oggetti divennero 117; 911 parole conosciute dal parser divennero 617. Non era la soluzione definitiva ai loro problemi, ma di certo aiutava, lasciandoli comunque con in mano un gioco enorme, delle dimensioni approssimative simili a quelle dell’originale Adventure come numero di stanze, ma capace comunque di annichilirlo in termini di oggetti e di parole, e che era comunque più grande di ogni altro gioco d’avventura per microcomputer. E, come spiega Galley qui sopra, li lasciava comunque in possesso di abbondante materiale con cui costruire un possibile seguito.
Altri risparmi potevano essere conseguiti spostando l’attenzione sul compilatore per MDL. Essendo un linguaggio progettato per eseguire molti compiti di computazione generici, molte delle capacità dell’MDL risultavano ovviamente inutilizzate in un gioco d’avventura come Zork. Ma, anche se inutilizzate, esse consumavano comunque memoria preziosa. La Infocom dette un paio di sforbiciate all’MDL, proprio come avevano fatto con il mondo di Zork, eliminando le librerie e la sintassi superflua, e tenendo solo ciò che era strettamente necessario per implementare un gioco d’avventura. Chiamarono il nuovo linguaggio ZIL (Zork Implementation Language [“Linguaggio per l’Implementazione di Zork”; ndAncient]), mentre il compilatore che attivava il linguaggio (che girava ancora su un PDP-1) lo chiamarono Zilch. Lo ZIL restò abbastanza simile, come sintassi e impostazione di base, all’MDL, tanto è vero che convertire Zork verso lo ZIL fu piuttosto indolore, ma nonostante ciò il nuovo linguaggio non solo produceva degli eseguibili più compatti e più veloci, ma era anche molto più pulito sintatticamente. Infatti lo ZIL incoraggiò la Infocom non solo a convertire Zork per il nuovo linguaggio, ma anche a migliorarlo da molti punti di vista; in particolare fu il parser che, implementato nel più congeniale ZIL, divenne ancora migliore.
Questa è la lanterna di Zork in MDL:
<OBJECT ["LAMP" "LANTE" "LIGHT"] ["BRASS"] "lamp" <+ ,OVISON ,TAKEBIT ,LIGHTBIT> LANTERN () (ODESCO "A battery-powered brass lantern is on the trophy case." ODESC1 "There is a brass lantern (battery-powered) here." OSIZE 15 OLINT [0 >])> |
E questo è il medesimo oggetto in ZIL:
<OBJECT LANTERN (LOC LIVING-ROOM) (SYNONYM LAMP LANTERN LIGHT) (ADJECTIVE BRASS) (DESC "brass lantern") (FLAGS TAKEBIT LIGHTBIT) (ACTION LANTERN-F) (FDESC "A battery-powered lantern is on the trophy case.") (LDESC "There is a brass lantern (battery-powered) here.") (SIZE 15)> |
Per i posteri darò una veloce spiegazione del codice ZIL mostrato qui sopra. La prima linea semplicemente ci dice che quel che segue descriverà un oggetto chiamato “lanterna”. La linea successiva ci dice che esso si trova nel soggiorno della casa bianca. Poi vediamo che il giocatore si può riferire a esso anche con i termini “lamp,” “lantern,” or “light,”, con l’aggettivo opzionale di “d’ottone” (che del resto può rivelarsi utile per distinguerla dalla lanterna rotta che si trova in un’altra zona del gioco). Quella che viene chiamata descrizione breve (e cioè, con maggior precisione, il nome col quale appare nell’inventario e in altri punti dove deve essere inserito nel testo) è “lanterna d’ottone”. Il flag TAKEBIT indica che è un oggetto che il giocatore può raccogliere e portare in giro con sé; il flag LIGHTBIT significa che proietta luce, illuminando qualunque stanza buia in cui viene lasciato o trasportato. LANTERN-F è la speciale routine d’azione della lanterna: un pezzo di codice che ci permette di scrivere delle “regole” speciali per la lanterna, che valgono solo per essa, come ad esempio le routine che permettono al giocatore di accenderla e di spegnerla (come ho spiegato in precedenza, questo livello di programmabilità e il conseguente approccio “orientato agli oggetti” era ciò che davvero contraddistingueva l’MDL -e di conseguenza lo ZIL- da tutti gli altri sistemi di sviluppo di avventure testuali dell’epoca). FDESC è la descrizione della lanterna che appare prima che essa sia spostata, e quindi come parte della descrizione della stanza del soggiorno; LDESC invece appare dopo che l’oggetto è stato spostato e depositato altrove. Per finire, SIZE determina le dimensioni e il peso della lanterna ai fini di stabilire quanto il personaggio possa trasportare con sé in un certo momento. Vi lascerò come esercizio quello di tradurre il più caotico codice per MDL...
E così a questo punto la Infocom aveva in gran parte risolto il problema n° 3 e aveva fatto dei grandi passi in avanti con il problema n° 1. Il che però li lasciava ancora con in mano il problema n° 2. Probabilmente state pensando che fosse abbastanza facile progettare un’accoppiata engine/database simile a quella ideata da Scott Adams. La verità però è che era assai problematico. Vi ricorderete infatti che una delle cose che rendevano unico l’ambiente di sviluppo di Zork (che fosse l’MDL o lo ZIL) era la sua programmabilità. Passare a una soluzione simile a quella di Adams avrebbe significato sacrificare proprio questo e, nel mezzo, anche lo ZIL. Perché lo ZIL funzionasse doveva poter eseguire del codice che gli consentisse di gestire le interazioni speciali (come, appunto, l’accensione e lo spegnimento della lanterna); doveva, in altre parole, essere un vero linguaggio di programmazione “Turing-complete” e non un mero sistema di inserimento dati. Ma come riuscirci senza rinunciare ad avere un sistema che fosse anche portabile da macchina a macchina (incompatibile)? La risposta: avrebbero ideato una macchina virtuale, un computer immaginario ottimizzato proprio per giocare alle avventure testuali (proprio come lo ZIL era ottimizzato per scriverle) e poi avrebbero scritto il codice di un interprete che avrebbe simulato quel computer su ogni piattaforma per cui avrebbero voluto pubblicare Zork.
Oggi le macchine virtuali sono ovunque. Le app del vostro smartphone Android in realtà girano dentro una virtual machine. Potete utilizzare qualcosa tipo VMWare sul vostro computer per utilizzare Linux dentro Windows, o viceversa. I grandi mainframe e, sempre di più, anche i server di fascia alta hanno sistemi operativi tipo Linux che funzionano all’interno di macchine virtuali astratte dal sottostante hardware; ciò, fra i vari benefici, permette anche di suddividere un unico gigantesco mainframe in tanti mainframe più piccoli. A parte gli scenari di questo tipo, le virtual machine sono così interessanti essenzialmente per due motivi; e virtualmente (ah!) chiunque decida di usarle lo fa per un motivo o per l’altro, o per entrambi. Innanzitutto sono molto più sicure. Se un codice malevolo (come un virus) viene introdotto in una macchina virtuale, rimane al suo interno, anziché infettare l’intero sistema che la ospita, e il codice che manda in crash la virtual machine (che lo faccia intenzionalmente o accidentalmente) in realtà manda in crash solo la virtual machine stessa, e non tutto il sistema che la ospita. La seconda cosa è che una virtual machine consente di eseguire lo stesso programma su macchine che sarebbero altrimenti incompatibili. È un caso di “scrivilo una volta e poi gira ovunque”, come erano soliti ripetere i sostenitori di Java. Nel loro caso, ogni piattaforma su cui doveva girare il programma in questione doveva solo essere dotata di un’implementazione aggiornata della virtual machine di Java (non necessariamente il linguaggio, anche solo la virtual machine). Le macchine virtuali hanno però anche un grosso svantaggio: poiché la piattaforma che le ospita sta emulando un altro computer, tendono a essere molto più lente dello stesso codice sorgente eseguito direttamente sulla propria piattaforma (lo so, tecnologie come la compilazione just-in-time possono fare molto per alleviare questo difetto, ma qui non è il caso di addentrarsi ulteriormente nell’argomento). Tuttavia oggi il potere computazionale è poco costoso e molto diffuso, e quindi questo in genere non è un grande problema. E infatti la situazione attuale può diventare a tratti anche abbastanza ridicola: la mia versione per Kindle di The King of Shreds and Patches è costruita su una virtual machine (Glulx) che viene eseguita dentro un’altra virtual machine (quella di Java), il tutto eseguito su un minuscolo lettore portatile... e nonostante questo le performance restano accettabili.
Già nel 1979 le virtual machine non erano un’idea nuova. Fra il 1965 e il 1967 un team dell’IBM aveva lavorato in stretto contatto con il Lincoln Laboratory del MIT per creare un sistema operativo chiamato CP-40, nel quale fino a 14 utenti potevano loggarsi all'interno di un proprio computer mono-utente, interamente simulato da un software eseguito su un grande mainframe della IBM. In seguito il CP-40 divenne la base del sistema operativo opportunamente chiamato VM, pubblicato per la prima volta dalla IBM nel 1972 e ancora oggi largamente usato sui mainframe odierni. Nel 1978 un’implementazione in Pascal, nota come UCSD Pascal introdusse la P-Machine, una macchina virtuale portatile che consentiva ai programmi scritti in UCSD Pascal di girare su molte macchine diverse, incluso perfino l’Apple II (in seguito alla pubblicazione dell’Apple Pascal nell’agosto del 1979). Proprio la P-Machine ebbe una grande influenza sulla virtual machine della Infocom, la Z-Machine.
Nell’optare per una virtual machine, dovettero ovviamente pagare (come con ogni altra virtual machine) la penalità in termini di performance, ma essa non era troppo severa come invece ci si aspetterebbe. Proprio come avevano ottimizzato lo ZIL, Blank e Berez resero infatti la Z-Machine il più leggera ed efficiente possibile, includendovi solo quelle caratteristiche davvero utili per eseguire un’avventura testuale. E poi avrebbero implementato l’interprete di ogni piattaforma solo in un linguaggio assembly altamente ottimizzato, col risultato che Zork (pur girando all’interno di una virtual machine) girava comunque molto, molto più velocemente delle tipiche avventure scritte in BASIC di quegli anni. E infatti il potere computazionale dei microcomputer, per quanto limitato, non era mai stato la loro preoccupazione principale durante la conversione di Zork: il vero collo di bottiglia era la memoria. Sì, avrebbero dovuto sacrificare della memoria aggiuntiva per l’interprete, ma ne avrebbero risparmiata ancora di più lavorando sull’efficienza della Z-Machine. Per esempio, una speciale codifica gli permetteva di immagazzinare la maggior parte dei caratteri in 5 bit invece che in 8 bit, e gli permetteva di rimpiazzare le parole più comunemente usate con delle loro abbreviazioni. Una tale compressione del testo era molto rilevante, specie se consideriamo che, dopotutto, è il testo che compone la maggior parte di un'avventura testuale. Con tali tecniche di compressione, insieme alle sforbiciate al gioco stesso e al linguaggio ZIL, finirono per avere un gioco di soli 77 K di dimensioni, senza ovviamente considerare l’interprete della macchina virtuale che era necessario per eseguirlo; quest’ultimo fu chiamato Zip (da non confondersi ovviamente con il formato di compressione dei file). Il file del gioco da 77 K, che la Infocom iniziò a chiamare “story file” [“file della storia”; ndAncient] è sostanzialmente uno "snapshot" della memoria della virtual machine.
Quando parliamo di capacità di immagazzinamento di un computer, in realtà stiamo parlando (confondendo così genitori e nonni di tutto il mondo) di due quantità separate: la capacità su disco e la capacità di memoria (RAM). Un Apple II poteva contenere 140 K su un singolo dischetto, mentre il TRS-80 in realtà faceva un po’ meglio con i suoi 180 K. E così ora la Infocom aveva un gioco che poteva essere comodamente alloggiato, insieme al suo necessario interprete, su un singolo dischetto. Il problema era la RAM: anche dimenticandoci il necessario interprete, 77 K non entrano in 32 K, per quanto ci si sforzi di ficcarceli. Oppure sì?
Non era la prima volta nemmeno in quegli anni che si sentiva usare il disco come una sorta di memoria secondaria, leggendo dei pezzetti di dati e trasferendoli nella RAM, per poi scartarli quando non erano più necessari. La Microsoft aveva usato proprio questa tecnica per infilare Adventure nei 32 K del TRS-80: ogni pezzo di testo, tutti immagazzinati in un file esterno al gioco stesso proprio come nel progetto originale di Crowther e Woods, veniva letto dal disco solo quando doveva andare a schermo. Tuttavia il sofisticato sistema orientato agli oggetti della Infocom mischiava necessariamente testo e codice, rendendo quantomeno poco pratico un tale approccio. Per questo Blank e Berez si spinsero un passo oltre: avendo già progettato una virtual machine, vi aggiunsero un’implementazione della memoria virtuale.
Anche il concetto di memoria virtuale non era nuovo, in generale, nel mondo dell’informatica. E infatti la memoria virtuale risale ancora più indietro nel tempo delle virtual machine, fino a uno dei primi supercomputer, sviluppato dalla University of Manchester e chiamato Atlas, che era stato ufficialmente commissionato nel 1962. In un sistema con memoria virtuale, ogni programma non ha un punto di vista “onesto” sulla memoria fisica del computer host. In sostanza gli viene data una mappa “idealizzata” della memoria, che potrebbe avere ben poco a che fare con il vero layout della RAM fisica del computer che lo ospita. Quando legge e scrive dei pezzi di questa mappa, l’host automaticamente traduce gli indirizzi virtuali in indirizzi reali dentro la sua memoria fisica, in modo trasparente. Ma perché mai fare una cosa del genere, specialmente se consideriamo che produce necessariamente uno spreco di risorse? Anche stavolta per due principali ragioni, entrambe le quali di solito si considerano applicabili solo a sistemi operativi multitasking (che ovviamente erano poco più di un sogno per i microcomputer del 1979 o del 1980). Per prima cosa, isolando la memoria di ciascun programma da quella di ogni altro (oltre che da quella del sistema operativo) la memoria virtuale si assicura che un programma non possa (per malizia o semplicemente a causa di bug) corrompersi e danneggiare altri programmi, se non addirittura far crashare l’intero sistema. Per seconda cosa, la memoria virtuale fornisce al computer una specie di “seconda spiaggia”, un’alternativa al semplice fallimento di sistema, qualora un programma (o più programmi) in esecuzione chiedessero più memoria fisica di quella concretamente disponibile. Quando ciò accade, il sistema operativo cerca nella propria memoria dei pezzi che non vengono usati spesso. A quel punto li archivia nella cache su disco, facendo così spazio nella RAM fisica per allocare la nuova richiesta. Quando si deve accedere nuovamente alle aree così archiviate nella cache, esse devono essere riportate nella RAM, possibilmente scambiandole con altri chunk, se la memoria è scarsa. Tutto ciò avviene in modo trasparente rispetto al programma (o ai programmi) in questione, che continuano a vivere all’interno del loro punto di vista idealizzato sulla memoria, gioiosamente ignari di quanto il sistema sottostante stia in realtà ansimando per tenere tutto in piedi. La memoria virtuale ormai è con noi da molti anni nel mondo dei PC desktop. In uno schema del genere c’è inevitabilmente un punto in cui il gioco non vale più la candela: se avete provato ad aprire tantissime finestre o programmi su un vecchio PC, avrete notato che tutto diventava terribilmente lento, mentre l’hard disk lavorava come un mulino; ecco, adesso sapete quello che stava succedendo dietro le quinte (sempre che non lo sapeste già; qui al The Digital Antiquarian non presupponiamo nessun livello di conoscenze tecniche nei nostri lettori).
Per la Z-Machine, Berez e Blank adoperarono una versione molto più semplice della memoria virtuale rispetto a quella che oggi troviamo in sistemi operativi come Windows, Linux, o OS X. E se certe importanti informazioni dinamiche (come la posizione attuale di oggetti all’interno del mondo di gioco) deve essere sempre tracciata e aggiornata dinamicamente, la gran parte dei dati che compongono un gioco come Zork è in realtà statica e non cambia nel tempo: tanto, tanto testo, ovviamente, mischiato a un bel po’ di codice. Berez e Blank riuscirono a progettare il compilatore ZIL in modo tale che esso collocasse tutta la roba che poteva realisticamente cambiare (e che noi chiameremo “dati dinamici”) all’inizio dello story file. Tutto il resto (che noi chiameremo “dati statici”) veniva dopo. Ebbene, dei 77 K dello story file di Zork, solo 18 K erano di dati dinamici. Ecco quello che fecero, quindi...
I dati dinamici (cioè la memoria in cui la virtual machine avrebbe scritto, oltre che letto) è sempre immagazzinata nella RAM del computer host. I dati statici tuttavia sono caricati e scaricati dalla RAM ad opera dell'interprete, secondo il bisogno, in blocchi di 1 K chiamati “page” [“pagine”; ndAncient]. In altre parole: dal punto di vista del gioco, esso ha 77 K di memoria con cui lavorare. L’interprete nel frattempo scambia freneticamente blocchi di memoria dentro e fuori dalla molto più limitata RAM fisica, per mantenere in piedi questa illusione. Come la virtual machine, anche la memoria virtuale porta ovviamente con sé un rallentamento, ma è un male necessario. Su un sistema a 32 K, con 18 K riservati ai dati dinamici, la Infocom aveva ancora 14 K liberi per ospitare al loro interno l’interprete della macchina virtuale, un piccolo “stack” (cioè un’area dove i programmi immagazzinano le informazioni temporanee di cui hanno bisogno per il “moment-to-moment processing”) e una “page” o due di memoria virtuale. Certo alle volte poteva rallentare vistosamente, ma funzionava. E, quando veniva avviato su un sistema con, ad esempio, 48 K, l’interprete se ne accorgeva automaticamente e usava questa memoria addizionale per tenere più dati statici nella RAM fisica, velocizzando così il tutto e ripagando l’utente per il suo investimento nell’hardware.
Con l’impianto ZIL / Z-Machine, la Infocom aveva creato un sistema, robusto e riutilizzabile, che avrebbe potuto godere di vita propria ben al di là del compito specifico di infilare Zork sul TRS-80 e sull’Apple II. Sono certo di non spoilerare niente a nessuno, se vi svelo già adesso che ciò è esattamente ciò che accadde.
Forti di tali fondamenta tecniche, la prossima volta osserveremo il percorso che portò infine Zork sul mercato.
The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto
Consulta l'indice per leggere gli articoli precedenti
Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!
The Ancient One
04/11/2019
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!
The Ancient One
19/02/2018
Abbiamo lasciato Scott Adams alla fine del 1979, impegnato a spingere tutta questa cosa delle avventure al proverbiale “livello successivo”, con un solido catalogo di titoli già disponibili per numerose piattaforme, con il nome più noto di tutta la nascente industria dei giochi per computer, e con una società nuova di zecca (la Adventure International), pronta a pubblicare le opere sue, e quelle di altri, sotto il suo marchio editoriale. L’anno successivo lo vide quindi impegnato a mettere a frutto tutto quel potenziale, e anche di più, per andare così ad occupare un posto di primissimo piano nella nascente industria.
La Adventure International negli anni successivi crebbe a passi da gigante, pur restando (come del resto ogni altra cosa toccata da Adams) indelebilmente marchiata dalla personalità del suo fondatore. I suoi cataloghi erano pieni di un’accozzaglia di software di ogni genere. La Adventure International in un certo senso era i Grandi Magazzini dell’industria del software. Oltre alle prevedibili avventure testuali scritte da Adams e da altri (e molte di queste usavano comunque l’engine di Adams), c’erano dei cloni dei titoli da sala giochi (“di gran lunga superiore a ogni altro gioco per il TRS-80 ispirato a Space Invader pubblicato fin qui”, recitava una pubblicità di Invaders Plus, facendo sfoggio più di onestà che di saggezza legale), giochi di strategia spaziale (Galactic Empire e Galactic Trader), programmi di scacchi (“anche se è disponibile una scacchiera visualizzata su schermo, per giocare si consiglia di munirsi di una vera scacchiera.”), adattamenti di giochi da tavolo (Micropoly, anche lui talmente avventato da pubblicizzarsi come un clone del Monopoli già dal testo promozionale), e perfino TRS-80 Opera, che consentiva di ascoltare la ouverture del Guglielmo Tell di Rossini attraverso una radio a transistor posizionata i prossimità del lettore di cassette della macchina (la mancanza di un’adeguata protezione dalle interferenze radio sul TRS-80 non era poi sempre così negativa, dunque…). E, per quando il tempo dello svago era finito, c’erano anche programmi di matematica, spooler di stampa, strumenti per programmare, programmi di disegno, e software educativo (quest’ultimo ovviamente presentava la solita passione per gli Stati e le loro capitali, così comune fra i primi programmatori). Tutto questo software era relativamente poco costoso (solitamente era prezzato $9.95 o $14.95) e di qualità… variabile. E, pur tuttavia, era emozionante camminare per le corsie virtuali dei cataloghi della Adventure International, osservando gli espositori stracolmi dei prodotti di una nuova industria in espansione e chiedendosi quali altre idee pazze (per non dire bislacche) avremmo trovato nella corsia successiva. E, ad aleggiare su tutta questa scena, c’era sempre la personalità straripante di Adams, che sarebbe rimasto per tutta la vita breve ma intensa della Adventure International un capo d’azienda insolitamente visibile (e infatti -leggendo le scritte legali in piccolo sui suoi prodotti- si scopre che la Adventure International in realtà era solo “una divisione della Scott Adams Inc.”).
Il 1980 rappresenta un momento cruciale per l’industria del software d’intrattenimento. A parte un paio di eccezioni tipo Microsoft e Automated Simulations, i giochi per computer fino ad allora erano stati distribuiti come prodotti secondari, per mano di soggetti non professionisti che si limitavano ad appendere le loro Ziploc nei negozi di computer locali e che al massimo aderivano ai servizi di distribuzione per hobbisti (tipo quelli delle riviste SoftSide e Creative Computing). Ora invece le compagnie come la Adventure International, e altre che iniziavano ad apparire più o meno contemporaneamente, iniziarono a rendere più professionale il settore. Nel giro di pochi anni i sacchetti Ziploc sarebbero stati sostituiti da dei massicci cartonati colorati, pieni di manuali patinati e altri gadget, e quei “soggetti non professionisti” con gli uffici in camera o in casa sarebbero stati sostituiti da veri studi di sviluppo i cui membri facevano quello di lavoro. I giochi per computer stavano diventando un business vero e proprio, attirando sulla scena più risorse, che presto avrebbero permesso creazioni più grandi e ambiziose di qualunque cosa si fosse vista fino ad allora, ma che al tempo stesso avrebbero complicato le cose e avrebbero inevitabilmente condotto a quella tipica perdita di innocenza che sempre consegue alla monetizzazione di una passione.
Alla luce della crescita esplosiva della sua compagnia, non sorprende che la creazione di nuove avventure da parte di Adams avesse subito un drammatico rallentamento. Una parte delle sue energie furono assorbite -e nemmeno questa sarebbe stata l’ultima volta che ciò sarebbe avvenuto!- con la ripubblicazione dei suoi giochi già esistenti. Tutti ricevettero delle illustrazioni di copertina fatte a penna e acquerello grazie a un artista noto solo come “Peppy”, il cui stile colorato, seppur poco rifinito, si adattava perfettamente al folle entusiasmo della prosa di Adams.
Nel 1980 la Adventure International pubblico solo due nuove avventure scritte da Adams: la parodia western chiamata Ghost Town a primavera e Savage Island Part One (prima parte di due) a Natale, un'avventura che fu pubblicizzata come abbastanza difficile da risultare impegnativa anche per i giocatori più hardcore fra i giocatori hardcore.
Ho ritenuto di dare un’occhiata più approfondita alla prima di queste due, per vedere quali progressi avesse fatto l’arte di Adams dopo The Count. La risposta, triste ma semplice, è: nessun progresso, davvero. Anzi, ci sono state delle involuzioni da molti punti di vista. L’ambientazione western era evidentemente solo l’ennesima in una lista di generi che Adams intendeva coprire, visto che essa contribuisce ben poco a dare forma all’esperienza di gioco. Ghost Town è una caccia al tesoro senza trama, proprio come Adventureland; come se The Count non ci fosse mai stato: “DROP TRESURES”, e poi “SCORE.” Sigh.
“LASCIA TESORO e poi PUNTEGGIO”
Derubiamo il saloon degli incassi semplicemente perché ci sono.
Doppio-sigh.
———-> Cosa devo fare?
“VAI AL BANCONE”
OK
“Sono dietro al bancone. Oggetti visibili
Cartello - ‘Suona il campanello per il servizio in camera’
———-> Cosa devo fare?
“PRENDI CASSETTA DEI SOLDI”
OK
———-> Cosa devo fare?
“GUARDA CASSETTA DEI SOLDI”
OK
Vedo
Niente di speciale
Quel che è peggio è che anche come caccia al tesoro Ghost Town non è né divertente, né soddisfacente. Se si escludono un paio di battute (tipo la risposta a VAI SPECCHIO - “Non sono Alice!”), Ghost Town ha perso un po’ di quel calore amichevole che un po’ ci faceva perdonare le incertezze dei primi giochi. L’utile comando HELP, con i suoi velati suggerimenti, è sparito del tutto, mentre gli enigmi sono involuti in una variegata raccolta di peccati di design. Adams ha lentamente fatto impennare la difficoltà dei suoi giochi con ogni titolo successivo che ha scritto, come se si aspettasse che il giocatore li affrontasse in sequenza e arrivasse quindi ben preparato a Ghost Town. Presumo che in astratto possa anche essere un approccio ragionevole, ma nella realtà nessuna preparazione è possibile per gli enigmi di Ghost Town. Perfino quelli meno discutibili richiedono comunque una notevole dose di conoscenze esterne, tipo la composizione della polvere da sparo o la capacità di tradurre il codice morse.
Sono in un ufficio del telegrafo. Oggetti visibili:
Chiave del telegrafo, filo sbucciato. Grossa cassaforte.
Uscite evidenti: SUD
———-> Cosa devo fare? SCRIVI
Non so come “SCRIVERE”.
———-> Cosa devo fare? PREMI TASTO
Click
SPARK! * * * *
… …. .- -.- - - --- .--. .--. . .--.
Inutile dire che nel 1980, quando ancora Wikipedia non era a un click di distanza da noi, questo genere di cose poteva richiedere una spedizione in biblioteca. Altri enigmi invece ci richiedono di visualizzare la stanza in questione esattamente come Adams se l’era raffigurata, nonostante le sue celeberrime descrizioni minimali, solitamente limitate all'elenco degli oggetti all’interno.
Altri ancora ricompensano invece la cieca caparbietà del giocatore, piuttosto che le sue intuizioni, come quello che ci costringe a trascinarci un badile per tutta la mappa, provando a scavare in ogni singola stanza sperando che sbuchi fuori qualcosa. E poi ancora -forse il peggiore di tutti- vanno menzionate le infinite battaglie con il parser. Non voglio nemmeno pensare a quanto tempo potrebbe servire al giocatore medio per intuire che per far muovere il cavallo deve dire GIDYUP. Né voglio pensare a quante volte siano stati mischiati inutilmente insieme carbone, zolfo, e nitrato di potassio prima di aver finalmente scritto FAI POLVERE DA SPARO. A volte il parser sembra non solo tecnicamente limitato, ma anche volutamente crudele!
Sono in una merceria. Oggetti visibili:
Ferro di cavallo. Grande campanella. *PROIETTILE D'ARGENTO* *DERRINGER D'ORO* Cartello. *SPERONI D'ARGENTO*. Cappello da Cowboy. Chiave piccola. Barilotto di polvere da sparo. Chiodi. Martello.
Uscite evidenti: NORD
———-> Cosa devo fare? RIEMPI BARILOTTO
OK
con cosa?
———-> Cosa devo fare? CON POLVERE DA SPARO
Scrivere solo POLVERE DA SPARO, invece che CON POLVERE DA SPARO al prompt di cui sopra restituisce un messaggio d'errore generico.
La mia esperienza con Ghost Town rafforza sempre di più in me l'idea che questi primissimi giochi erano semplicemente troppo limitati tecnologicamente per poter supportare degli enigmi complessi che fossero al tempo stesso anche equi e affrontabili con la logica, col risultato che -volendone aumentare la difficoltà oltre una certa soglia molto bassa- si ricadeva inevitabilmente in assurdità, che infatti abbondano in Ghost Town e nel finale di Adventure.
È forte la tentazione di concludere che Adams semplicemente non avesse quella visione che sarebbe stata necessaria per poter spingere ancora oltre le avventure testuali. È una tentazione, ma probabilmente non sarebbe corretto. Per un paio di anni Adams tenne una rubrica sulla rivista SoftSide. Nel novembre del 1980 annunciò che aveva in progetto un nuovo sistema per avventure testuali chiamato Odyssey, che si sarebbe avvantaggiato dei sistemi dotati di floppy drive nello stesso modo utilizzato da Microsoft Adventure, e cioè utilizzando lo spazio sui dischetti come memoria ausiliare. I suoi progetti erano a dir poco ambiziosi:
“1. A ogni 'Odyssey' potranno partecipare più giocatori contemporaneamente. E ogni giocatore potrà aiutare o ostacolare, come meglio crede!
2. Frasi complete, invece del solito "linguaggio da bambini". Ad esempio: "Metti gli zoccoli al cavallo con il ferro da cavallo e il martello e i chiodi."
3. Messaggi di risposta più lunghi.
4. Effetti sonori
5. Trame più ampie.
Per sviluppare questo sistema in realtà ho dovuto prima sviluppare un nuovo linguaggio per computer che ho chiamato OIL ('Odyssey Interpretive Language'), che viene implementato da uno speciale assembler Odyssey, che genera il codice macchina per Odyssey. Questo codice macchina viene poi implementato su ognuno dei diversi microcomputer (es. Apple, TRS-80, ecc.) attraverso uno speciale emulatore host che simula il mio (inesistente) computer Odyssey.
Attualmente (scrivo dal Washington Computer Show, ed è il Settembre del 1980) il sistema è nelle fasi finali di implementazione dell'emulatore host su un TRS-80 32 K a dischetti, e sto già scrivendo la prima 'Odyssey' (che ho già abbozzato e che è provvisoriamente intitolata Martian Odyssey) in OIL proprio per tale emulatore. Spero che quando voi starete leggendo queste righe, Odyssey Number One sia già disponibile nel vostro negozio di fiducia o nel catalogo del vostro servizio di acquisti per posta preferito."
Il concetto tecnico dietro Odyssey è incredibilmente simile a quello che sarebbe stato utilizzato di lì a poco da una minuscola startup del Massachusetts chiamata Infocom. È però interessante notare che Marc Blank e Stu Galley della Infocom avevano già delineato in astratto le basi della loro virtual machine, la “Z-Machine”, in un articolo su Creative Computing [Il link non è più attivo, pertanto non è stato possibile recuperare l'articolo] giusto un paio di mesi prima che Adams scrivesse queste righe. Che sia stato ispirato proprio da quell'articolo?
Quale che sia la risposta, Martian Odyssey non ha mai fatto la sua apparizione sulle scene e -per quanto ne so- Adams non ha mai più parlato del suo sistema Odyssey. Nel bene o (decisamente) nel male, Adams scelse di restare fedele a ciò che lo aveva portato fin lì: cacce al tesoro giocabili su computer di fascia bassa a 16 K equipaggiati solo con lettori di cassette.
Tale strategia rimase profittevole per qualche altro anno ancora, ma è difficile oggi non chiedersi dove lo avrebbe portato la strada che scelsce di non intraprendere, il territorio che cedette senza combattere alla Infocom e agli altri. Dal 1980 in poi, Adams è più interessante come uomo d'affari e come facilitatore delle opere altrui, che come artista di software vero e proprio. Al riguardo, la prossima volta vi voglio parlare un po' di qualche altra creazione interessante che affiancava le avventure di Adams nel guazzabuglio del catalogo della Adventure International.
Se volete provare Ghost Town, ecco qui una versione [Il link non è più attivo, per cui non è attualmente possibile reperire il file] che potete caricare nell'emulatore MESS utilizzando la funzione “Devices -> Quickload”.
The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.
Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto
Articoli precedenti:
- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80
- Eliza
- Adventureland
- Dog Star Adventure
- Qualche domanda per Lance Micklus
- Un 1979 indaffarato
- The Count
- Due diverse culture di avventurieri
- Microsoft Adventure
- La Narrativa Ludica già nota come Storygame
- L'Ascesa dei Giochi Esperienziali
- Dungeons And Dragons
- Una Definizione per i Giochi di Ruolo per Computer
- Dal Tavolo al Computer
- I Primi Giochi di Ruolo per Computer
- Temple of Apshai
Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!
The Ancient One
12/01/2015
Moonmist è un'avventura testuale della Infocom, scritta da Stu Galley (autore anche del più celebre Witness e co-autore di Seastalker insieme a Jim Lawrence) e classificata quanto a difficoltà come "Intro".
Questa IF trae il "mood" e l'ambientazione dai romanzi di paura e di investigazione per bambini tipici degli anni '80. Le vicende narrate si svolgono interamente, in una notte di luna piena, all'interno di un castello della Cornovaglia a picco su una scogliera.
Il castello, con i suoi molteplici passaggi segreti, è riprodotto abbastanza bene e la sua prima esplorazione è abbastanza piacevole e non richiede una mappatura vera e propria da parte del giocatore, il quale può anche fare affidamento sulla planimetria contenuta nell'opuscolo per turisti contenuto nella confezione originale del gioco.
Sempre nell'opuscolo si trovano anche delle descrizioni integrative delle varie sale del castello. Questo è invece meno gradevole, perché costringe il giocatore a staccarsi dallo schermo e avere sempre a portata di mano l'opuscolo, giacché queste descrizioni aggiuntive talvolta si rivelano essenziali per terminare il gioco. Scelta discutibile.
L'avventura si compone sostanzialmente di due missioni, da portare avanti congiuntamente: una caccia al tesoro con 5 indizi e un'investigazione su un omicidio, che è poi il motivo della nostra presenza nel castello e che inizialmente presenta tratti soprannaturali.
L'elemento che più di ogni altro contraddistingue questo Moonmist è il fatto di contenere quattro storie diverse. All'inizio della partita ci viene chiesto di dichiarare il nostro colore preferito e, sulla base della nostra inconsapevole scelta, il gioco seleziona una delle quattro storie. Concretamente parlando ci sono 4 diverse caccie al tesoro (ognuna con 5 indizi divesi) e 4 diverse investigazioni (ognuno con prove e colpevoli diversi). Ognuna di queste quattro storie ha in comune i protagonisti (gli ospiti del castello) e la location (il "Tresyllian Castle") in cui cercare il tesoro e gli indizi dell'investigazione.
Sulla carta sembra un'ottima idea, capace anche di garantire un elevato tasso di rigiocabilità, ma per me si è rivelata un fallimento.
L'idea delle quattro storie è realizzata tecnicamente in modo perfetto, come da tradizione Infocom, però la verità è che non risulta divertente. Questo perché:
- Si è costretti ogni volta a esplorare da capo il castello, cosa che risulta noiosa già alla seconda storia.
- C'è poi il rischio -concretissimo!- che nel corso dell'esplorazione si scopra un indizio successivo a quello che si stava cercando (vanificando così il senso di sfida e la gratificazione del giocatore) o, peggio ancora, che si scopra involontariamente un nascondiglio che sarà utilizzato in una delle altre tre storie. A me sono capitate più volte entrambe le cose; figuratevi che nella mia prima partita ho (del tutto involontariamente, ma con estrema facilità) scoperto il tesoro mentre stavo ancora cercando il primo indizio! Inutile dire che questo mi ha completamente tolto la voglia di continuare e così ho abbandonato il gioco dopo aver provato solo due delle quattro storie.
- Gli indizi delle quattro caccie al tesoro sono tutti tematici. Quelle cho ho provato io erano a tema biblico e a tema Edgar Allan Poe. Tematiche per me poco appassionanti ma, soprattutto, oggettivamente prive di una qualsiasi connessione con la storia che si sta narrando. E, aggiungo, prive anche di qualsiasi connessione con le premesse del gioco e con i suoi feelies.
- Più in generale, sia la caccia al tesoro che l'investigazione hanno sfumature infantili (da racconto di paura per bambini, appunto), che non mi hanno proprio appassionato. Sembra un gioco pensato per adolescenti, ma con una difficoltà da adulti (tanto più per gli standard odierni). Un contrasto fra il mezzo e la storia per me insanabile e cha rovinato la mia esperienza di gioco.
Anche i "feelies" per me sono abbastanza deludenti e testimoniano un prodotto che manca di una vera e propria anima.
Stavolta abbiamo: un opuscolo turistico del castello, un libro di storie di fantasmi con delle belle illustrazioni (ma che non ha alcuna relazione con la stroia dell'avventura) e un triste adesivo da stirare su una t-shirt.
Resta qualcosa di buono?
Non molto.
Di certo si possono salvare la qualità tecnica dell'avventura, la qualità della scrittura, i personaggi numerosi e ben caratterizzati (per quanto volutamente un po' stereotipati), nonché l'ambientazione notturna nel castello con i suoi tanti segreti.
La verità però è che, prima di ogni cosa, il gioco non ha saputo stupirmi, né coinvolgermi, né divertirmi fino in fondo. E per un avventura testuale non c'è niente di peggio.
Il gioco potrà forse risultare leggermente più allettante per chi è in cerca di avventure testuali classiche per principianti, anche se costui farebbe forse meglio a rivolgersi alle altre IF introduttive dell'abbondante catalogo Infocom (Wishbringer, Seastalker e Plundered Hearts) o alle tante produzioni amatoriali più recenti.
The Ancient One
06/03/2014
Seastalker è un'avventura testuale della Infocom, scritta a quattro mani da Stu Galley (autore anche di Moonmist e Witness) e da Jim Lawrence (coautore di Moonmist e ghost writer di numerosi libri per ragazzi, fra cui anche Nancy Drew).
TRAMA E AMBIENTAZIONE:
L'ambientazione di Seastalker è lievemente fantascientifica, collocata in un mondo solo un po' più tecnologicamente avanzato del nostro. Il gioco si svolge nelle profondità del mare, con un vago ma piacevole sapore diVentimila Leghe Sotto i Mari.
Seastalker ci vede impersonare uno scienziato, di cui possiamo scegliere il nome, a capo di un centro ricerche sottomarino. Accompagnati dal nostro compagno e collega Tip Randall (al nostro fianco per tutta l'avventura - chi ha detto Floyd?!?), sventeremo la minaccia rappresentata dallo Snark, un colossale mostro marino che mette a repentaglio l'incolumità della nostra base sottomarina. Per riuscire nell'impresa dovremo servirci della nostra ultima invenzione: un modernissimo sommergibile, battezzato SCIMITAR.
Nel farlo non mancheranno ovviamente i colpi di scena e i risvolti imprevisti, che coinvolgeranno anche gli altri membri della nostra folto staff scientifico e che ci daranno così l'occasione di calarci nei panni di un improvvisato investigatore.
GAMEPLAY:
Il gioco si svolge quasi per intero in due diversi tipi di ambienti: all'interno di basi scientifiche (una a terra e l'altra sottomarina) e in mare aperto (a bordo del nostro SCIMITAR).
Nella basi ci troveremo ad interagire con i vari PNG e a svolgere indagini di tipo prevalentemente investigativo, in modo non dissimile da tante altre avventure testuali.
Le fasi a bordo del sottomarino invece si basano prevalentemente sull'interazione con la variegata strumentazione di bordo. Questa è, probabilmente, la parte più interessante e originale del gioco.
Ogni strumento del sottomarino è descritto con cura nel manuale del gioco, assolutamente indispensabile per poter manovrare il sottomarino. Per fortuna il tutto ha il giusto livello di complessità e ricorrere al manuale è un divertimento e non una frustrazione (no, non è il manuale di Falcon 3.0...).
C'è da aggiungere anche che le varie strumentazioni di bordo vengono introdotte gradualmente, con una curva di apprendimento ben bilanciata.
Come in un vero sommergibile, ci si orienterà usando il sonar (che rivela, su una griglia realizzata in caratteri ASCII, gli ostacoli che si trovano intorno a noi e alla nostra stessa profondità) e il misuratore di profondità (che inizia a lampeggiare quando siamo troppo vicini al fondale). Il giocatore, per poter raggiungere la propria meta, dovrà quindi incrociare ripetutamente i miseri (ma realistici!) dati forniti da tali strumentazioni di bordo con la cartina del fondale inclusa nella confezione.
Vi garantisco che il risultato è una sfida estremamente gratificante, non difficile, ma originale e tutt'altro che banale.
L'altro aspetto centrale del gameplay è rappresentato da numerosi eventi a tempo, che uno non si immaginerebbe mai di trovare in un gioco etichettato come "Junior". Sappiamo fin dall'inizio che la base sottomarina è minacciata e che la nostra missione dovrà avere tempi strettissimi, ma... non sappiamo quanto stretti. E ogni nostra azione sposterà in avanti di uno il contatore dei turni di gioco, facendoci avvicinare inesorabilmente alla distruzione della nostra cara base.
La sensazione di urgenza è poi acuita da tutta una serie di scelte da compiere che sono strettamente legate al fattore tempo. Per esempio: si sa che la SCIMITAR non è stata ancora testata a dovere; sarà davvero opportuno spingerla al massimo della sua velocità per risparmiare una trentina di turni? O sarà forse meglio andare piano, ma senza sforzare il motore?
L'altro aspetto interessante, indirettamente legato al fattore tempo, è la presenza di tutta una serie di azioni secondarie facoltative. Si può infatti terminare il gioco in maniera favorevole ma senza aver scoperto tutti i risvolti della trama. Questo aggiunge anche un certo fattore di rigiocabilità. E, nel mio caso, la seconda partita mi ha permesso (raggiungendo anche i 100 punti su 100) di scoprire tutti quegli indizi che, nella prima partita, mi ero perso e che hanno dato un maggior senso agli eventi narrati.
DIFFICOLTA'
Seastalker è l'unico titolo Infocom a essere classificato come "Junior". Infatti le altre AT della Infocom per principianti (Wishbringer, Moonmist e Plundered Hearts) sono tutte classificate come "Novice".
Il ridotto livello di difficoltà rende questo Seastalker particolarmente interessante per chi sta muovendo i primi passi nel genere... Non aspettatevi però un gioco che si gioca da solo! La strumentazione del sottomarino da imparare a usare, i rigidissimi limiti temporali e i numerosi risvolti nascosti della trama conferiscono al titolo un livello di sfida dignitoso.
Non vi terrà impegnati per mesi (come potrebbe fare uno Zork), anzi al massimo per un paio di serate. Ma quelle saranno sufficientemente impegnative da rappresentare una sfida appagante.
Scendendo nel dettaglio, dirò che il ridotto livello di difficoltà si concretizza sopratutto in alcuni aspetti:
- un numero di location assai ridotto, navigabili facendo affidamento anche esclusivamente sulle planimetrie allegate al gioco e quindi senza bisogno di crearsi la propria mappa cartacea;
- i tanti enigmi (es. tutta la parte della navigazione con il sommergibile) che consistono quasi esclusivamente nell'applicazione delle istruzioni contenute nel manuale di gioco;
- l'abbondanza di indizi che ci vengono suggeriti dentro il gioco direttamente dai vari PNG (ma, per avere questi indizi, si deve comunque imparare ad interagire con loro!).
- alcuni di questi indizi in-game sono talmente espliciti che è stato adottato un sistema di spoiler, per non renderli "obbligatori". In pratica in questi casi il gioco ci fornisce una parola chiave che va a completare una frase (altrimenti incomprensibile) contenuta nella confezione del gioco. Qualcosa del tipo: "leggi l'indizio n°5 e nel relativo spazio vuoto inserisci la parola: SCIMITAR".
CURIOSITA'
- Seastalker è il primo gioco Infocom (il secondo sarà il già citato Moonmist) a consentire al giocatore di dare un nome al protagonista. La curiosità è che il nome andrà a completare il sottotitolo del gioco, il che fa di Seastalker il primo gioco dal titolo... interattivo!
- La mappa in caratteri ASCII del sonarscope è (credo) l'unico esempio di mappa in-game di un gioco Infocom. Se a questo aggiungiamo che essa si aggiorna, turno dopo turno, in base agli spostamenti del sottomarino, è l'ennesima dimostrazione di quanto sia potente il parser della Infocom.
CONCLUSIONI
Seastalker non è l'avventura più bella della Infocom, ma questo già lo sapevate.
Tuttavia è una buona avventura, impreziosita da qualche spunto originale. A parere del sottoscritto essa raggiunge sicuramente la sufficienza ed è sicuramente consigliata a chi muove i primi passi nel fantastico mondo della narrativa interattiva.
Credo che, insieme a Wishbringer, questo sia il titolo del catalogo Infocom migliore con cui iniziare. Sugli altri due giochi per principianti (Moonmist e Pludered Hearts) ho invece alcune riserve sui cui è inutile dilungarsi in questa sede.
Segnalo infini che il gioco oggi è facilmente reperibile e perfettamente emulato su iOS (con tanto di supporto per il GameCenter) tramite l'app Lost Treasures of Infocom di Activision.
Consigliata.
Il sito di OldGamesItalia è attualmente "in letargo". Nuovi contenuti saranno aggiunti con minore regolarità e con possibili lunghe pause tra un articolo e l'altro.
Il forum rimane attivo, ma meno legato al sito, e gli aggiornamenti riguarderanno principalmente le sezioni di IF Italia e della versione italiana del Digital Antiquarian e del CRPG Addict.
Grazie a chi ci è stato vicino nei vent'anni di attività "regolare" di OldGamesItalia, a chi ha collaborato o a chi ci ha soltanto consultati per scoprire il mondo del retrogaming. Speriamo di avere presto nuove energie per riprendere un discorso che non vogliamo davvero interrompere.
Grazie, OGI. Arrivederci!
- [Traduzione] Gobliiins 4
- [Recensione] Wasteland 3
- [Podcast] CV 2x05 - C'era una volta Wasteland
- [Podcast] CV 2x04 - C'era una volta Wing Commander 3/4
- [Podcast] CV 2x03 - C'era una volta Baldur's Gate II
- Ogni volta che provo a
4 giorni 21 ore fa - Bellissima traduzione, quasi
6 giorni 14 ore fa - Fallout 2 Traduzione
6 settimane 2 giorni fa - h
9 settimane 5 giorni fa - How to translate the game
11 settimane 1 giorno fa