J'dal

Proseguono le recensioni dei giochi partecipanti alla IF COMP 2012: oggi parliamo di J'dal il primo lavoro di  Ryan Kinsman (e si vede).

J'dal è la protagonista di questo racconto, unica ragazza di una compagnia d'avventurieri che annovera anche il padre e che ha come obiettivo quello di recuperare un misterioso manufatto dalle viscere della miniera. 

Una comitiva di quattro persone che devono esplorare una miniera alla ricerca di un tesoro. Non potrebbe esserci trama più classica nel mondo della narrativa interattiva. J'dal si distingue per avere una protagonista femminile, che a dire il vero verrà maltrattata dal resto della comitiva, come ci si aspetterebbe in epoca medievale. Questo ha suscitato critiche da parte di alcuni recensori tra cui Emily Short, che si è lanciata anche in una disamina dei termini e dei dispregiativi usati nel testo. A dire il vero il gioco è talmente insipido nell'implementazione, nella scrittura e negli enigmi che non merita di dedicarvi tale attenzione. 

Nessuna possibilità di esplorazione, interazione con gli altri personaggi scarsa e esitante, enigmi per nulla interessanti, oltre a diversi bug nell'implementazione, relegheranno questo gioco nel dimenticatoio.

E' la dura lezione che ognuno di noi impara quando partecipa a una competizione con il suo primo lavoro.

The Lift

Altra recensione dei giochi in concorso alla IF COMP 2012.

Oggi vi racconto di The Lift di Colin Capurso, non che ci voglia molto a dir la verità.

Si tratta di un mini racconto a scelte multiple. Nessuna caratterizzazione del personaggio che non ha memoria, nessuna storia, ma solo combattimenti. Vi viene chiesto di entrare in una stanza e scegliere un'arma, poi passate in un'altra dove potete dilettarvi con giornaletti porno o meno, infine entrate in un ascensore che vi porterà ad incontrare vari tipi avversari ed a seconda dell'arma scelta potreste sopravvivere o incontrare una morte truculenta. Tutto qua.

L'unica curiosità che può portarvi a rigiocarlo è quello di vedere in quanti modi riuscite a morire.

Da non spenderci oltre cinque minuti.

Guilded Youth

Oggi recensiamo un altro gioco partecipante alla IF COMP 2012, ovvero Guilded Youth di Jim Munroe.

In questa avventura ambientata negli anni '80 si vestono i panni di Tony il Ladro, un adolescente che ha conquistato tale appellativo su un MUD di Dungeons & Dragons a cui accede attraverso il suo fido C64.

Tony ed i suoi amici hanno un cruccio; al di la del bosco esiste una villa abbandonata e pericolante di cui hanno sempre desiderato scoprire i misteri, anche se incute paura e tra pochi giorni verrà demolita e con essa tutti i suoi misteri e tesori. A Tony non rimane che farsi coraggio, arruolare l'allegra compagnia e lanciarsi all'avventura.

Il gioco è scritto molto bene, ambientazione e  personaggi sono ben definiti e caratterizzati. Il richiamo alle avventure di bande di ragazzi adolescenti conta negli anni '80 numerosissimi riferimenti cinematografici, ma tutti noi da ragazzini abbiamo avuto (spero) la nostra gang  volta ai giochi ed alle avventure, il richiamo quindi è attualissimo ed universale.

Nel gioco alterneremo fasi in cui ci collegheremo al gioco di ruolo online, dove reclutare fidi compagni d'avventura, alle escursioni notturne nella villa abbandonata.

Ciò che colpisce da subito è l'aspetto grafico dell'avventura, assolutamente spettacolare. Vi potreste chiedere: sei forse impazzito? Non stiamo parlando di avventure TESTUALI?

Non temo smentite!

L'autore ha pubblicato questo gioco online, basandosi sulla nuova interpretazione di parchment fornita da vorple. Un modo di sfruttare l'html, i css e javascript facendoli dialogare con lo storyfile. In pratica il gioco riesce a comunicare con l'interprete modificando l'interfaccia a seconda delle necessità del gioco. Ecco dunque che quando il protagonista è collegato online al MUD attraverso il C64, lo schermo usa caratteri anni 80 e immagini  bicromatiche, un vero tuffo nel passato. Poi quando ci spostiamo nella "realtà" ecco che lo schermo si modifica, appaiono le immagini dei personaggi in stile fumetto, un ottimo inventario grafico e i caratteri assumono un aspetto moderno.

Il layout è pensato in maniera perfetta, la parte centrale è dedicata al testo, in modo che le frasi (che vengono mantenute brevi) non creino linee troppo lunghe e pesanti da leggere, in cima una bella immagine d'ambiente, a sinistra il profilo dell'eroe ed il suo inventario, a destra i personaggi che lo affiancano. Alcune delle immagini sono anche leggermente animate. Il tutto si adatta perfettamente a diverse possibili grandezze della finestra, anche se i browser supportati non sono tutti, e probabilmente chrome è il migliore avendo anche il supporto audio.

Vorple è ancora in fase sperimentale, ma le premesse sono eccelse, e non ho ravvisato problemi del parser, con l'unico inconveniente dell'impossibilità di richiamare la cronologia delle azioni. Ma è questione di tempo, vorple è il futuro (spero).

Tornando alla sostanza del gioco, sebbene sia ben strutturato ed anche la storia abbia degli spunti interessanti, la parte enigmistica lascia molto a desiderare, praticamente si può completare il gioco usando solo tre verbi, impossibile rimanere bloccati, ed il gioco prosegue senza slanci rimanendo abbastanza piatto e senza poter approfondire veramente nessun aspetto. Non fosse per la spettacolare interfaccia e per la buona scrittura sarebbe un gioco del tutto scialbo.

Ritengo che Guilded Youth sia un gioco importante, ma non come desidererebbe ogni autore per la qualità del gioco stesso, ma per essere il primo esempio di utilizzo di vorple, ed in particolare per essere un ottimo esempio di come il layout possa costituire un valore aggiunto per ogni avventura.

Non fosse per l'interfaccia Guilded Youth finirebbe nel dimenticatoio appena giocato.

Ai fini della competizione non credo che possa ambire alla vittoria o ad un piazzamento, magari otterrà un riconoscimento per l'uso del medium. Meritato.

Lunar Base 1

Alla IF COMP 2012 la fantascienza la fa da padrone. Dopo Andromeda Apocalypse recensiamo una delle altre avventure in competizione.

Anno 2080 due astronauti partono dalla terra diretti alla prima base lunare americana. Un altro passo importante per l'umanità, ma le cose non andranno come previsto...

Lunar Base 1 di Michael Wayne Phipps Jr. avrebbe tutte le premesse per essere un grande gioco. Un'ambientazione fantascientifica (il viaggio e la colonizzazione della luna) tradizionale ma attuale ed estremamente realistica, un'ottima prosa, piacevole e scorrevole, una caratterizzazione dei personaggi che si fa sempre più dettagliata, belle descrizioni... peccato che a tutti questi elementi non venga aggiunta una storia.

L'avventura comincia con il lancio della missione, ed essendo il gioco molto orientato alla simulazione, sarete spesso chiamati a ripetere operazioni standard come manipolare degli strumenti, aprire e chiudere i portelloni quando uscite dalla navicella e così via. In realtà questo aspetto, sebbene ripetitivo, non annoia dal momento che contribuisce a costruire l'ambientazione e fa immedesimare il giocatore sempre più anche grazie alla narrazione degli eventi che si arricchisce di dettagli fornendo ulteriori informazioni sul carattere dei personaggi. 

A questo punto, mentre state effettuando delle analisi di routine accade l'inaspettato, uno strano fenomeno sulla superficie lunare ed il vostro compagno che perde la ragione. La vostra necessità che oscillerà tra fargli riprendere il senno completando la missione e la curiosità nell'investigare il fenomeno dai connotati soprannaturali.

Fino a questo momento c'è tutto... un ottimo incipit per un grande gioco... peccato finisca qua. Il resto è breve e banale ed il finale sebbene ben scritto ha poca sostanza e non cancella la delusione per la mancanza di una vera storia. 

La sensazione è che l'autore abbia esaurito la verve creativa o peggio abbia deciso di presentare un gioco incompleto tagliandone gran parte. E' un vero peccato perché come detto le potenzialità c'erano tutte.

Consigliato per gli appassionati di fantascienza che vogliono passare una ventina di minuti in una simulazione di missione lunare, ma che non abbiano velleità di giocare una vera Avventura.

Non credo che possa arrivare molto in alto nella classifica finale della competizione.

Andromeda Apocalypse

Marco Innocenti colpisce ancora, a distanza di un anno pubblica una nuova avventura Andromeda Apocalypse che come suggerisce il titolo rappresenta il seguito di Andromeda Awackening (avventura che avevamo già recensito su queste pagine) ed ancora una volta lo fa partecipando alla IF COMP, la competizione anglofona più prestigiosa in ambito di narrativa interattiva.

Lanciato nello spazio a bordo del misterioso Hyerotrope, Ektor Mastiff, ultimo (?) sopravvissuto della razza umana, sperso nel cosmo, s'imbatterà in ciò che rimane di una nave spaziale aliena completamente disabitata (?) e piena di misteri.

Sarà un viaggio di esplorazione e d'avventura, un concentrato di nichilismo di fronte alla vastità del cosmo e all'umana incapacità di comprenderne i misteri.

In questa nuova avventura Innocenti rispolvera un altro classico della fantascienza anni '50, la scoperta di un manufatto alieno (nella specie una nave spaziale) e la sua esplorazione, con i suoi misteri ed i suoi pericoli. Ancora una volta quindi l'autore non punta sulla storia, su una trama dall'intreccio complesso o su un conflitto tra i personaggi per catturare l'attenzione del giocatore, ma ci pone di fronte al fascino dell'esplorazione di un ambiente sconosciuto ed alieno. Si andrà avanti nel gioco non tanto chiedendosi cosa accadrà, ma cosa incontreremo. In questo senso ricalca lo stesso stile del primo capitolo di questa saga, mantenendone tutti i punti di forza.

Rispetto al primo capitolo, invece, ho riscontrato un netto miglioramento nella qualità della scrittura. Dopo le molte critiche ricevute in passato, l'autore in questo nuovo lavoro usa periodi brevi senza più appesantirli con aggettivi e similitudini improbabili. La scorrevolezza della lettura ne guadagna e così la sua godibilità. Non mancheranno le critiche degli anglofoni, naturalmente, leggendo il testo si ha ancora la sensazione che esso sia  stato scritto vocabolario alla mano da un non madrelingua. In ogni caso seppur non rappresentando un surplus, la qualità della scrittura questa volta non dovrebbe penalizzare il giudizio complessivo del gioco.

Uno degli aspetti divertenti di questo tipo di giochi è disegnare la mappa, ed in Andromeda Apocalypse ne avrete bisogno dal momento che per come sono strutturati gli enigmi la dovrete consultare spesso e sarà un accessorio imprescindibile ed indispensabile per il completamento del gioco (fatela accurata).

Il ritmo del gioco è buono, interessante e costante nel tempo, non fa mai calare l'attenzione ed anche le scene d'intermezzo dove vengono affrontati i grandi quesiti filosofici del ruolo dell'umanità nello spazio infinito sono godibili e ben strutturati, ottimo è anche il senso di urgenza che si crea alla fine dell'avventura che aumenta il pathos nel momento più opportuno. In questo contesto gli enigmi si inseriscono bene, non sono particolarmente difficili e sono ben studiati quale parte integrante dell'ambiente.

Il gioco mette anche a disposizione un ottimo servizio di suggerimenti (progressivamente espliciti) consultabile nel caso ci si trovasse in difficoltà, cosa che in realtà accade di rado. Vi è un unico difetto nell'impianto enigmistico del gioco anche se piuttosto grave e che spero venga presto corretto. In uno dei momenti culmine del gioco potreste avere la netta sensazione di essere incappati in un cul de sac. Ovvero si percepirà che una azione passata (fatta moltissimi turni prima) abbia compromesso la solvibilità del gioco (non è detto che capiti, potreste essere stati più avveduti di me). Ciò non è vero, esiste una soluzione alternativa (fortunatamente) solo che non ne avrete alcun indizio, anzi il meccanismo dei suggerimenti vi darà la convinzione che non ci sia più niente da fare. Fortunatamente prima di abbandonare il gioco ho voluto scrivere all'autore (che è stato gentilissimo e celere nella risposta) per sapere se esisteva una soluzione alternativa all'enigma il che mi ha permesso di completare con successo l'avventura.

Dal punto di vista tecnico l'implementazione del gioco è quasi perfetta, non ho rilevato errori o bug, la mappa poteva essere disegnata meglio dandole una forma significativa, ma stiamo cercando il pelo. Si nota un ottimo lavoro di beta-testing.

Il gioco viene distribuito con dei gadget elettronici allegati, un file mp3 di musica elettronica poco orecchiabile, una bella cartolina, l'immagine di un disco che troveremo nell'avventura ed il biglietto del treno da cui ebbe inizio l'avventura del protagonista nel precedente capitolo (e che abbiamo ancora nell'inventario).
Ci sarebbe anche l'immagine di un book con la tesi scritta dal protagonista, ma non è niente di che. Direi che la cosa migliore è il biglietto del treno dove spicca un logo della locale compagnia ferroviaria veramente ben fatto.

In conclusione siamo di fronte ad un'ottima avventura, dal carattere esplorativo, con numerosi riferimenti (non espliciti, ma evidenti) a grandi capolavori della fantascienza che gli appassionati non potranno non apprezzare, e che vi impegnerà per diverse ore.

I giochi d'Innocenti, pur essendo di vecchia scuola nella struttura, sono originali e moderni, oserei dire che l'autore sta sviluppando e definendo un proprio stile personale nel creare avventure dai connotati ben precisi. Se, come preannuncia il finale aperto di Andromeda Apocalypse (scelta che lascia sempre l'amaro in bocca al lettore), vedremo nuovi episodi della saga probabilmente in futuro parleremo di giochi all'Innocenti.

Buon divertimento!!!

Julius Blasck e la mano viola

Come saprà chi segue il newsgroup it.comp.giochi.avventure.testuali il sito di IF ITALIA sta migrando come sotto-sezione del più attivo OLD GAMES ITALIA su cui nel frattempo ha fatto la sua comparsa (in sordina direi) la pubblicazione della prima avventura di questo nuovo corso.

Stiamo parlando di Julius Blasck e la mano viola un'avventura di stampo poliziesco scritta e programmata da Francesco Bellia al suo primo lavoro nel mondo della narrativa interattiva.

Nel gioco si impersona un detective alle prese con un omicidio piuttosto cruento e singolare, che scoprirete affondare le proprie radici nel passato avventuroso della vittima, passato che dovrete ricostruire e che si arricchirà di dettagli con l'avanzare delle indagini.

La prosa è breve e scorrevole, si ispira chiaramente alla narrazione in prima persona fatta dallo stesso detective come se raccontasse il ricordo dell'indagine, una scelta che nelle avventure testuali è originale e di cui avevamo suggerito l'uso già molti anni fa.

La storia è interessante ed invita al gioco con l'introduzione di nuovi personaggi che emergono dal passato della vittima man mano che si avanza nel gioco.  La trama è lineare e piuttosto semplice, ma non lo si avverte come difetto, anche se non sarebbe stato male avere indizi che portassero verso false piste.

Fin qui sembrerebbe un bel gioco, ma veniamo alle dolenti note, che sono molte purtroppo. L'implementazione è assolutamente carente, il riconoscimento delle azioni importanti poco curato, e quindi eccoci alle prese con una caccia al verbo assolutamente fastidiosa (ammetto che sono dovuto andare a spulciare il sorgente per venirne a capo). Nessun orpello è regalato al giocatore che non potrà gingillarsi con nessuna azione di contorno e d'ambiente. L'interazione con gli altri personaggi è ridotta all'osso e questo mortifica il giocatore che vedrà l'indagine avanzare in modo automatico semplicemente per aver parlato con questo o quel personaggio. I comandi validi e che sortiranno effetto saranno quasi esclusivamente quelli necessari alla prosecuzione del gioco.

La programmazione tradisce inesperienza e mancanza di beta-testing, personalmente ho rilevato almeno 5 o 6 bugs di cui uno irreversibile dal momento che non mi è stato possibile completare il gioco. Non ho avuto il coraggio di ricominciare per verificare se era possibile evitare tale cul de sac involontario, a voi se ne avrete voglia la controprova.

In definitiva, spero che Francesco decida di rivedere e correggere la programmazione del gioco, per renderlo usufruibile dal momento che allo stato attuale l'implementazione mortifica troppo l'esperienza di gioco per renderlo divertente o anche solo consigliabile.

Marco

IF Multilineare

di Emily Short

Traduzione di Marco Falcinelli

Uno degli aspetti più belli della narrativa interattiva è che la si può utilizzare per raccontare storie che si sviluppano in molteplici trame alternative.

E’ una possibilità, non è detto che questo aspetto ne diventi una caratteristica tipica. Qualunque gioco sia stato scritto da “Zork” passando per “Jigsaw” segue una trama lineare prestabilita, anche se il giocatore può avere l’impressione di poter seguire sentieri alternativi, non vi è la concreta possibilità di allontanarsi da quello principale. Anche l’IF più ambiziosa e sperimentale, come “Photopia” ad esempio, normalmente racconta solo una storia. O se vi sono più sentieri narrativi (come nel caso i “I-O”) questi si limitano ad essere due o tre al massimo.

Ciò che intendevo fare con “Galatea” era dare al giocatore l’impressione che l’universo fosse completamente aperto per il finale, e che, piuttosto che attraversare una lunga serie di opzioni sbagliate per arrivare a quella che ho scelto di implementare, potesse con buon senso  raggiungere un qualsiasi risultato. Ovviamente non è stato possibile raggiungere tale intendimento: tutti i possibili finali in Galatea sono prodotti della mia mente, cose che ho scritto perché anticipassero una certa combinazione di eventi che li avrebbero resi appropriati. Ma vi sono circa 30 o 40 finali diversi (ne ho perso traccia; non tutti i finali si distinguono molto gli uni dagli altri), e molte centinaia di modi per raggiungerli. 

Pertanto come accade in una macchina per racconti, il gioco ha una sua efficacia nel creare degli scenari a cui non ho pensato specificamente. Alcuni di essi sono migliori di altri, ma ho cercato di fare del mio meglio per essere sicura che qualunque cosa fosse prodotta dal gioco avesse quanto meno senso. (E’ molto più difficile di quanto possiate immaginare, e vi sono probabilmente ancora combinazioni inappropriate e che stonano, anche dopo un lungo processo di verifica ed aver giocato molte volte l’avventura.)

Ciò dovrebbe, credo, rispondere (o almeno contribuire a rispondere) al lungo dibattito se sia possibile scrivere narrativa interattiva veramente multi lineare o narrativa non lineare che rimanga comunque ben costruita e con una storia sensata.

Un lavoro che possa quindi ricompensare adeguatamente il giocatore che la rigioca più volte; qualcosa che mantenga l’interesse del lettore. Ogni passo di conversazione in Galatea potrebbe suggerire due, tre, anche quattro o cinque ulteriori argomenti degni di essere investigati; in più, le azioni come BACIA, ABBRACCIA, COLPISCI, e SCUSATI portano a differenti effetti in contesti diversi. La storia procede molto differentemente a seconda delle scelte del giocatore. Volevo evitare, per quanto possibile, la sindrome dell’immaginare cosa frulla nella mente dell’autore abolendo interamente gli enigmi e lasciando che la trama fosse aperta alle più ampie modifiche.

Questo tipo di approccio concede una certa libertà anche all’autore. Avevo dozzine di idee diverse mentre scrivevo Galatea - sull’arte; sul femminismo e la critica al femminismo; sull’amicizia e i suoi abusi; e (naturalmente) sulla narrativa interattiva e la programmazione dei personaggi non giocatori. Qualunque racconto potessi scrivere sarebbe stato demolito da materiale tanto diverso. Anche uno sviluppo ramificato, nello stile dello Choose-Your-Own-Adventure non avrebbe potuto coprire l’intero campo che intendevo coprire. Con questo mezzo, dunque, ho avuto la libertà di mettere tutti gli argomenti all’interno del gioco, lasciando al giocatore la libertà di scegliere ciò che lo interessava in particolare.

La sfida quindi è quella di determinare le condizioni finali e scrivere degli epiloghi in modo tale che soddisfino il giocatore e che siano coerenti - legando assieme gli eventi accaduti e spiegandoli, e dando la sensazione che i progressi nelle conversazioni siano naturali. Certamente non sarò riuscita a fare un lavoro perfetto da questo punto di vista, e vi è modo di giocare dei racconti che sarebbero terribili se messi a confronto a narrativa statica. L’IF, però, offre un poco di libertà di movimento in più: le persone (almeno per quanto attiene la mia esperienza) tendono ad avere aspettative meno rigorose per quanto riguarda la trama ed il ritmo se gli si offre l’opportunità di interagire con quanto viene scritto e raccontato, e se il finale ha senso basandosi su ciò che è accaduto negli ultimi turni, sembrano relativamente contenti.

Ciò che non vi ho anticipato fino ad ora è quanto la multi linearità possa infastidire le persone. Forse è la natura del giocatori di IF che cercano sempre di risolvere gli enigmi, ma molti dei riscontri che ho avuto avevano la forma della domanda: “Questi sono i finali che ho trovato: ne mancano altri?”

E non vengono rassicurati dalla risposta “Si, ma non fa niente.”

Il che mi ha meravigliato. Dopo tutti i discorsi sul fatto che si possa o meno scrivere narrativa interattiva veramente multi lineare, forse abbiamo trascurato un altro punto: è ciò che il giocatore desidera? Molte persone vogliono seriamente raggiungere “il giusto risultato” o vedere “tutti i finali”, e credo di poter comprendere in parte le loro ragioni. Da un certo unto di vista, vedere Il Mondo Intero del gioco è un enigma da risolvere, e gli enigmi attraggano i giocatori di IF. Ma ancor di più, come sapere che si sta ricevendo ciò che l’autore intendeva trasmettervi se si vede solo un frammento dell’intero lavoro? Ciò va anche al di la della critica ricevuta dal lettore.

Il testo E’ ciò che il giocatore ottiene; le responsabilità dell’autore in questo caso fluttuano tra me ed il giocatore. Probabilmente il senso di coesione e progressione narrativa posseduta dal giocatore sono tanto importanti quanto qualsiasi cosa che io possa fare per rendere la sessione di gioco soddisfacente.

E senza dubbio rimarranno persone che non saranno mai contente fino a quando avranno la certezza di osservare solo una parte del progetto. A loro posso solo dire, Mi spiace. Non ne ho una visione completa io stessa. Si, ho scritto tutti i testi, e si, ho il sorgente a mia disposizione. Ma ciò non significa che abbia anticipato qualunque risultato possa essere prodotto dal gioco. Non realmente. Anche conoscendo tutti i finali questo non significa che conosca tutti i possibili percorsi che vi ci possano condurre, e tutte le possibili varianti che si hanno a seconda dei diversi contesti creati dalle scelte del giocatore.

Nautilisia di Ryan Veeder

Stavo navigando su un qualche sito spagnolo di interactive fiction (mi spiace ma non ricordo quale) quando mi sono imbattuto in un link che portava a Nautilisia un gioco di Ryan Veeder. Non so perché, ma il titolo mi ha incuriosito e così sono andato a dargli un'occhiata. Una "botta di fortuna" dal momento che si tratta di un gioco veramente piacevole e divertente. L'avventura è giocabile online.

Ryan Veeder è l'autore di Taco Fiction, gioco di cui abbiamo parlato in questa recensione e che ha vinto numerosi premi alla IF Comp 2011, quindi non sorprende che altri suoi lavori abbiano una certa qualità; in ogni caso questa piccola recensione non è influenzata dal nome dell'autore visto che vi ho fatto caso solo dopo aver terminato il gioco.

In Nautilisia siete in coma, e l'avventura consiste in un viaggio nel subconscio del protagonista al fine di risvegliarlo. Detto così sembra banale e già visto. Il pregio del gioco è nella qualità della scrittura e soprattutto nell'umorismo che la pervade, a partire dai numerosissimi riferimenti ai simbolismi junghiani. 

Il giocatore è un estraneo, novello medico telepatico, che viene messo a confronto con la "coscienza" del personaggio in coma, un'entità perfettamente "cosciente" di esserlo ed anche abbastanza soddisfatta della situazione. Chi non vorrebbe vivere in un mondo fatto a sua discrezione? In ogni caso la "coscienza" non vi sarà ostile, anzi sarà abbastanza divertita ed irreverente, ma anche "accondiscendente" e d'aiuto nel vostro tentativo di sondare i suoi recessi e risvegliarla al mondo materiale. I suoi commenti sono la parte più divertente, e se non mi credete provate a dare il comando "DREAM" e cercate di non ridere!

Il gioco è abbastanza breve e non dovreste avere difficoltà a terminarlo in un 20/30 minuti. Gli enigmi sono volutamente semplici per mantenere il ritmo della lettura, si tratta di una scelta azzeccata e congeniale alla parte narrativa. Semplice e ottima è anche la mappa e l'esplorazione di cui non rivelo nulla per non rovinarvi la sorpresa (ma vi consiglio di disegnarla, vi stupirà).

Per quanto riguarda l'implementazione il gioco è molto curato, non si avvertirà alcuna carenza o buco nella programmazione, ne tanto meno ho rilevato bugs. Il gioco è stato programmato in Inform 7 ed è giocabile online attraverso parchment. Tra l'altro ho scoperto che il sito di Playfic permette agli autori di sviluppare giochi in Inform 7 direttamente online. Non lo sapevo e mi sembra molto interessante. Non eviterà agli autori la necessità di imparare un linguaggio di programmazione, ma gli consentirà di lavorare e testare il gioco ovunque siano e senza scaricare nulla in locale. Se qualche autore che conosce Inform 7 lo volesse provare, saremmo grati che ci recensisse il sito di Playfic.

Giocate Nautilisia e fatemi sapere i vostri commenti!!!

PS il gioco è in inglese, ma è molto comprensibile.

iOS Fizmo

Come gli appassionati di interactive fiction e di iPhone/iPad sanno, da qualche anno è possibile giocare le vostre avventure preferite per Z-machine anche sui dispositivi mobili targati Apple grazie all'applicazione gratuita iFrotz . Applicazione che fa egregiamente il suo lavoro.

Era tempo però che molti autori aspettavano la possibilità di distribuire i loro giochi per Z-Machine nella forma di applicazioni dedicate e personalizzate per iPhone.

A. Plotkin ha rilasciato iosFizmo, un primo passo in questa direzione. La prima versione è già stabile anche se in piena fase di sviluppo, manca infatti ancora il supporto per glulx.

Naturalmente non è così semplice creare un'applicazione per Apple, è necessario procurarsi un Mac, comprare una licenza di sviluppo software (circa 100 $) ed apprendere le basi del linguaggio xCode (soprattutto se si vuole personalizzare l'applicazione), comunque per chi è interessato è bene iniziare dal sito di Zarf dedicato a iOS Fizmo.

Fateci sapere se intendete imbarcarvi nell'avventura!

Recuperare i Lavori In Corso

di Emily Short

Traduzione di Marco Falcinelli

Mi capita piuttosto spesso di bloccarmi durante un “lavoro in corso”. E lo stesso credo accada a molte persone. Quella che segue è una lista di problemi piuttosto comuni in cui mi sono imbattuta, ed alcuni modi di come questi possano essere risolti per poter proseguire e completare il proprio progetto.

Naturalmente non posso garantire che tali soluzioni siano di particolare utilità per un qualsiasi specifico “lavoro in corso”.

Qualcosa di difficile che risulta impossibile da implementare

Problema: qualcosa di incredibilmente difficile-da-programmare risucchia tutto il tempo che potete dedicare all’implementazione e vi impedisce di procedere con il resto del gioco.

Soluzione: questa cosa-difficile-da-programmare è essenziale per il vostro progetto? Se la risposta è no, allora fatevi forza è tagliatela.

Soluzione: semplificate. Cercate di capire quale parte della vostra simulazione/o-qualunque-cosa-sia sia veramente necessaria e quale possa essere eliminata; sfoltite il vostro progetto fino a quando vi rimane qualcosa che possiate implementare efficaciemente.

Soluzione: chiedete aiuto. Talvolta altri programmatori potranno offrirvi dei buoni consigli. Sia che siate dei principianti che dei programmatori moderatamente esperti, potreste trovare utile pubblicare sul newsgroup delle richieste di aiuto per il codice di programmazione. Se siete programmatori esperti, è poco probabile che vi sia qualcun altro che ne sappia più di voi, ma discutere il problema che avete con un amico può spesso chiarirvi le idee e farvi venire a capo della soluzione.

La produzione di contenuti vi opprime?

Problema: avete concepito una situazione che richiede una quantità assolutamente insana di contenuti, ad esempio, un sistema di conversazione in cui il giocatore può formulare domande su qualsiasi argomento o un world-model con troppi elementi.

Soluzione: restringete l’accesso del giocatore al sistema ponendo un limite di tempo alle scene. Se si hanno solo tre turni a disposizione per sostenere una conversazione con la guardia del palazzo, il giocatore non avrà il tempo di giocherellare con le lacune della vostra implementazione. Molte volte, tale soluzione ha il benefico effetto collaterale di evitare che il ritmo dell’avventura cali nel momento in cui il giocatore spende troppo tempo in parti del gioco che non sono importanti.

Soluzione: restringete l’accesso del giocatore riducendone la libertà d’azione. Cambiate il modo in cui funziona il sistema di conversazione così che non possa chiedere di qualunque cosa (ad esempio usando un sistema a menù, o accettando solo il comando PARLA A); non permettetegli di versare un liquido in un contenitore che già contiene qualcosa; etc. Il trucco qui è di dare al giocatore tanta libertà quanta ne richiedano la vostra storia ed i vostri enigmi, ma non tanta da trascinarvi in gratuiti ed estenuanti lavori di programmazione.

Soluzione (avanzata): meccanizzate l’implementazione. Se il problema è che avete (ad esempio) un sistema completo di conversazione, ma che questo richieda di produrre 3000 oggetti per dei dialoghi piuttosto simili, scrivere tutto il codice a mano potrebbe richiedere più sforzo di quanto possiate sopportare. Considerate la progettazione di un vostro linguaggio di codificazione o una qualche forma di programmazione che vi permetta di autogenerare il codice nel linguaggio di programmazione che avete scelto. E’ una soluzione spesso fattibile ricorrendo ad un linguaggio di codifica come il Perl o simili.

Compiti di implementazione noiosi.

Problema: sapete che dovete inserire un oggetto, una locazione, etc. ma l’idea di farlo vi riempe di tedio.

Soluzione: eliminate l’oggetto. Seriamente: se non vi è niente di interessante in un certo oggetto, considerate se effettivamente ne avete bisogno nel vostro gioco o se potete ometterlo o nasconderne l’assenza. Spesso se trovate che qualcosa sia tedioso, scoprirete che lo sarà anche per il giocatore.

Soluzione: raggruppate gli oggetti. Talvolta è possibile prendere alcuni oggetti differenti nella progettazione del vostro gioco e rimpiazzarli con un singolo nuovo oggetto, più interessante, che giocherà un proprio ruolo in diversi enigmi. E’ possibile esagerare in questo tipo di soluzioni, e ovviamente dovreste evitare di consegnare al giocatore un coltellino svizzero che risolva qualsiasi enigma dell’universo, ma è una soluzione per rendere più interessante una generica implementazione di qualcosa di poco entusiasmante.

Scrivere descrizioni noiose

Problema: dovete scrivere le descrizioni per delle locazioni o degli oggetti, ma l’idea di scriverle vi riempie di tedio.

Soluzione: eliminate l’oggetto. Se una locazione od un oggetto vi annoia, probabilmente non vi è necessità che sia li. Restringere la mappa in modo tale che non abbia troppe locazioni monotone è spesso una buona idea.

Soluzione: fate ricerche. Date uno sguardo ad oggetti o posti reali dello stesso tipo di cui scrivete, e prendetene uno insolito quale ispirazione.

Soluzione: spostate l’attenzione narrativa sulla caratterizzazione o sulla memoria piuttosto che sulle descrizioni di oggetti fisici. Se non c’è niente di interessante da dire a proposito di un oggetto o di una locazione potreste invece usare tale oggetto o locazione come una scusa per raccontare un aneddoto, od una battuta, o qualcosa di particolare che riveli l’attitudine del personaggio giocatore. O potreste usarlo per fornire dei suggerimenti per la soluzione di un enigma, o per cercare di creare una certa atmosfera.

Soluzione: cambiate il progetto. E’ una soluzione piuttosto drastica da attuare nel mezzo della vostra implementazione, ma se trovare poco eccitante la maggior parte delle locazioni del vostro gioco, considerate l’opportunità di modificare un poco la storia - aggiungendo una nuova sezione al vostro mondo, o una nuova linea temporale - in modo da dare una ventata di freschezza all’atmosfera o per rendere più interessanti i luoghi da esplorare.

Soluzione: reclutate un collaboratore. Se odiate veramente scrivere e avete dei problemi a generare un qualsiasi tipo di prosa di vostro pugno, forse dovreste pensare di collaborare con qualcun altro che colmi le vostre lacune.

Sequenze eccessivamente dettagliate sviano l’attenzione dal resto del gioco.

Problema: una scena incredibilmente difficile-da-programmare, ricca di dettagli e di oggetti, o che prevede un enigma particolarmente difficile concentra tutta l’attenzione del giocatore su di essa e gli fa trascurare il resto del gioco. (Spesso questa problematica non si manifesta se non in fase di beta-testing, quando i revisori cominceranno a subissarvi di richieste su un particolare del gioco senza magari completarlo veramente.)

Soluzione: questa scena è fondamentale per la vostra storia, o sta solamente rompendo il ritmo della narrazione? Nel secondo caso, fatevi forza e tagliatela. Se vi è qualcosa di fenomenale nella sua implementazione, ma che non si adatta al resto del progetto, salvate il codice ed utilizzatelo in un altro progetto a cui si possa adattare maggiormente, come ad esempio un gioco per una competizione monocamerale o per l’IF art show.

Soluzione (meno drastica): semplificate la scena e fornite al giocatore una possibile soluzione alternativa. Fate in modo che sia chiaro quale sia l’obiettivo dell’interazione del giocatore (la soluzione di un particolare enigma che porti ad una scena narrativa in particolare) in modo che non si senta impantanato giocandola.

Soluzione (drastica): elevate il livello dell’implementazione di tutto il resto del gioco fino a quando non eguagli il livello della sezione problematica. E’ un’opzione da prendere in considerazione se pensate che tale scena sia la parte migliore del vostro gioco e che sia il modello del tipo di interazione che desiderate creare. Probabilmente allungherà i tempi, sia di gioco, che per la realizzazione del progetto. D’altra parte il gioco risulterà più intensamente curato nella sua implentazione dall’inizio alla fine, il che è una cosa buona. Se avete bisogno di ulteriori motivazioni, provate “Sunset Over Savannah”, “Worlds Apart”, o alcuni dei giochi di zarf per rammentarvi quando possano essere divertenti da giocare.

Sequenze troppo lineari rendono debole una parte del gioco

Il problema: vi confrontate con una parte del gioco in cui il giocatore non può fare niente di interessante per un certo periodo. Un’intera sequenza comporta che il personaggio giocatore faccia qualcosa di piuttosto noioso e meccanico, come seguire una ricetta, fare una valigia, o fare il check-in all’aeroporto.

Soluzione: saltate alla parte successiva attraverso la narrazione. Qualunque cosa risulti noiosa al giocatore e che sia noiosa da programmare probabilmente merita di essere eliminata. La tecnica del salto narrativo tra locazioni è un meccanismo usato con successo in molti giochi; un po’ meno ovvio è un salto narrativo temporale, anche se non si cambia la scena. Ma guardate come esempio “Gourmet”.

Soluzione: cambiate il centro dell’interazione. Ponete in primo piano le conversazioni o altre interazioni interessanti, automatizzando sullo sfondo i compiti noiosi. Invece di richiedere al giocatore di scrivere “ATTACCA IL NEMICO” cinque volte in un duello all’arma bianca, fategli scambiare qualche battuta spiritosa, e descrivete lo scambio di colpi mentre va avanti in modo semi-automatico tra una battuta e l’altra. E’ una soluzione un poco ardita, in quanto implica togliere una parte del controllo dal giocatore, facendo accadere gli eventi senza che egli dia una  diretta istruzione, ma è spesso una soluzione più divertente della sua alternativa.

La parte narrativa richiede troppo tempo perché si sviluppi

Il problema: l’incipit del gioco è piuttosto noioso; non accade niente di rilevante fino a quando il giocatore non ha esplorato abbondantemente la scena, e/o l’obiettivo del giocatore non è abbastanza immediato.

Soluzione: date al giocatore un obiettivo ovvio da perseguire, anche se non è quello principale del gioco. Ciò può rendere necessario aggiungere una piccola scena di prologo a ciò che avete già realizzato. Tale prologo dovrebbe avere un obiettivo chiaramente articolato e dovrebbe anche aiutare a definire il personaggio giocatore e le sue motivazioni di fondo, in modo tale che alla fine, il giocatore abbia maggiore slancio per affrontare una sezione centrale del gioco dal ritmo più basso.

Soluzione: fate iniziare il giocatore nel mezzo di un compito già in evoluzione: nel mentre di una conversazione, ad esempio, o durante un duello di spada, o mentre sta riparando la sua Ferrari.

E’ troppo difficile fare progressi nel gioco, specie all’inizio

Il problema: il primo enigma nel gioco è troppo difficile. (Vedi “Christminster”, un gioco che altrimenti sarebbe ben bilanciato.) E’ importante lasciare che il giocatore faccia dei progressi all’inizio del gioco, altrimenti sarà portato ad arrendersi; se si blocca successivamente, avrà maggiore motivazione nel continuare a giocare, dal momento che vi ha investito già del tempo.

Soluzione: semplificate il primo o i primi due enigmi. Ma presumo vi abbiate già pensato.

Soluzione: aggiungete un prologo con un enigma più semplice, idealmente qualcosa che dia al giocatore un poco di esperienza che può riutilizzare per risolvere ciò che accade successivamente.

Le scene narrative o gli eventi principali mancano d’incisività

Il problema: un evento che si suppone essere narrativamente importante da una sensazione di poca consistenza durante il gioco e non fa la dovuta impressione sul giocatore. E’ un problema particolarmente comune nel momento in cui accade qualcosa di importante nel gioco e vi è un cambiamento di scena attraverso una parte narrativa.

Soluzione: allungate la scena perché abbia luogo in più turni. Rendere la scena interattiva - anche solo per un paio di turni - può cambiare drammaticamente la percezione dell’evento.

Soluzione: inserite delle pause nella scena narrativa dove il giocatore debba premere un tasto per continuare. Questa è una soluzione da minimo-sforzo, e non pagherà molto, ma può dare un certo senso d’importanza alla scena. Alcuni effetti multimediali possono talvolta essere utili in questi casi: se state scrivendo un gioco con delle illustrazioni, inserirle nei momenti importanti aiuta a creare l’evento piuttosto che distribuendole casualmente. “Bolivia by Night” è un ottimo esempio in questo senso.

Soluzione: riscrivete la scena; il problema potrebbe essere la vostra scrittura. Prendete in considerazione di consultare qualche guida su come si scrive la narrativa statica, se non avete molta esperienza nel campo. Potrebbero illuminarvi su cosa manca ai vostri dialoghi o alle vostre caratterizzazioni. In particolare un problema piuttosto comune tra gli autori d’IF in erba è la tendenza a scrivere scene vaghe e poco precise, o a sintetizzare dialoghi che dovrebbero essere scritti con maggior cura.

Soluzione: alzate la sbarra, aggiungendo o cambiando ciò che porta al momento culmine. Dando al personaggio giocatore più motivazione a prestare attenzione a ciò che accade; o dando al giocatore più motivazione a prestare attenzione a ciò che accade, facendolo lavorare verso un obiettivo che viene trattato, modificato o scalzato dal momento culmine.

Sequenze non interattive impediscono al giocatore di fare nient’altro che osservare

Il problema: in alcune parti della narrazione, il personaggio giocatore non ha davvero niente d’importante da fare: come quando due personaggi non giocatori intrattengono una conversazione che il giocatore deve ascoltare senza che vi possa partecipare. Siete infognati in quella che è, essenzialmente, l’implementazione di un film, ed il giocatore è costretto semplicemente a schiacciare Z (“aspetta”) continuamente per fare in modo che il dialogo proceda; oppure anche se il giocatore ha qualcosa da fare durante questa scena, le sue azioni sono solo una perdita di tempo mentre gli altri personaggi importanti proseguono i loro affari importanti che il giocatore è costretto ad attendere e osservare.

Soluzione: tagliate la scena. Le scene dove il giocatore non fa nulla sono meno penose se sono corte. Ciò va, lo ammetto, direttamente contro il mio suggerimento sulla lunghezza delle scene che non hanno abbastanza impatto. Ma la chiave qui è quella di elevare il coinvolgimento del giocatore se gli date qualcosa di realmente importante da fare per alcune scene che contribuiscono alla realizzazione di un evento; se gli date solo dei compiti per tenerlo impegnato, non cambierà nulla.

Soluzione: aggiungere un trama-B alla scena. Vi è qualcosa di veramente interessante che il giocatore deve fare e che può accadere simultaneamente alla trama principale della scena? Allora mettete le due scene assieme. Fate in modo che il giocatore lavori su qualcosa che deve fare mentre i personaggi non giocatori fanno le loro cose allo stesso tempo. Questo spesso richiede che sia sottintesa una certa “ingenuità” all’interno del progetto che permetta che sia la trama A (la parte non interattiva condotta dai personaggi non giocatori)  e la trama B (il compito del giocatore) siano spiegate chiaramente, che non si intralcino tra di loro, e che richiedano pressappoco lo stesso ammontare di tempo. Ciò nonostante, può risultare una soluzione estremamente efficace se ben fatta. (Vedete “Delusions”.) Una variazione comune prevede che  la scena sia progettata in modo tale che la trama B, determinata dal comportamento del giocatore, interrompa e porti alla conclusione la trama A, come quando il giocatore fa infine esplodere le sbarre della propria cella, o scopre un tesoro nascosto, e quindi distrae i personaggi non giocatori da ciò di cui stavano parlando.

Soluzione: cambiare il punto di vista del personaggio. non vi è alcuna ragione per cui il giocatore debba interpretare il medesimo personaggio dall’inizio alla fine. Talvolta è più interessante prevedere dei cambi di ruolo. Ciò può accadere anche se l’altro personaggio ha degli scopi diversi dal primo protagonista: interpretare personaggi alternativi potrebbe gettare nuova luce sulle motivazioni degli antagonisti, ad esempio. (Considerate a tal proposito “Being Andrew Plotkin”.) Questa tecnica potrebbe stridere con il resto del gioco se introdotta nell’ultima parte dello stesso od unicamente per una singola scena, quindi ponderatela bene, tenendo conto del ritmo narrativo e della sua coerenza.

L'Arte dell'Avventura (end)

Come promesso ho messo assieme tutti i precedenti messaggi impaginandoli in un unico file PDF.

Chi non avesse seguito la traduzione settimanale del celebre scritto di Graham Nelson può ora scaricarlo e leggerselo comodamente a questo link.

Buona lettura!!!

Marco

L'Arte dell'Avventura (9)

E con oggi completiamo la traduzione dell'Arte dell'Avventura. Presto ne curerò una versione in pdf, stampabile e comunque più leggibile, sperando di fare cosa gradita. E' stato un lavoro lungo...

Perfezionamento

“[Un gioco in alpha-testing ha] una media di 4,000 bug. Magari il 50% sono errori di battitura o punteggiatura, spazi superflui, righe vuote mancanti, e via dicendo. Magari l'1% sono bachi che causano il blocco del gioco.”

“Cerco di assicurarmi che il sole sia nella giusta posizione o, se ti trovi nello spazio, che il sole e la luna siano collocati nel posto in cui dovrebbero -- cose così... La trave di legno [in Infidel] è descritta essere di una lunghezza e larghezza certa, e ho calcolato che dovrebbe pesare 500 libbre."

-- Max Buxton e Gary Brennan (Infocom play-testers), 1987

Ecco quindi che il gioco è costruito: il legno è grezzo e scheggiato, ma è riconoscibile un gioco. Ci resta ancora un mesetto abbondante di lavoro, un lavoro più semplice anche se meno creativo, ovvero una bella sfacchinata per correggere un baco dopo l'altro, e poi ancora bachi². Il primo compito post-sviluppo è di risolvere il sistema del punteggio, in genere compensando i punti in base a una cifra piacevolmente tonda e dividendola in ranghi. Vediamo Zork II:

Principiante (0), Avventuriero Amatoriale (40), Avventuriero Novizio (80), Giovane Avventuriero (160), Avventuriero (240), Maestro (320), Mago (360), Maestro Avventuriero (400)

E' deludentemente blando, mentre una tradizione più soddisfaciente è di chiamare i ranghi in base alla professione del giocatore nel gioco -- cosicché un musicista d'orchestra potrebbe iniziare come Triangolo, e ascendere a Secondo Violinista e infine Direttore. (In Sherlock, il livello più basso-- che corrisponde a zero conseguimenti -- è Sovraintendente Capo di Scotland Yard). Tra le domande da porsi vi sono: ogni vincitore del gioco avrà necessariamente conseguito 400 punti su 400? (Questo può essere difficile da organizzare se vengono punteggiati anche gli atti piccoli). Tutti coloro che entreranno nella parte finale della partita avranno già conseguito 360 punti, guadagnandosi il titolo di Mago? Il rango Amatore corrisponderà esattamente all'essere usciti dal prologo verso la parte centrale del gioco?

² Dave Lebling comincia a lavorare al mattino: ``Anche una tazza di ottimo caffé non migliorerà le cose quando si hanno di fronte dodici pagine di bug report.” Molti dei commenti benevoli dei test apparsero nelle pubblicità della Infocom sui giornali. Nel migliore dei casi, era enormemente divertente, e il dipartimento di collaudo di Liz Cyr-Jones fece un vivace ed esilarante lavoro estivo. Ma vi erano anche tensioni. I collaudatori che scrissero quelle 12 pagine nel le videro con terrore , ma con l’orgoglio del risultato di un lavoro ben fatto. Sarebbe risultato invece frustrante che essi fossero sistemati ad intervalli irregolari, o per nulla, con le versioni riviste del gioco che talvolta arrivavano senza alcuna chiara indicazione di cosa era stato modificato. Brian Moriarty riprogrammo una gran parte del gioco all’ultimo minuto, ed il fatto che avesse sempre detto che non lo avrebbe fatto rese la situazione esasperante.

Senza che il sistema di punteggio funzioni ed il gioco possa essere giocato dall’inizio alla fine seguendo la sua soluzione vincente senza bloccarsi o sputare fuori risposte assurde, è prematuro lanciarsi nel testing del gioco.

▲ I sistemi di punteggio variano molto tra di loro. Adventure Quest ha un punteggio "su un totale di 6,000 punti", ed esemplifica la tendenza a premiare con 5, 10, o 100 punti alla volta, come i flipper. Altri giochi considerano un enigma come un punto, o ricompensano in percentuali, altri ancora fanno accigliare non dando punti poiché "non è così che funziona la vita." In Moonmist, i punti vengono descritti così: "[Bene, finora hai incontrato Lord Jack e tutti gli ospiti, ti sei lavato dopo il viaggio... ma non hai trovato il tesoro nascosto né prove sufficienti, e non hai neppure identificato il fantasma!]" In Zork III, il "potenziale" del giocatore è dato su una scala di 7, a cui corrispondono sette sfide incontrate (così che un punteggio di 7 non significa che il gioco sia terminato). In The Lurking Horror, 20 puzzle principali vengono premiati 5 punti ciascuno per un totale massimo di 100: il ventesimo puzzle è la vittoria della partita. In alcune versioni di Advent, si viene ricompensati un punto per ogni stanza visitata per la prima volta, 1 punto se non si è mai salvato la partita --- uno sporco trucco --- più il famigerato "Last Lousy Point", ricompensato senza alcun indizio per aver lasciato cadere un certo oggetto in un dato posto, un azione irrilevante che non ottiene nulla. (La gente doveva decompilare il gioco per scoprirlo).



Durante la scrittura e manutenzione di Christminster, Gareth Rees ha tenuto un registro di tutte le 475 modifiche spronate dai tester del gioco e dai giocatori. Questo registro è archiviato con il codice sorgente del gioco sull’archivo ftp dell’Interactive Fiction e fornisce un interessante caso di studio. 224 rapporti richiedevano maggiore interattività e risposte, sovente in relazione ai tentativi sbagliati, ma ragionevoli che il giocatore provava. Altri 86 erano sollevati da risposte sbagliate o incongruenze, 32 da errori tipografici e 79 da errori di programmazione informatica, per esempio nei complessi algoritmi del gioco per gestire la telefonia e la miscelazione dei liquidi.

Ad ogni stadio della scrittura di un lavoro di narrativa interattiva è facile scivolare nell'abitutide di scriverne una che non sia interattiva. Uno sviluppatore che abbia scritto una storia lineare e poi vi abbia introdotto degli enigmi può immaginare che lo stile letterario e l'effetto del gioco siano dati dal testo scritto in origine, ma questo non è del tutto vero: la maggior parte del tempo che il giocatore passa alla tastiera è speso a tentare le cose sbagliate, quindi la maggior parte dell'esperienza che il giocatore ha del gioco risiede in come l’avventura gestisce i tentativi erronei. Questo significa che è essenziale rispondere a quanti più tentativi possibili, prendendo atto del fatto che il giocatore ha fatto dei tentativi onesti, e cercando quindi di aiutarlo ad andare avanti:

Nell'acquario c'è un cucciolo di serpente-marino che ti addocchia con sospetto. Il suo corpo squamoso serpeggia nell'enorme vasca.

>prendi serpente

Invece è lui che prende te. *Uurrp!*

Questo era tratto da Zork II, un programma che è almeno il doppio della grandezza di Advent nonostante implementi un design molto più piccolo. Quasi tutta questa disparità è dovuta alla sua generosa scorta di risposte. Similarmente, Zork I contiene quelli che sono forse i primi esempi di soluzioni alternative ai puzzle (i ciclopi possono essere sconfitti in due maniere diverse, così come la Loud Room). Se un tester del gioco può pensare a una soluzione ragionevole a cui il gioco non risponde, vale la pena considerare una rivisitazione del puzzle per consentire entrambe le soluzioni. Anche in caso contrario, andrebbe comunque inserita una risposta che prenda atto del buon tentativo del giocatore.

I bachi nell'interactive fiction sono di per sé inezie, eppure sono stremanti per la loro quantità, come una colonna di formiche guerriere. Così come il log di Christminster (vedi sopra) dà un'idea del testing di routine, così il catalogo di Graeme Cree sui bug nei giochi pubblicati dalla Infocom (su www.xyzzynews.com) ci mostra ciò che può sfuggire al più rigoroso regime di collaudo. Ecco alcuni tipi di bachi comuni:

• Refusi di punteggiatura, ortografia o grammatica: per esempio, "un arancia". I giochi Infocom sono abbastanza puliti sotto questo aspetto, in parte perché a correggerne le bozze era John Prince, con alle spalle esperienza come editor di libri. (Il compilatore Inform consente allo sviluppatore di estrarre tutto il testo di un gioco per la correzione di bozza.)

• Stanze che sono oscurate quando dovrebbero invece essere illuminate (situazione che tende a non rivelarsi se lo sviluppatore ha l'abitudine di portare con sé una lampada quando prova il gioco), o non modificarne lo stato di illuminata/oscurata quando dovrebbe: come, per esempio, quando un lucernaio si apre, o quando il sole tramonta, o quando le candele in Zork I vengono spente. In Sherlock (21/871214) un giocatore esperto può attraversare la Londra avvolta nella nebbia senza una lampada, sfruttando vari oggetti e luoghi che si rivelano possedere una luce propria (non menzionata nella descrizione).

• Proprietà secondarie di un oggetto trascurate: come un pesce contrassegnato come commestibile, o una porta come fissa sul posto². Starcross (15/820901) trascura di marcare un raggio di luce come inanimato, quindi il giocatore può sbarazzarsene digitando "raggio, vai a ovest".

² Non fu che alla quinta revisione del manuale di Inform che notammo come all’altare dalla ``grande tavola di pietra'' di `Ruins' non fosse mai stato associato l’attributo static.

• Connessioni della mappa mancanti o incongruenti. In Suspended (8/840521), il corridoio nordest da East End a Alpha FC non ha un collegamento indietro a sudest: lo sviluppatore si è semplicemente scordato di crearlo.

• Qualcosa che sarebbe dovuto accadere una sola volta che invece è possibile più di una volta: come rompere una finestra, o un personaggio che saluta il giocatore come uno sconosciuto. L'unico baco risaputo in Wishbringer (68/850501) consentiva al giocatore di riprendersi una moneta d'oro spesa e di poterla spendere di nuovo, guadagnando ulteriori punti all'infinito.

• Fallire nel rivedere appropriatamente lo stato del gioco dopo un evento principale. In Deadline (18/820311), Ms Dunbar a volte era in grado di comparire anche dopo la sua morte e, invero, essere presente nella stessa stanza in cui c'era il suo cadavere.

• Piccole illogicità: messaggi del tipo "La palla rimbalza al suolo e ti ritorna in mano." mentre si è sospesi nel vuoto o si sta guadando un fiume; o essere in grado di nuotare indossando un'armatura, o sbandierare il cappotto che si sta indossando, o mangiare indossando una maschera antigas. In Hollywood Hijinx (37/861215), puoi svuotare un secchio d'acqua mentre nuoti sott'acqua.

• Fallire di controllare che gli oggetti necessari siano di fatto presenti quando il giocatore tenta di usarli implicitamente. In The Witness (22/840924), puoi prendere un drink in qualsiasi luogo del gioco.

• Contenitori con capacità surreali: come un borsellino che può contenere una scala a pioli, o una candela la cui fiamma rimane accesa, o un libro che può ancor essere letto anche dopo essere stato riposto dentro uno zaino. La battaglia della Infocom contro il bug del contenitore di Zork è divenuta leggenda. Numerosi casi furono seguiti, ma in tutte e undici le release di Zork I potevi ancora mettere la zattera nella bara, e poi la bara nel #raft#, facendo così svanire entrambi.

• Nomi dimenticati: per esempio `Planetfall' (20/830708) dimentica di lasciare che il giocatore chiami il mostro microbo "microbo".

• Nomi inadatti: in `Deadline' (19/820427) la porta del bagno al primo piano era impossibile da aprire poiché il gioco la chiamava semplicemente "porta", ma con una porta dello sgabuzzino nello stesso luogo emergeva un'ambiguità che non poteva essere risolta da nulla di ciò che il giocatore poteva digitare.

• Bachi veri e propri nel codice studiato per estendere la simulazione del mondo, specialmente con le corde e con i liquidi: in `Infidel' (22/830916) riempendo il calice quando è già pieno causa il messagio "Il calice d'argento è pieno d'acqua. Il calice d'argento è vuoto."

Le giornate del collaudo del gioco sono dolorosissime. Dave Lebling di nuovo, su `Suspect':

>barista, dammi un drink

"Mi spiace, sono stato assunto soltanto per shakerare drinks."

>balla con alicia

Quale Alicia intendi, Alicia o il soprabito?

Il corpo di Veronica è riverso dietro la scrivania, strangolato con un laccio.

>parla a veronica

Il corpo di Veronica ti ascolta.

("Piccoli bachi, hai presente? Cosucce che nessuno noterebbe mai. A questo punto il lavoro del collaudatore è abbastanza semplice. La storia è come un castello di carte--sembra solido ma al minimo contatto crolla.")

Dei buoni collaudatori di giochi valgono il loro peso in oro. Il primo contributo è cercare di fare le cose in una maniera sistematicamente perversa. Per citare Michael Kinyon, il cui effetto può essere avvertito praticamente ovunque nei giochi del qui presente autore:

Un collaudatore con un nuovo verbo è come un bambino con un martello; ogni problema gli sembra un chiodo.

E qui abbiamo Neil deMause, in merito a uno dei suoi collaudatori di giochi:

Ha una strana compulsione, quando gioca alle avventure testuali, ossia di chiudersi dietro le porte. E' una fastidiosità bizzarra, neppure lontanamente utile ad un giocatore di IF, ma lo adoro per questo, perché in questo modo ha portato alla luce dei bachi che io non sarei mai riuscito a trovare.

Sostanzialmente, i giochi crescono durante il loro collaudo, e diventano vivi. I ringraziamenti di Irene Callaci potrebbero esprimersi a nome di tutti gli autori:

Credevo che il beta testing potesse rivelare un paio di comandi strani, demenziali che non erano stati implementati, o magari un refuso qui e uno là, o al massimo un aggettivo o due di cui mi ero scordata. No! Non ero neanche vicina all'aver chiuso i lavori, e non lo sapevo neppure. Mother Loose crebbe da 151K a 199K durante il periodo di betatesting soltanto. Guardandomi indietro, se avessi rilasciato Mother Loose quando io ritenevo fosse stato pronto, sarei strisciata sotto una roccia dalla vergogna. Grazie, grazie, grazie a tutti i miei beta-testers.

La verità è ancora maggiore: il collaudatore del gioco sta all'interactive fiction come l'editor al romanzo, e dovrebbe essere menzionato e ringraziato in quanto tale. Le maggiori regioni della mappa di Curses e Jigsaw furono espuriate educatamente, ma con determinazione dai miei beta testers in quanto sotto gli standard o inadeguate². Una risposta radicale ai dubbi dei collaudatori è quasi sempre meglio che cartavetrare le crepe.

² Similmente, il codice sorgente pubblicato di `Christminster' contiene ``offcuts'' una specie di enigma del tiro-alla-fune nella torre dell’orologio.

Dopo una prima passata da parte di uno o due collaudatori di gioco, e il conseguente esercizio di ritocco della bozza, il gioco può andare al collaudo di sei o anche sette volontari, che vi si avvicinano freschi e trattandolo più come un divertimento che non come una bomba inesplosa. (Ad un certo punto la Infocom usava due fasi di collaudo, a volte coinvolgendo finanche 200 volontari, anche dopo il collaudo pre-alpha e apha in casa.) E' saggio insistere sui rapporti scritti o via email, o qualche forma concreta, e di chiedere una serie di rapporti, uno alla volta, anzichè attendere un mese per una lista epica di bachi. Può essere utile per i collaudatori mantenere trascrizioni della loro partita al gioco, ed inviarle parola per parola, poiché questi transcript sono eloquenti su quanto difficili o facili siano i puzzle e quali tentativi vani vengono provati. Nella sua versione di debug, Jigsaw forniva il comando "bug" solamente per aiutare i giocatori a digitare i commenti in un simile transcript:

>bug Miss Shutes è menzionata come se fosse un lui

Oh diamine.

>bug Il pane di grano non è commestibile

Davvero?

Vale la pena restare in contatto con i collaudatori per assicurarsi che non restino completamente bloccati per via di un bug o un enigma irragionevole, ma è importante non fornire loro alcun indizio a meno che non lo richiedano esplicitamente.

Un gioco non è mai finito, solo abbandonato. Vi è sempre un ulteriore baco, o un ulteriore messaggio che potrebbe essere migliorato, o una risposta più ironica che andrebbe infilata. Il Debugging è un processo creativo, anche dopo la prima release, e i giochi hanno in genere da quattro fino a dieci rivisitazioni nei loro primi due anni di gioco.

Alla fine, ovviamente, l’autore esce di scena. Quasi tutti gli sviluppatori pre anni '90 citati nella bibliografia sono ancora vivi, ma solo pochi di essi sviluppano ancora, e spesso parlano dei loro giochi come di qualcosa divertente, sì, ma che appartiene ad un altra epoca della loro vita: qualcosa di cui si sentono lievemente auto-consapevoli, forse, qualcosa che fecero anni addietro: quando erano alle superiori, quando i loro figli erano giovani, quando facevano qualche beta-testing per la Infocom, quando i computer erano meno grafici, quando l’if era lo stato dell’arte, quando il dottorato era a un punto morto. Ma, se venticinque anni sono un'epoca nell'informatica, non è un però un lasso di tempo lungo nel mondo dell'arte, e i primi autori rimangono delle presenze importanti in un genere che è più giovane e meno accasato di quanto a volte sembri. Ogni tanto Scott Adams scatena un sussulto generale lanciando un commento in un newsgroup letto perlopiù da autori ai quali egli sembra una figura storica contemporanea a Sott dell'Antartico. Un uomo del genere può davvero avere un indirizzo email?

In una recente trasmissione radio (1999), Douglas Adams disse che la grande godibilità del lavorare ai suoi giochi alla Infocom era il divertirsi con un nuovo medium prima che divenisse una forma d'arte e che vi scrivessero articoli seri. (La qual cosa posiziona questo capitolo abbastanza al suo posto) Ma quella fascinazione originale è dura a morire, la prima e più felice scoperta di chiunque approfondisca l’interactive fiction è che gli autori del passato sono semplicemente troppo contenti di essere riscoperti, e disposti a passare attraverso un sacco di tribulazioni -- setacciando archivi, cantine, ed equipaggiamenti obsoleti -- per vedere che i propri giochi vengano battuti di nuovo.

Un'avventura testuale può essere uno dei lavori più soddisfacenti da scrivere: forse perché uno può sempre lucidarlo ancora un po', forse perché ha possibilità nascoste e segrete. Ma forse anche perché qualcosa viene fatto oltre che scritto: è una volta fatto non può più essere disfatto, cosicché ci sarà sempre un piccolo edificio di mattoni al fondo della strada, e dentro di esso ci saranno sempre chiavi, cibo, una bottiglia e una lampada.