IF ITALIA - Il sito Italiano sull'Interactive Fiction
ZORK
La magia è reale? Le spade si illuminano se il nemico è vicino? Nel
demoniaco mondo di Zork, un universo simulato stuzzica il giocatore con un
nuovo modo di risolvere i problemi. Oltre questa indefinita cucina, sopra e sotto la superficie della terra,
si trovano delle stanze, alcune contengono trappole, altre contengono
enigmi. Centinaia di oggetti sono sparsi per questo labirinto, alcuni
tesori preziosi, alcuni strumenti magici. La piccola casa bianca nella
foresta è chiaramente l'ingresso a Zork, un gioco sviluppato dagli autori.
Zork è un esempio di un nuovo tipo di gioco: il gioco di Simulazione
Fantasy Computerizzata. In questo tipo di gioco, il giocatore interagisce in modo discorsivo con un
onnisciente "Master del Dungeon", che regola su ogni azione proposta e
racconta le conseguenze. Se il giocatore dice "Vai a nord", potrebbe
muoversi a nord, o il dungeon master potrebbe dire "Non ci sono modi per
andare in quella direzione". Se il giocatore dice "Apri la finestra", il
dungeon master può rispondere "La finestra è chiusa a chiave". I risultati
dipendono dal disegno del gioco, dalla sua architettura e dal suo
arredamento, per così dire: in un gioco prendere una spada potrebbe essere
fatale, in un altro potrebbe conferire poteri magici. Il disegno e
l'implementazione di questo genere di giochi è sia un esercizio di
scrittura creativa che di programmazione. L'interesse nello giocare a Zork (o ad ogni altro gioco SFC) è a due facce.
Prima di tutto l'obiettivo del gioco è, di solito, quello di collezionare
tesori, e questo può essere fatto solo risolvendo i problemi; nell'esempio
precedente il giocatore raccoglie 10 punti essendo abbastanza intelligente
da aprire la finestra ed entrare nella casa. (Zork stesso ha più di due
dozzine di problemi diversi da risolvere, alcuni presentati in stadi
differenti). Secondo, un bel po' del divertimento di questi giochi deriva
dall'esplorare le loro risposte in una sorta di test di Turing informale:
"Chissà che cosa dice se faccio questo?" I giocatori (e i designer) si
divertono con le risposte intelligenti (o inaspettate) ad azioni altrimenti
inutili. Un'occhiata: simulare l'universo Il cuore di ogni SFC è la sua abilità nel simulare l'onniscienza. Con
questo intendiamo dire che il gioco deve simulare il mondo reale
sufficientemente bene da consentire al giocatore di spendendere la maggior
parte del suo tempo nel cercare di risolvere i problemi invece di risolvere
il programma. Se, ad esempio, il vocabolario è troppo limitato, il
giocatore deve sempre domandarsi se il suo problema è quello che non ha
ancora trovato la parola giusta da usare. Analogamente è fastidioso se una
possibile soluzione ad un problema viene ignorata dal gioco. In altre
parole, il programma deve simulare il mondo reale. Ovviamente nessun piccolo computer può contenere l'intero universo. Quello
che può fare, comunque, è simulare abbastanza universo da apparire più
intelligente di quanto in realtà sia. Questa è una strategia vincente solo
perché i giochi SFC sono diretti ad uno scopo. Come conseguenza, la maggior
parte dei giocatori prova solo un ristretto insieme delle cose che farebbe
con un oggetto se ne fosse in possesso veramente. Zork "simula l'universo" in un ambiente che contiene 191 "stanze" (posti in
cui essere) e 211 "oggetti". Il vocabolario comprende 908 parole, di cui 71
sono differenti "azioni" che è in grado di gestire. D'altra parte il
vocabolario colloquiale di una persona è più grande di un fattore di due (o
più). Come fa, allora, un programma limitato a mostrare quella
conversazione credibile che caratterizza Zork? La tecnica che Zork usa per simulare l'universo è quella dei metodi
universali modificati per situazioni particolari. Ad esempio, quando un
giocatore cerca di prendere qualche oggetto, si aspetta di entrarne in
possesso. Ci sono, come nel mondo reale, delle eccezioni: alcuni oggetti
sono "inchiodati", e la capacità di trasporto è limitata. Queste
restrizioni sono incluse nella funzione generale PRENDI. Comunque, il
designer potrebbe volere un'azione speciale da aggiungere, o da sostituire,
al PRENDI generale: un coltello potrebbe emanare una luce accecante quando
preso; cercare di prendere qualcosa in un tempio potrebbe essere fatale.
Queste eccezioni non saranno presenti nella funzione generale PRENDI, ma in
funzioni associate al coltello ed al tempio. I dettagli di questo metodo di eccezioni veranno discussi più avanti.
L'effetto è che "la cosa che ci si aspetta" di solito capita quando il
giocatore cerca di (ad esempio) prendere qualche cosa. Se l'oggetto che sta
cercando di prendere non è speciale, e la situazione non è speciale, allora
"funziona", e prende l'oggetto. In Zork, ci sono parecchi di questi verbi
base. Comprendono "prendi", "lascia", "tira", "attacca", "brucia", "rompi"
ed altri. Questi verbi base sono organizzati in modo tale da consentire di
fare cose sensate ad ogni oggetto il giocatore incontrerà nel gioco. In
molti casi gli oggetti hanno delle proprietà che indicano se un certo verbo
ha senso se applicato loro (le armi hanno una proprietà "arma", ad esempio,
che viene controllata dal verbo "attacca"). Applicare un verbo ad un
oggetto che non possiede la proprietà necessaria spesso ha come risultato
una risposta sarcastica ("Attaccare un troll con un giornale è
temerario."), ma il punto è che viene fatto qualcosa che ha un significato,
qualcosa che il giocatore si aspetta. Un altro modo in cui il gioco cerca di essere reale è tramite l'uso di
presupposti nell'analizzatore dei comandi del dungeon master. Immaginiamo
che il giocatore dica "Attacca". Supponendo che abbia un'arma e che ci sia
un nemico da attaccare, ciò dovrebbe funzionare, e funziona. I presupposti
sono implementati per mezzo dell'esistenza di costruzioni di verbi
(stereotipi) e di memoria nell'analizzatore. Nell'esempio l'analizzatore
seleziona le costruzioni del verbo "attacca". Queste indicano che "Attacca
'cattivo' con 'arma'" è la forma della frase che ci si aspettava. Ora,
"cattivo" indica un altro abitante del dungeon, così l'analizzatore ne
cerca uno che sia attualmente disponibile, un "nemico" nella stessa stanza
del giocatore. Allo stesso modo il giocatore deve avere un'"arma" in suo
possesso. Presupponendo che solo un "nemico" sia nella stanza e che il
giocatore abbia solo un'"arma", questi vengono inseriti negli spazi vuoti
della costruzione ed avviene il combattimento. Supponiamo che ci sia solo un nemico disponibile, il troll, ma che il
giocatore abbia due armi: un coltello ed una spada. In questo caso il
dungeon master non può decidere per lui quale usare, così si arrende,
dicendo "Attacco il troll con cosa?", si ricorda l'ultimo input, così come
creato per default ("Attacca il troll"). Quindi se l'utente risponde "Con
la spada", o "Spada" viene unito al resto dell'input e il combattimento
avviene. Questa memoria dura per diversi turni: ad esempio, "Attacca";
"Attacca il troll con cosa?"; "Con il coltello"; "Quale coltello"; "Il
coltello arrugginito"; e così via. Strutture dati e strutture di controllo La struttura sottostante di Zork è composta dal data base (conosciuto come
il "dungeon") e la struttura di controllo. Il data base è una struttura di
puntatori interconnessi che uniscono le istanze di quattro tipi di dati
principali: "stanze", le locazioni del dungeon; "oggetti", cose alle quali
ci si può riferire; "azioni", i verbi e le loro strutture di costruzione; e
gli "attori", gli agenti delle azioni. Ogni istanza di questi tipi di dati
può contenere una funzione che è l'elemento specializzante di
quell'istanza. La struttura di controllo di Zork è, ad un livello, la
specificazione di quali di queste funzioni deve processare la frase in
input ed in quale ordine. Nel caso più semplice, Zork esegue un ciclo in cui tre operazioni
differenti vengono effettuate: input del comando ed analisi, esecuzione del
comando, ed elaborazione in background. (La figura 1 è un diagramma di
flusso del programma di Zork). [Figura 1] La fase di input del comando nel ciclo è relativamente semplice. Ha lo
scopo di permettere all'utente di digitare il suo comando, modificarlo se
necessario, e terminare con un ritorno carrello. Lo scopo dell'analizzatore di Zork è quello di ridurre le specificazioni in
input dell'utente (il comando) ad una piccola struttura che contiene
un'"azione" e fino a due "oggetti" se necessario. L'analizzatore inizia controllando che tutte le parole nella frase in input
siano nel suo vocabolario. Poi deve determinare quale azione e quali
oggetti, se necessario, sono stati specificati. Un oggetto che viene
indicato in una frase deve essere "disponibile" - cioè deve essere in
possesso del giocatore, nella stanza in cui si trova il giocatore, o
all'interno di un oggetto che è disponibile. Gli oggetti che non rispondono
a questi criteri possono ancora essere indicati se sono "oggetti globali",
e sono di due tipi: quelli che sono sempre disponibili (come le parti del
corpo del giocatore), e quelli che sono disponibili in un ristretto insieme
di stanze (come una foresta od una casa). Gli aggettivi forniti nella frase
vengono usati per distinguere gli oggetti dello stesso tipo generale (come
coltelli e pulsanti) altrimenti sono ignorati. Se un oggetto rimane
ambiguo, l'analizzatore domanda quale tra gli oggetti ambigui si voleva
indicare (ad esempio, "Quale pulsante devo premere?"). Poi viene il controllo sintattico, con cui l'"azione" corretta viene usata
per ogni verbo. L'analisi sintattica fa uso di ogni preposizione fornita,
distinguendo tra, ad esempio, "guarda" e "guarda sotto", che comportano
azioni differenti. Infine, avendo determinato la sintassi appropriata per
una particolare frase, l'analizzatore si assicura che tutti gli oggetti
richiesti dalla determinata azione siano stati specificati. L'analizzatore
può, ad esempio, decidere che la sintassi corretta della frase "Dai X" sia
"Dai X a Y". Allora viene fatto un tentativo per fornire un "Y" appropriato
per completare la frase. Questo è reso possibile dalle definizioni delle
azioni, che includono gli attributi degli oggetti su cui applicarle. In
questo esempio, l'azione per "Dai" definisce l'oggetto indiretto ("Y") come
un altro abitante del dungeon; l'analizzatore cerca di acconsentire vedendo
se uno è disponibile. Se così, l'oggetto indiretto è stato trovato, e
l'analisi ha avuto successo. Se no, al giocatore viene chiesto di fornire
l'oggetto indiretto. ("Dai X a chi?"). Una volta che questa fase è stata
completata, l'analisi è finita e l'output dell'analizzatore viene
restituito. Gli aggettivi e le preposizioni che si trovavano nell'input dell'utente
sono stati usati solo per determinare l'"azione" e gli "oggetti", e non
fanno parte dell'output dell'analizzatore. In più tutti gli articoli
vengono ignorati, sebbene gli utenti possano usarli per aumentare la
chiarezza (per loro) di quello che hanno scritto. Ad esempio un input come
"Knock down the thief with the rusty knife" ["Atterra il ladro con il
coltello arrugginito"] viene ridotto a qualcosa simile a Se, invece, l'input fosse stato "Knock on the thief" l'analizzatore avrebbe
potuto ridurlo a riconoscendo che l'"azione" da eseguire dipende, per la parola "knock",
dalla sintassi della frase in input: "knock down" diventa "colpisci",
mentre "knock on" diventa "picchia". Una volta che l'analizzatore ha terminato, inizia il trattamento del
comando. Gli elementi funzionali (se ce ne sono) di ognuno degli oggetti
dell'input analizzato vengono invocati. In più alcuni oggetti che non sono
stati specificamente indicati, ma che definiscono la situazione, fanno
parte della sequenza di trattamento. L'ordine mediante il quale queste
funzioni vengono chiamate viene determinato per mezzo di una strategia che
fornisce alle eccezioni l'opportunità di manipolare l'input prima di
eseguire l'azione associata al caso più generale. L'ordine di trattamento è
quello che segue:
Ognuna di queste funzioni viene chiamata a turno e gli viene data
l'opportunità di trattare il comando. Se decide di interpretare il comando,
il processo di trattamento termina a quel punto, e le funzioni rimanenti
non vengono chiamate. Altrimenti la sequenza prosegue. Si deve notare che
una funzione può fare qualcosa (come stampare un messaggio) senza trattare
completamente un input. La chiamata della funzione di un oggetto avviene
sotto il controllo del verbo; può, dopo appropriati controlli, determinare
che la richiesta del giocatore non è ragionevole. ("Il tuo carico è troppo
pesante. Devi lasciare qualche cosa.") Questo limita leggermente la
flessibilità, ma ha il vantaggio di localizzare i test ad uno stato
ragionevole. Probabilmente una delle funzioni interpreterà il comando e stamperà una
risposta appropriata. Se non dovesse succedere, la risposta di defauilt
"Nothing appens" [Non accade nulla] viene stampata. D'altra parte è stata
posta molta cura per assicurare che la maggior parte degli input abbiano
una rispota appropriata. Infatti una delle cose più divertenti del gioco è
che consente di fare delle cose ridicole, e la sorpresa che deriva dal
vedere che il gioco le capisce. Le funzioni descritte fin'ora vengono invocate come risposta diretta a ciò
che l'utente ha scritto. I processi in background, i "demon", vengono
richiamati dopo ogni input, indipendentemente dalla sua natura. Consentono
al programma di fare delle cose indipendentemente dalle azioni del
giocatore. Al momento ci sono quattro demon. Il primo è il demon del "combattimento".
Gli abitanti del dungeon sono spesso ostili; questo demon consente loro di
assalire il giocatore anche se non provocati, e di continuare a combatterlo
anche se li ignora. Poi c'è il processo di guida dietro il "ladro", descritto come un "uomo
apparentemente depresso che porta una grossa borsa". Lo scopo del ladro è
quello di rendere difficile la vita al giocatore scappando con i tesori od
altri oggetti scelti a caso. Si comporta come un altro giocatore nel
dungeon, sebbene sia ostile e più potente. Il terzo demon viene usato per avvertire il giocatore della presenza di
forze ostili inducendo la sua spada (se ne ha una) a splendere se in
vicinanza ci sono dei nemici. Controlla nelle vicinanze del giocatore e
stampa un messaggio appropriato se lo "stato di allarme" cambia; visto che
il ladro si muove per conto proprio, non è sufficiente cercare i nemici
quando il giocatore si muove. L'ultimo è il demon "orologio". È il meccanismo mediante il quale il
concetto di tempo futuro è stato introdotto nel gioco; eventi arbitrari
possono essere programmati per tempi futuri. Ad esempio la lampada può
esaurirsi dopo un determinato numero di mosse, e le ferite inflitte in un
combattimento possono guarire. Ed in considerazione dei modesti
dattilografi l'orologio non va avanti dopo un input non interpretabile. La storia di Zork L'esistenza di Zork è la diretta conseguenza dell'esistenza di due giochi
eccellenti: Dungeons and Drangons, un gioco di simulazione fantasy (non su
computer) inventato da Dave Arneson e Gary Gygax, e Adventure, un gioco di
simulazione fantasy su computer scritto originariamente da Wil Crowther ed
in seguito ampliato enormemente da Don Woods. Adventure stesso prendeva ispirazione da D&D (come viene familiarmente
chiamato), in particolare da una variazione di D&D che veniva giocata a
Bolt Beranek and Newman, una società di computer di Cambridge in
Massachusetts. Alla fine venne rilasciato al pubblico e divenne uno dei
più popolari giochi di computer degli ultimi tempi. Uno dei laboratori che entrò in possesso di Adventure era il laboratorio di
Computer Science del MIT, nel quale si trovavano tutti i designer di Zork
(gli autori e Bruce K. Daniels). Durante il processo di "risoluzione" di
Adventure, comunque, le mancanze del gioco e lo spirito di competizione che
spesso anima i ricercatori di computer destò il desiderio degli autori di
crearne un seguito. La nostra scelta naturale per il linguaggio da usare fu MDL, che è uno dei
linguaggi in uso al LCS (Laboratory for Computer Science). MDL era
raccomandabile per altre ragioni, comunque. Discende dal LISP ed è
funzionalmente espandibile. Permette inoltre di definire dei propri tipi di
dato, che è una cosa importante per un gioco composto di "stanze",
"oggetti", "verbi" ed "attori". Infine MDL rende semplice inserire chiamate
implicite di funzioni nelle strutture dati per confezionare il gioco come
descritto più sopra. La versione iniziale del gioco venne progettata ed
implementata in circa due settimane. La prima versione di Zork vide luce nel Giugno del 1977. La cosa
interessante è che non venne mai "annunciato" od "installato" per l'uso, ed
il nome venne scelto perché era una parola senza senso largamente
utilizzata, come "foobar". La versione originale del programma era molto più piccola, sia
geograficamente che per quel che riguarda le sue capacità. Diverse nuove
sezioni sono state create da corrispondenti espansioni nella quantità di
universo simulato. Ad esempio la necessità di navigare nel fiume appena
creato portò all'invenzione dei veicoli (nella fattispecie una
imbarcazione). Allo stesso modo l'aggiunta di un robot portò all'invezione
di altri attori oltre al giocatore: esseri che potevano modificare
l'ambiente circostante, e così via. Il combattimento venne aggiunto per
fornire un po' più di casualità in un gioco abbastanza deterministico. Il futuro dei giochi di simulazione fantasy su computer Zork ha quasi raggiunto il limite pratico di dimensioni imposto da MDL e
dallo spazio di indirizzamento del PDP-10. Per questo il gioco non si
espanderà (molto?) ulteriormente. Comunque il sottostrato del gioco (i tipi
di dato, il parser, ed i verbi base) è sufficientemente indipendente che
non dovrebbe essere troppo difficile usarlo come base per un linguaggio per
SFC. Ci sono diversi modi in cui i prossimi giochi di simulazione fantasy su
computer potrebbero evolversi. Il più ovvio è quello di scrivere nuovi
enigmi nello stesso sottostrato dei vecchi giochi. Alcune delle aggiunte di
Zork sono esattamente questo, per questo hanno richiesto una piccola
espansione dell'universo, o nessuna. Una persona sufficientemente
fantasiosa potrebbe farlo per un tempo indefinito. Una direzione simile potrebbe essere quella di cambiare l'ambiente del
gioco. Zork, Adventure e Haunt (i giochi SFC conosciuti dagli autori)
risalgono tutti a D&D ed alla tradizione della letteratura fantasy di J. R.
R. Tolkien, Robert E. Howard e Fritz Leiber. Ci sono, comunque, altre
ambientazioni; quella fantascientifica è la prima che viene alla mente, ma
ce ne sono indubbiamente altre. Un approccio un po' differente per il futuro potrebbe essere quello di
espandere la simulazione di universo descritta nel gioco. Ad esempio in
Zork il concetto di "indossare qualcosa" è assente: con questo si
potrebbero avere anelli magici, elmetti, stivali, ecc. In più di potrebbe
aggiungere il corpo del giocatore. Ad esempio un giocatore potrebbe essere
ferito al braccio con cui usa la spada, riducendo la sua capacità di
combattimento, o ad una gamba, riducendo la sua abilità nel muoversi. Quelle precedenti sono sostanzialmente aggiunte banali al gioco. Una cosa
più interessante potrebbe essere l'introduzione di incantesimi magici. Per
avere una qualche idea del tipo di problemi che i nuovi concetti
introducono nel gioco, considerate questo breve elenco di problemi che
sarebbe necessario fronteggiare: Se la magia esiste, come fanno i giocatori
ad imparare gli incantesimi? Come vengono invocati? Sono presenti con forze
differenti? Se così, come è possibile qualificare il giocatore per una
versione più forte di un incantesimo che già possiede? Per cosa devono
essere usati gli incantesimi (sono come le parole magiche di Adventure, ad
esempio)? Come fa il giocatore a conservare le sue capacità magiche nel
corso di diverse sessioni di un gioco? Come si può vedere quella che all'inizio sembra una semplice aggiunta ad un
gioco che già possiede elementi magici solleva molte domande. Una delle
lezioni imparate da Zork, infatti, è quella che dovrebbe essere già ben
conosciuta nel campo dell'informatica: "Non c'è una cosa come un piccolo
cambiamento!" Una direzione ancora più ambiziosa per i futuri giochi SFC è quella dei
giochi multi-giocatore. Anche il più semplice di questi giochi introduce
parecchi problemi, anche ignorando il meccanismo usato per consentire la
comunicazione e la condivisione. Ad esempio ci sono degli enormi problemi
relativi ai vari aspetti della simultaneità e della sincronizzazione. Come
fanno i giocatori a comunicare tra di loro? Come possono coordinare le loro
azioni, come l'attacco di un certo nemico insieme? Mettendo da parte i problemi di implementazione, un gioco multi-giocatore
dovrebbe avere (crediamo) dei differenti tipi di problemi per essere
interessante. Se il gioco dovesse essere di tipo cooperativo (come lo sono
la maggior parte degli scenari di D&D), allora dovrebbero essere escogitati
dei problemi che richiedano l'aiuto di diversi giocatori per essere
risolti. Se il gioco dovesse essere competitivo e simile all'attuale Zork,
allora il primo giocatore che venisse in possesso dell'unico strumento
adatto ad un determinato lavoro avrebbe un enorme vantaggio, solo per fare
un esempio. Altri problemi nascono dal fatto che la statistica ci dice che
al giocatore medio occorrono settimane e molte sessioni distinte per
finire il gioco; che cosa gli accade nel momento in cui lui non sta
giocando, ma gli altri sì? Crediamo che ci sia un grande futuro per questo tipo di giochi, sia per i
giocatori che per i programmatori e designer di più complessi, più
sofisticati e, per farla breve, più reali giochi di simulazione. La distribuzione di Zork Zork è disponibile in due modi. La versione più aggiornata è disponibile
presso P. David Lebling, Stanza 205, 545 Technology Square, Cambridge, MA
01239. Questa versione è compatibile con i sistemi operativi ITS, Tenex e
Tops-20 per il PDP-10 della Digital Equipment Corp. Per ottenere questa
versione è necessario inviare un nastro magnetico e l'affrancatura per il
ritorno. Un'altra versione, tradotta da MDL in Fortran, è disponibile
tramite il DECUS (il Digital Equipment Computer Users Society), One Iron
Way, Marlboro, MA 01752. Questa versione è compatibile con i sistemi
operativi del PDP-11 e del VAX. Bibliografia S. W. Galley and Greg Pfister, MDL Primer and Manual, MIT Laboratory for
Computer Science, 1977. P. David Lebling, The MDL Programming Environment, MIT Laboratory for
Computer Science, 1979. Gary Gygax and Dave Arneson, "Dungeons and Dragons," TSR Hobbies, Inc.,
Lake Geneva, Wisc. P. David Lebling è un membro dello staff del MIT Laboratory for Computer
Science, dove lavora su sistemi di pianificazione data-intensive e su
sistemi di messaggistica su computer. In precedenza era impegnato con
sistemi di trascrizione e comprensione del codice Morse. Detiene titoli SB
e SM in scienze politiche ottenuti al MIT. Marc S. Blank è uno studente di medicina all'Albert Einstein College of
Medicine; prenderà la laurea in Giugno. Viene impiegato di tanto in tanto
come consulente per il MIT Laboratory for Computer Science, dove lavora su
database MDL e manutenzione del sistema. È laureato al MIT con un BS in
biologia, è membro di Phi Beta Kappa e Phi Lamdba Upsilon. Timothy A. Anderson è un membro dello staff di ricerca della Computer
Corporation of America, Cambridge, Massachusetts, dove lavora sul sistema
di database distribuito SDD-1. Come studente al MIT Laboratory for Computer
Science, Anderson era coinvolto nella ricerca dell'apprendimento del codice
Morse. È membro di ACM, Sigma Xi, Tau Beta Pi, e Eta Kappa Nu, e detiene
titoli SB e SM in scienze dell'informazione ottenuti al MIT. All'interno di Zork Quelli che seguono sono alcuni esempi di quello che è presente all'interno
di Zork. I commenti (come nel linguaggio MDL) sono stringhe che seguono un punto e
virgola. Quindi ;"Sono un commento." Esempi da Zork Una dimostrazione dei veicoli, specificatamente il battello magico (vengono
tentate diverse cose ridicole). Giocare con il fuoco, cercando di incendiare il dipinto (alla fine
l'avventuriero incauto si fa il proprio deserto): Una dimostrazione del parser, ed un insieme delle sue caratteristiche,
compreso il ricordarsi gli input precedenti e l'uso di ALL [tutto] e ALL
EXCEPT [tutto tranne]: Il ladro, che dimostra la sua vena sadica: Un non atipico incontro e combattimento con il troll (sfortunatamente
questo si è risolto con la morte dell'avventuriero): La dimostrazione del demon Orologio, con lo Gnomo di Zurigo che appare dopo
un numero di mosse specifico conseguentemente all'intrappolamento nella
Small Room: "Zork: A Computerized Fantasy Simulation Game"
Trascrizione originale di Paul David Doherty
P. David Lebling
Marc S. Blank
Timothy A. Anderson
MIT Laboratory for Computer Science
Benvenuto in Zork.
Versione creata 8 Dicembre.
Ovest della casa.
Ti trovi in un vasto campo ad ovest di una grande casa bianca
con una porta chiusa con assi.
C'è una piccola cassetta postale.
>VAI A NORD
Nord della casa
Sei di fronte al lato nord di una casa bianca. Non ci sono
porte, e tutte le finestre sono sbarrate.
>EST
Retro della casa
Sei dietro la casa bianca. In un angolo della casa c'è una
piccola finestra che è leggermente socchiusa.
>APRI LA FINESTRA
Con grande fatica, apri la finestra abbastanza da consentire
l'entrata.
>ENTRA
Cucina
Sei nella cucina della casa bianca. Un tavolo sembra essere
stato usato recentemente per la preparazione del cibo.
Un passaggio conduce ad ovest, e si vede una scala scura
che porta di sopra. Ad est c'è una piccola finestra che è
aperta.
Sul tavolo c'è una sacca marrone allungata, odorante di
peperoncino.
Una bottiglia è posata sul tavolo.
La bottiglia di vetro contiene:
Una quantità d'acqua
[<azione COLPISCI> <oggetto LADRO> <oggetto COLTELLO-ARRUGGINITO>]
[<azione PICCHIA> <oggetto LADRO>]
;"La definizione del `verbo' READ:"
<ADD-ACTION "READ"
"Read"
[(,READBIT REACH AOBJS ROBJS TRY)
;"restrizioni sulle caratteristiche e le locazioni degli
oggetti per il completamento di un comando `READ' privo
di indicazioni.
L'oggetto deve essere leggibile ed accessibile."
["READ" READER] DRIVER]
;"READER è la funzione, e la forma `READ oggetto' è
preferibile (il `driver')"
[(,READBIT REACH AOBJS ROBJS TRY) "WITH" OBJ ["READ" READER]]
;"la specifica per `READ obj1 WITH obj2'"
[(,READBIT REACH AOBJS ROBJS TRY) "THROU" OBJ ["READ" READER]]
;"la specifica per `READ obj1 THROUGH obj2'">
;"I sinonimi di READ:"
<VSYNONYM "READ" "SKIM">
;"READER è la funzione generale di lettura:"
<DEFINE READER ( )
<COND (<NOT <LIT?,HERE>> ;"Deve esserci della luce per leggere."
<TELL "It is impossible to read in the dark."<)
(<AND <NOT <EMPTY? <PRSI>>>
;"<PRSI> è l'oggetto indiretto. Se ce ne è uno, il
giocatore sta cercando di usare qualcosa come una
lente di ingrandimento."
<NOT <TRNN <PRSI>,TRANSBIT>>
;"Se è così, meglio che sia trasparente!">
<TELL "How does one look through a " 1 <ODESC2 <PRSI>> "?">
;"Il test è fallito, quindi stampa una battuta")
(<NOT <TRNN <PRSO>,READBIT>>
;"L'oggetto diretto deve essere leggibile."
<TELL "How can I read a " 1 <ODESC2 <PRSO>> "?">
;"Non lo è.")
(<OBJECT-ACTION>
;"Ora la lettura ha una possibilità.")
(ELSE ;"Non è stato gestito, quindi stampa il testo."
<TELL <OREAD <PRSO>>,LONG-TELL1>)>>
;"Un oggetto: Un mucchio di banconote di Zorkmids
(gli Zorkmids sono la valuta di Zork)"
<OBJECT ["BILLS" "STACK" "PILE"]
;"Il nome dell'oggetto ed i sinonimi."
["NEAT" "200" "ZORKM"]
;"Gli aggettivi che si riferiscono all'oggetto."
"stack of zorkmid bills"
< + ,OVISON, READBIT, TAKEBIT, BURNBIT>
;"Le proprietà dell'oggetto: è visibile, leggibile,
prendibile ed infiammabile"
BILLS-OBJECT
( ) ;"Il contenuto dell'oggetto (sempre vuoto per
questo oggetto)."
[ODESC1
"200 neatly stacked zorkmid bills are here."
;"La descrizione estesa."
ODESCO
"On the floor sit 200 neatly stacked zorkmid bills."
;"La descrizione estesa iniziale (quando viene
visto per la prima volta dal giocatore)."
OSIZE 10 ;"Il suo peso."
OTVAL 15 ;"Il valore dell'oggetto: i punti per il ritrovamento
ed il salvataggio."
OFVAL 10
OREAD ,ZORKMID-FACE
;"Cosa stampare quando l'oggetto viene letto."]
;"Gli elementi un oggetto con parole chiave che li
nominino sono rari (pochi oggetti sono leggibili e
quindi richiedono slot OREAD). Gli altri slot sono
comuni a tutti gli oggetti.">
;"La funzioni per le banconote Zorkmids. È dove è possibile fare la maggior
parte dei commenti sarcastici."
<DEFINE BILLS-OBJECT ( )
<SETG BANK-SOLVE!-FLAG T>
<COND (<VERB? "BURN">
<TELL "Nothing like having money to burn!">
<>) ;"Stampa una battuta ma non gestisce il comando
(ottenuto restituendo l'oggetto false <>). Consente
a BURN di trattare questo oggetto."
(<VERB? "EAT">
<TELL "Talk about eating rich foods!">
;"Non consente ad EAT di funzionare (restituisce un
valore non falso.")>>
;"Una stanza: la cripta in cui si trovano i Zorkmids."
<ROOM "BKVAU" ;"Il nome interno della stanza."
"This is the Vault of the Bank of Zork, in which there are no doors."
"Vault"
,NULEXIT ;"Non ci sono uscite da questa stanza."
(<GET-OBJ "BILLS">)
;"All'inizio le banconote sono qui."
<>
< + ,RSACREDBIT ,RLANDBIT>
;"Nella stanza non può entrare il ladro, ed è una
stanza di terra."
[RGLOBAL < + ,WALL-ESWBIT ,WALL-NBIT>]>
;"Ci si può riferire ai muri della stanza."
>GUARDA
Base della Diga
Sei alla base del Controllo del Flusso Diga #3, che si erge sopra di te
ed a nord. Il River Frigid [Fiume Freddissimo] scorre proprio qui. Oltre
il fiume ci sono le White Cliffs, che sembrano creare un muro gigantesco
che si estende da nord a sud lungo la sponda est del fiume mentre
prosegue la sua via a valle.
C'è un canotto gonfio.
Il canotto magico contiene:
Un'etichetta marrone
>IMBARCATI SUL CANOTTO MAGICO
Sei ora nel canotto magico.
>NORD
Non puoi andarci mentre sei nel canotto magico.
;La stanza a nord è stata definita per non consentire le barche.
>LEGGI
Leggi cosa?
>ETICHETTA
Presa.
!!!!FROBOZZ MAGIC BOAT COMPANY!!!!
Hello, Sailor!
Istruzioni per l'uso:
Per entrare nella barca, scrivi `Imbarcati'
Per lasciare la barca, scrivi `Sbarca'
Per entrare in acqua, scrivi `Lancia'
Per andare a riva, scrivi `Approda'
>LANCIA
Frigid River
Sei nel River Frigid nelle vicinanze della diga. Il fiume scorre
tranquillamente. C'è un approdo nella riva ovest. Sei nel canotto
magico.
>GIU
Frigid River
Il fiume gira ad angolo qui, rendendo impossibile vedere la diga. Le
White Cliffs si ergono sul bordo est e delle grandi rocce impediscono
l'approdo ad ovest.
Sei nel canotto magico.
>SU
Non puoi andare controcorrente a causa della forte corrente.
>METTI IL CANOTTO NEL CANOTTO
Come puoi farlo?
>SBARCA
Ti rendi conto, appena in tempo, che sbarcare qui potrebbe essere
fatale.
>GIU
Frigid River
Il fiume scorre veloce qui, ed il suono avanti sembra appartenere a
delle rapide. Sulla riva ovest c'è una spiaggia. Una piccola spiaggia
si scorge anche sotto le Cliffs.
Sei nel canotto magico.
C'è una boa rossa, qui (forse un avvertimento).
[nella stanza]
>MANGIA LA BOA
Presa.
Non credo che la boa rossa sarebbe d'accordo con te.
;La funzione del verbo ha finito tutto il processo.
>INVENTARIO
Stai portando:
Un paio di candele
Una scatola di fiammiferi
Una torcia
Un dipinto
Una lampada
>ACCENDI LE CANDELE CON LA TORCIA
Ti accorgi, appena in tempo, che le candele sono già accese.
>SPEGNI LE CANDELE
La fiamma si spegne.
>ACCENDI LE CANDELE CON LA TORCIA
Il calore della torcia è così intenso che le candele si vaporizzano.
;La funzione `candele' ha gestito la cosa essendosi accesa con
la torcia.
>ACCENDI FIAMMIFERO
Uno dei fiammiferi comincia a bruciare.
>INCENDIA IL DIPINDO CON IL FIAMMIFERO
Il dipinto prende fuoco. Sfortunatamente, nel frattempo, lo tenevi
in mano.
>OVEST
Soggiorno
Sei nel soggiorno. C'è una porta ad est, una porta in legno con una strana
scritta gotica ad ovest, che sembra essere inchiodata, ed un grande
tappeto orientale al centro della stanza.
C'è una scatola.
Una lanterna di ottone alimentata a batterie è sopra la scatola. A dei
ganci sopra la cappa è appesa una spada molto antica.
>PRENDI TUTTO TRANNE LA CARTA ED IL TAPPETO
spada:
Presa.
lampada:
Presa.
>LEGGI
Leggi cosa?
>LA PORTA
L'iscrizione si traduce in `Questo spazio è stato lasciato vuoto
intenzionalmente'
>GUARDA SOTTO IL TAPPETO
Sotto il tappeto c'è una botola chiusa.
>SPOSTA IL TAPPETO
Con grande sforzo il tappeto si sposta in un lato della stanza.
Con il tappeto spostato, la copertura impolverata di una botola
chiusa appare.
>APRI
Apri cosa?
>LA PORTA
Quale porta devo aprire?
>LA PORTA DELLA BOTOLA
La porta si apre con riluttanza rivelando una traballante scala che
scende nell'oscurità.
>VAI GIU
È decisamente buio. Potresti essere mangiato da un grue.
La tua spada si illumina di un debole blu.
>COSA È UN GRUE?
Il grue è una presenza sinistra ed in agguato nei posti bui della terra.
La sua dieta favorita è composta di avventurieri, ma il suo insaziabile
appetito viene moderato dalla sua paura della luce. Nessun grue è mai
stato visto alla luce del giorno, e solo pochi sono sopravvissuti alle
sue mandibole spaventose per raccontarlo in giro.
La tua spada si illumina di un debole blu.
>ACCENDI LA LAMPADA
La lampada è accesa.
Cantina
Sei in una cantina umida e scura con uno stretto passaggio che porta
ad est, ed un cunicolo a sud. Ad ovest c'è il fondo di una ripida
rampa di metallo che non è scalabile.
La porta della botola si chiude con uno schianto, e senti qualcuno
che la blocca.
;La funzione della stanza chiude la botola per evitare fughe.
Sei in una piccola grotta con entrate ad ovest e nord, e una scura,
minacciosa scala che porta giù.
C'è un individuo dall'aspetto sospetto, con una borsa, appoggiato
contro un muro. È armato con uno stiletto.
>INVENTARIO
Stai portando:
Una lampada
Una spada
Una barra di platino
Una figurina in giada
L'impugnatura del suo stiletto ti colpisce alla testa, e tu barcolli
indietro.
;Il demon del combattimento è partito.
L'altro occupante se ne è andato, portando con sé la grossa borsa. Prima
che tu possa accorgerti del fatto che ti ha derubato.
;Il demon del ladro è partito.
>INVENTARIO
Stai portando:
Una lampada
>SOSPIRA
Devi parlare più forte se vuoi che ti senta!
>EST
La Stanza del Troll
Sei in una piccola stanza con passaggi in tutte le direzioni.
Macchie di sangue e profondi graffi (forse fatti da un'ascia)
deturpano i muri.
Un disgustoso troll, brandendo un'ascia insanguinata, blocca tutte
le uscite dalla stanza.
La tua spada sta brillando molto intensamente.
>UCCIDI IL TROLL CON LA SPADA
Un colpo potente, ma manca il troll di un chilometro.
L'ascia ti colpisce ad un fianco. Ahio!
>TIRA LA BOTTIGLIA AL TROLL
Cercare di attaccare un troll con una bottiglia di vetro è
da suicidio.
L'ascia colpisce le rocce, lanciando scintille!
>SALTA SUL TROLL
Il troll è troppo grande per saltargli sopra.
Barcolli all'indietro sotto i colpi dell'ascia.
>LEGA IL TROLL
Con cosa?
>CORDA
Il troll si divincola e non riesci a legarlo.
Il troll ti colpisce con un colpo rapido, e resti stordito per
un momento.
>DIAGNOSI
Hai una ferita leggera, che si curerà in 29 mosse.
Puoi essere ucciso da un'altra ferita leggera.
Il troll agita la sua ascia, ma ti manca.
;Il troll, non essendo un gentleman, continua a combattere mentre
esaminate le vostre ferite.
>GRIDA
Aaaarrrrrrrrgggggggggggggghhhhhhhhhhhhhh!
L'ascia colpisce le rocce, lanciando scintille!
>SVEGLIA IL TROLL
Il troll non sta dormendo.
L'ascia ti manca mentre salti da una parte.
>SALTA
Wheeeeeeeeee!!!!!
L'ascia del troll ti passa da parte a parte.
Sembra che l'ultimo colpo sia stato di troppo per te. Mi dispiace per
la tua morte.
Piccola Stanza
Sei in una stanza piccola e spoglia senza niente di particolare. Non
ci sono uscite da questa stanza.
>NORD
C'è un muro in quella direzione.
>EST
C'è un muro in quella direzione.
>SUD
C'è un muro in quella direzione.
>OVEST
C'è un muro in quella direzione.
>SU
Non ci sono uscite in alto.
>GIU
Non ci sono uscite in basso.
>FOO
Beh, FOO, BAR e BLETCH anche a te!
>ARRAMPICATI SUI MURI
Arrampicarsi sui muri non porta a niente.
Uno Gnomo di Zurigo, con indosso un vestito in tre pezzi, e in mano
una cassetta di sicurezza, si materializza nella stanza. `Sembra
che lei abbia dimenticato di depositare i suoi valori', dice, toccando
impaziente il coperchio della cassetta. `Di solito non consentiamo ai
clienti di usare le cassette qui, ma possiamo fare questa UNICA eccezione,
credo...' Ti guarda di traverso da sotto le sue lenti bifocali.
>SALVE, GNOMO!
Lo gnomo sembra sempre più impaziente.
>INVENTARIO
Stai portando:
Una lampada
Uno spicchio d'aglio
Un coltello
>DAI L'AGLIO ALLO GNOMO
`Non metterò QUELLO nella cassetta di sicurezza', sottolinea lo gnomo
con disdegno, lanciandolo oltre le spalle, dove scompare con un leggero
'pop'.
>PUGNALA LO GNOMO CON IL COLTELLO
Lo gnomo dice 'Beh, non ho mai...' e scompare con uno schiocco di
dita, lasciandoti da solo.
>GUARDA
Piccola Stanza
Sei in una stanza piccola e spoglia senza niente di particolare. Non
ci sono uscite da questa stanza.
by P. David Lebling/Marc S. Blank/Timothy A. Anderson
[IEEE Computer, vol. 12 no. 4, April 1979, pages 51-59.]
Traduzione di Paolo Vece <pvece@mclink.it>
Torna alla Home Page
©2000 Simone Zanella e ©2000 IF Italia. E' vietata la riproduzione.