Cirque De Zale – Traduzione Italiana

Come avevo preannunciato, ecco il link per la patch per tradurre Cirque de Zale in italiano.

Potete scaricare Cirque De Zale dal sito dell’Adventure Game Studio o dal sito del gioco.

Questa, come spiego anche nel file “sounasega.txt”© contenuto nella patch, è una traduzione realizzata in assenza del codice sorgente del gioco, quindi molte, anzi tutte, le parti grafiche non sono state localizzate.

Troverete dunque l’interfaccia in stile SCUMM con i verbi inglesi, ma spero che nessuno sia così sprovveduto da non sapere che “Open”=”Apri”, “Close”=”Chiudi” e via discorrendo (ad ogni modo, cliccandoci sopra apparirà la relativa traduzione italiana, quindi non prevedo che qualcuno si arrenda di fronte a questa mancata traduzione.).

Per giocare dovrete scaricare il gioco originale in inglese, installarlo, e poi scaricare la mia patch, e lanciarla (non c’è bisogno che la scarichiate nella stessa directory del gioco) scegliendo però la corretta directory d’installazione.

Una volta installata la patch, è necessario che per la prima volta lanciate il file winsetup.exe e fra i vari settaggi  scegliate “Game Language” in basso a destra, selezionando dal menu a discesa “Italiano2 translation”.

Vi consiglio di selezionare inoltre la risoluzione 640×400 e l’esecuzione in finestra piuttosto che a schermo pieno (sgrana decisamente troppo, ma fate pure come vi pare) ; “Save and Run” vi consentirà d’ora in poi di lanciare direttamente Cirque.exe per giocare. Purtroppo oltre alla 320×200 e alla 640×400 non c’è altra possibilità.

Dimenticavo di ringraziare alcuni amici di OldGamesItalia che mi hanno offerto parte del loro tempo e alcuni consigli: Micartu e Redice, che mi hanno orientato nella tutt’altro che semplice questione della traduzione di avventure AGS (soprattutto in mancanza del codice originale). Ringrazio ovviamente anche Rebecca Clements, che ha creato il gioco.

Vi auguro buon divertimento nel giocare questa breve, semplicissima, ma divertente avventura del 2004, e vi invito a segnalare eventuali imprecisioni o correzioni da apportare.

 

Palle, piatti e concorsi.

Da qualche giorno è stato pubblicato sul portale del Ministero dell’Istruzione, dell’Università e della Ricerca un simulatore delle prove che i candidati dovranno sostenere nel prossimo concorso per professori.

Fra le varie domande, che spaziano dai quesiti di logica a quelli di ortografia, ce n’è una che ha solleticato maggiormente la mia curiosità.

Si tratta del non nuovissimo problema delle pesate; sostanzialmente nella cinquantina di test presenti sul sito, ognuno composto da 50 domande da risolvere in cinquanta minuti al massimo, viene riproposto puntualmente in ogni serie, ogni volta con un numero diverso di oggetti.

In cosa consiste il problema? La sua formulazione tipo è: date N palle, tutte indistinguibili ed uguali, a parte una più pesante delle altre, ed una bilancia a due piatti, quante pesate minime sono necessarie per individuare la palla più pesante?

Il problema è interessante perché è possibile generalizzare la soluzione rispetto al numero delle palle, e anche fare ulteriori osservazioni a margine.

Innanzitutto, come spesso si usa in matematica, iniziamo a considerare i casi “banali”:

per N=1, non c’è niente da pesare, quindi il numero di pesate è zero;

per N=2, chiaramente, è necessaria una pesata;

per N=3, inizia ad apparire la struttura di base dell’intero ragionamento, la cui dimostrazione sarà per induzione; mettiamo una palla su ciascun piatto e ne lasciamo una fuori: se la bilancia si inclinerà, abbiamo trovato la palla più pesante, altrimenti quella lasciata fuori sarà quella cercata; in sostanza, è necessaria una pesata;

per N=4, mettiamo due palle su ciascun piatto, uno dei due si inclinerà, scartiamo le palle dell’altro piatto e ricadiamo nel caso delle due palle già risolto; due pesate, dunque;

da N=5 a N=8 sono necessarie due pesate; la logica è una via di mezzo tra l’approccio di N=3 e N=4: metto due palle su ciascun piatto, se uno dei due si abbassa, ricado nel caso N=2 ed ho un’altra pesata da fare, altrimenti la palla più pesante sta nel gruppo non pesato di 1,2,3 palle a seconda che N sia uguale a  5,6,8, e ricado comunque in un caso per cui è necessaria una sola pesata;

Per N=9, attenzione: potrei (sbagliando strategia) disporre 4 palle su ciascun piatto, ma così facendo rischierei quasi sicuramente di fare 3 pesate, mentre ne sono sufficienti 2: faccio tre gruppi di palle da tre ciascuno, ne confronto due sulla bilancia, il terzo fuori: con una pesata isolo un gruppo da tre, e dunque ho bisogno di una sola ulteriore pesata per identificare la palla più pesante.

Per N=10, siamo costretti ad ammettere che non possiamo escludere che possano essere necessarie 3 pesate: purtroppo dovremo comunque suddividere le 10 palle in gruppi di cui uno superiore a 3 e dunque con un numero necessario di pesate maggiore di 2.

Se si aumenta il numero di gruppi di suddivisione  per ridurre il numero di pesate necessarie per ogni gruppetto, il numero di pesate complessivo non tende a diminuire.

Riassumendo, abbiamo il seguente schema:

N

Gruppo 1

Gruppo 2

Gruppo 3

Pesate

1

1

0

0

0

2

1

1

0

1

3

1

1

1

1

4

2

1

1

2

5

2

2

1

2

6

2

2

2

2

7

3

2

2

2

8

3

3

2

2

9

3

3

3

2

10

4

3

3

3

Sembra dunque che il numero di pesate necessarie non aumenti di pari passo con il crescere del numero di palle. In termini matematici, le due grandezze non sono legate da una proporzionalità con andamento lineare.

Questa tabella può ulteriormente essere riassunta come:

Da N=

A N=

Pesate

2 (30+1)

3 (31)

1

4 (31+1)

9 (32)

2

10 (32+1)

?

3

La casella con il segno “?” è a questo punto facilmente desumibile: è 33, cioè 27; fino a 27 palle sono necessarie al più 3 pesate per trovare quella più pesante; se intuitivamente ci pare poco credibile, non abbiamo altro da fare che effettuare delle prove, ma la matematica ci mette a disposizione degli strumenti molto più potenti come l’induzione: ipotizziamo dunque che per tutti gli interi fino ad N, con N > 3, per N palle di cui una più pesante delle altre, per individuare quest’ultima siano necessarie m pesate dove m è espresso come il numero che soddisfa la condizione: 3m-1+1 ≤ N ≤ 3m  (se M = 3m , allora m=log3M ) e cerchiamo di dimostrare che sia vero che, per ogni M tale che 3m+1 ≤ M ≤ 3m+1 , siano sufficienti al più m+1 pesate. Ma questo è banalmente verificato se applichiamo lo stesso procedimento sopra descritto, ossia formiamo tre gruppi di palle, ognuno dei quali avrà un numero di elementi compreso tra 3m-1+1 e 3m , due dei quali con lo stesso numero, ossia [M/3], dove […] rappresenta la parte intera . Con la prima pesata dunque decideremo in quale gruppo è contenuta la palla più pesante e per quel gruppo vale che il numero di pesate necessario è al più m, e quindi in totale m+1 pesate.

Un fatto interessante è notare che questa struttura di “triplicità” è indotta dal fatto che le nostre bilance hanno due piatti, ma potremmo ipotizzare, anche solo idealmente, delle bilance a tre, quattro,…, P piatti, e a questo punto la regola diventa più genericamente che, data una bilancia a P piatti ed un insieme di palle (con ≥ 2) di cui una più pesante delle altre, il numero di pesate m da effettuare per  determinare quale sia la palla più pesante è dato dall’esponente tale che (P+1)m-1+1 ≤ N ≤ (P+1)m .

E se le palle più pesanti delle altre fossero due? E se fossero Q, con Q < [N/2] ?

Cirque de Zale

Ho avuto modo di affrontare il mondo delle avventure grafiche amatoriali come recensore e vorrei proseguire il discorso con una retrospettiva che secondo me vale la pena recuperare, perché passata forse un po’ sotto silenzio qui da noi in Italia, per via della mancata localizzazione.

Mi sto riferendo a Cirque de Zale (sul sito di AGS, mentre il sito del gioco è Cirque de Zale), a quanto si sa la prima ed unica avventura di Rebecca Clements,

Cirque de Zale

validissima one(wo)man-band creatrice, sceneggiatrice,  finoaduncertopuntoprogrammatrice di CdZ.

Rebecca pubblica CdZ nel 2004, dopo uno sviluppo dell’ordine di grandezza di soli “alcuni” mesi, fra l’altro partendo da una conoscenza elementare, se non da zero, dell’Adventure Game Studio, allora ancora alla versione 2.60 suppergiù, del motore.

Il risultato è un’avventura certamente dall’aspetto retrò già dieci anni fa o poco meno, ma tutto sommato elegante, abbastanza curata nei dettagli e soprattutto dotata di una verve comica “cattiva” piuttosto determinata.

Alexander Zale, il protagonista, è un “ragazzo della cacca”, una sorta di spazzino che ci ricorda in parte il Roger Wilco spaziale,  che lavora nel circo del Grande Astoundo, prestigiatore nonché proprietario del circo; egli sogna di diventare egli stesso un giorno direttore di circo. Ma la sua ambizione, e soprattutto il suo cinismo, lo mettono in condizione di pagare caro una sua insubordinazione ai superiori: finisce per ritrovarsi proiettato in un’altra dimensione in un mondo atemporale, nel quale riuscirà a trovare … la sua dimensione.

Alexander è un personaggio ben ideato, completamente al di fuori da ogni schema mentale, forse vagamente assimilabile a Simon the sorcerer: con lui condivide la faccia tosta, l’opposizione ad ogni tipo di stereotipo, e la battuta politicamente scorretta.

Alexander fa il provolone in inglese…

L’interfaccia è la solita spudorata SCUMM vecchia di venticinque anni (eh, sì, passa il tempo…), la grafica non va oltre la 640×400, altrimenti vi esplodono i pixel in faccia, tutto quanto richiederebbe una rinfrescata su una versione nuova di AGS, non c’è parlato, la durata sarà al massimo di 4-5 ore, gli enigmi sono tutti di tipo “ti do un oggetto per averne un altro in cambio”,  o di dialogo, non ci sono puzzle  o combinazioni di oggetti in inventario, ma per la miseria, c’è una bella sceneggiatura sotto e soprattutto una comicità non banale. Alexander non avrà alcun rispetto di , sovrani, prostitute, papponi, maghi, personaggi delle favole, non vedenti, streghe, animali, nani e ballerine, pur di costituire e mettere insieme la sua compagnia di acrobati ed artisti.

Perché mi metto a parlare di un banalissimo “giochino” di dieci anni fa, scaricabile in meno di un minuto a costo zero, ancora a malapena giocabile in Win7 con qualche accorgimento, che non ha nessun aspetto estetico che possa attirare il giocatore del 2012? Perché, riprendendo il discorso di qualche settimana fa, Cirque de Zale è il classico esempio di come si possa progettare in poco tempo con mezzi limitati una avventura grafica amatoriale di un certo interesse se si ha la pazienza di stendere una sceneggiatura che stia in piedi e che faccia leva su alcuni punti nevralgici per catturare l’attenzione del giocatore: la originalità (anche se non si inventa mai completamente niente di nuovo) e un copione “non scontato”. Solo per questi due aspetti, Cirque de Zale meriterebbe di non finire mai nel dimenticatoio provocato dall’inesorabile progresso dell’hardware e dei sistemi operativi.

Con questo spirito, dunque, mi ero mosso per chiedere a Rebecca Clements, devo ammettere con una certa sfacciataggine, se fosse disposta ad acconsentire che il codice sorgente venisse adattato e ricompilato in una versione più recente di AGS; purtroppo dopo qualche tempo, Rebecca mi ha risposto che sfortunatamente, “tutto il codice sorgenti di CdZ è andato perso a seguito della rottura completa dell’HD un paio di anni fa”.

Eliminata perciò ogni possibilità che Alexander Zale possa mai tornare ricompilato con risoluzioni e compatibilità aggiornate, resta comunque il fatto che vale la pena riproporlo tradotto in italiano. Ecco dunque un paio di esempi di come apparirà :

…e in italiano.

 

… e anche il pataccaro. Peccato per l’interfaccia non completamente traducibile.

Recensione di “Space Hunter” della Miciosegone

Space Hunter (by Miciosegone)

Premessa generale.

Non ho scritto molte recensioni (è anche vero che in generale non ho scritto molte recensioni punto e basta) di avventure freeware/amatoriali, tantomeno comiche. Ritengo che non si possa parlare alla medesima maniera, utilizzando cioè lo stesso metro e gli stessi strumenti che comunemente si adottano  per analizzare un prodotto commerciale. Se da una parte non è ragionevole aspettarsi caratteristiche di alto livello che richiedono un team progettuale a tempo pieno con conseguenti budget dedicati, dall’altra il solo fatto di avere una squadra di sviluppo che lavora per diletto e non per profitto non può giustificare un degradamento qualitativo delle caratteristiche proprie di un’avventura grafica rapportato sia alla struttura standard del genere sia ad un accettabile livello degli aspetti estetici del gioco rispetto agli standard correnti. Detto “terra terra”, un gioco amatoriale alla “Hugo in the house of horror” (che tanto freeware non era, fra l’altro, bensì shareware) poteva essere accettabile e forse addirittura al livello delle avventure Sierra a cavallo degli anni ‘80/’90, ma sicuramente oggi, in mancanza di precise scelte stilistiche e di altri aspetti che controbilancino la grafica pixellosissima, farebbe alzare il sopracciglio anche al retro giocatore nostalgico. Ciò detto in forma del tutto generale e slegata dall’avventura in questione, solo per introdurre il problema metodologico che ci si può, e ci si deve, porre nella critica di un prodotto così diverso da quelli mainstream, la domanda da porsi prima di entrare nel vivo della recensione è: quale critica è necessario adottare per i prodotti, nel nostro caso le avventure grafiche, amatoriali e freeware (termini che per amore di semplificazione potrei tendere ad usare come sinonimi in questo contesto, ma che sinonimi a priori non sono)? La scelta che ho fatto è di procedere, né più né meno con le medesime modalità di un’avventura commerciale, cercando cioè di estrarre gli elementi costitutivi di un rappresentante del genere (trama, grafica, interfaccia, musica/suono/doppiaggio, enigmi, testo) ed individuare “delle basi razionali per la valutazione e l’apprezzamento dell’arte”, come dice wikipedia nella definizione della “critica artistica”, eliminando dall’analisi tutti quegli elementi come confezionamento esterno, manualistica, presentazione del sito, altre recensioni, dichiarazioni del produttore, che, pur rappresentando forme di (iper)testo inerente all’opera in esame, ciononostante costituiscono elementi metatestuali in forma di peritesto ed epitesto (strutture semiologiche il cui approfondimento nell’ambito della critica videoludica, e più nello specifico, delle avventure grafiche, mi ripropongo di analizzare in altre sedi in un futuro indefinito).

Ma perché, qualcuno potrebbe chiedere (e concludo)  i videogiochi sono arte? Certo che lo sono, se accettiamo quanto riportato sempre da wikipedia, che non sarà la Bibbia, è vero, ma non è neanche un romanzo di Liala, che:

“l’arte, nel suo significato più ampio, comprende ogni attività umana – svolta singolarmente o collettivamente – che porta a forme creative di espressione estetica, poggiando su accorgimenti tecnici, abilità innate e norme comportamentali derivanti dallo studio e dall’esperienza. Nella sua accezione odierna, l’arte è strettamente connessa alla capacità di trasmettere emozioni, per cui le espressioni artistiche, pur puntando a trasmettere “messaggi”, non costituiscono un vero e proprio linguaggio, in quanto non hanno un codice inequivocabile condiviso tra tutti i fruitori, ma al contrario vengono interpretate soggettivamente.”

e, proseguendo:

Alcuni filosofi e studiosi di semantica sostengono però che esista un linguaggio oggettivo che prescinda dalle epoche e dagli stili e che dovrebbe essere codificato per poter essere compreso da tutti, sebbene gli sforzi per dimostrare questa affermazione siano stati finora infruttuosi.

Io ovviamente, che amo mettermi sempre dalla parte più scomoda, sono di quest’ultimo avviso.

Resta comunque fermo il fatto che, il solo fatto che un’opera possa essere “artistica” non la pone automaticamente sullo scaffale dei capolavori, esistendo arte fatta bene e arte fatta male, e chi si pronuncia su quale lo sia e quale no, oltre al riconoscimento del pubblico, non necessariamente pagante, attraverso la percezione soggettiva di ciascuno, è la critica.

Premessa alla recensione.

Space Hunter è un’avventura grafica prodotta in forma amatoriale con il motore e ambiente di sviluppo AGS dalla Miciosegone Games Inc. (sic!), la “più produttiva casa di produzione freeware italiana”, recita il sito web, pubblicata nell’agosto del 2010, secondo quanto riporta Mobygames. A questa recensione si è arrivati anche dopo essere venuti a conoscenza che alcune avventure dello stesso produttore hanno rappresentato l’Italia presso competizioni ufficiali internazionali, notizia che è circolata forse un po’ troppo “sottotono”.

Non sia mai.

Qualunque impegno a qualsiasi titolo volto a promuovere e diffondere l’avventura grafica come forma di produzione di opere artistiche, va valorizzato e fatto emergere.

Il gioco, ottenibile ovviamente solo attraverso download, si installa semplicemente decomprimendo la cartella zippata nella directory che preferiamo. Il file Readme.doc non offre una bella presentazione per i giocatori stranieri (che potranno giocare in inglese l’avventura operando sul file di setup; in questa recensione viene valutata la versione in italiano): si parte subito con un chiaro svarione di inglese: “For play the game on wyndows 7 use the winsetup file for choose a lower risolution , fullscreen don’t work”.  Il consiglio in realtà è un po’ troppo drastico: sul notebook su cui è stato provato il gioco, con Win7, è stato possibile giocare a schermo pieno con un gioco di CTRL-ALT-DEL / “Passa a …” ma senza potere visualizzare i filmati. Alla fine si è optato per la decisione di giocare alternativamente per la maggior parte del tempo in finestra (non ridimensionabile, a meno di operare su altri settaggi che comunque non si sono trovati) e in parte a tutto schermo.

Il tema del cacciatore (di taglie) spaziale, trasposizione futuristica dell’investigatore privato dei film noir, è un tema ricorrente nella letteratura cyber-punk-fantascientifica (basti pensare, uno fra tutti, a Blade Runner), che fa riportare alla mente anche un vecchio film del 1983, Il cacciatore dello spazio (Space Hunter in originale, appunto).

Voglio entrare nel vivo della recensione sputando sin da subito i “rospi” più grossi, per passare poi in seguito agli apprezzamenti, che non mancano, ci tengo ad anticiparlo, pur essendo globalmente questo titolo un lavoro “adolescenziale”, questo va detto senza mezzi termini, e per molti versi un lavoro lasciato a metà.

Primo tra tutti, lo scoglio degli errori di ortografia, che non si limitano ad estemporanei errori di battitura, ma che testimoniano una carenza di base della grammatica e dello stile di scrittura. Sono veramente fastidiosi, ed impediscono di poter seguire decentemente le linee di testo a video; talvolta il sorriso viene provocato dagli svarioni (uno tra tutti, “propio” o “propietario”  senza la seconda erre, ripetuto decine e decine di volte nel corso di tutta l’avventura), più che dalle battute.

Un esempio degli errori di ortografia.

Questo, voglio intenzionalmente essere duro su quest’aspetto, non deve accadere mai in un gioco che presenti molto testo come la maggior parte delle avventure grafiche. Il problema è facilmente arginabile e risolvibile, basta (tanto siamo in ambito amatoriale e non remunerativo) rivolgersi ad un amico, che magari abbia un otto in italiano (almeno uno lo si troverà, perdiana!) e chiedergli la cortesia di correggere gli errori di ortografia, le “è” o le “é” dove servono (non sono la stessa cosa), controllare gli apostrofi dove sono necessari e dove non lo sono, i”centra” per “c’entra”, i “cie” e “gie” inappropriati o convertiti in “ce” e “ge” erroneamente, la consecutio temporum e il congiuntivo dove necessario, i monosillabi che non richiedono accentazione, tutte cose a cui con una passata del correttore ortografico di un qualsiasi programma di videoscrittura si può dare una sgrossata micidiale. Questo è uno dei tanti elementi che mi portano a credere che non sia stato dedicato il necessario tempo per realizzare quest’avventura. Un’avventura, non importa se amatoriale o commerciale, non si fa in 10 giorni, in primo luogo, ma soprattutto senza un adeguato ed approfondito betatest condotto da persone terze rispetto all’autore, meglio se completamente digiune di informatica, giochi, o del tema stesso. La sensazione generale, praticamente in ogni comparto, fatta eccezione per  quello musicale, è che il lavoro sia stato buttato giù di getto e che ci sia accontentati di una versione beta, senza preoccuparsi di individuare e correggere molti difetti  anche evidenti. La fretta è sempre una cattiva consigliera in tutte le cose, ma in questo caso lo è ancora di più. Non si diventa buoni realizzatori di avventure sfornandone diciotto (dico per dire) mediocri in un anno, ne basta una, fatta perbene. E  questo è un atteggiamento che va evitato in ogni caso, lo sviluppatore, se commerciale a maggior ragione perché ha un dovere nei confronti del giocatore pagante, ma pur sempre anche nel caso sia amatoriale, ha un obbligo morale che comincia nel momento stesso in cui progetta l’opera e termina il giorno del rilascio finale, di consegnare al gioco un prodotto che sia ragionevolmente quanto di meglio ha potuto fare.

Grafica

In un’avventura grafica, la grafica, appunto, non può essere trascurata; certo, è vero che un’avventura senza grafica, se c’è una storia valida, continua a reggersi in piedi (semmai diventa testuale), mentre difficilmente riesco ad immaginare il contrario, ma questo non deve diventare un alibi. I fondali devono essere rifiniti per quanto si può, i path (le parti realmente calpestabili dall’avatar) devono essere ben delineati, non devono vedersi innaturali percorsi che “attraversano” letteralmente oggetti impenetrabili o personaggi che “levitano” per aria, gli oggetti e le parti interagibili devono essere facilmente riconoscibili e gli hotspot (ossia le parti interagibili della schermata di gioco) devono essere precisamente puntabili. Sotto tutti quanti questi aspetti, Space Hunter è oggettivamente carente. Non stiamo parlando di bellezza, categoria fortemente soggettiva, né di aspetti estetici. Si può anche disegnare come un bambino di tre anni (ma non è questo il caso, ovviamente), ma quando si passa sopra quello che si pensa che possa essere un oggetto con cui interagire, si deve visualizzare il suo nome a video quando si passa sopra l’oggetto, non venti pixel più a destra, l’immagine dell’interfaccia (guarda, parla, usa) non deve mai sovrapporsi alla frase verbo-oggetto-complemento del parser che appare in basso, i fondali con un punto di fuga lontano sono belli, ma devono poi essere gestiti adeguatamente con il proporzionamento progressivo degli sprite, gli oggetti e gli hotspot, infine, devono essere sempre chiaramente visibili e facilmente distinguibili.

Gli sprite del protagonista non sono ancorati alle parti camminabili

Si prenda ad esempio la seguente immagine, presa dai primi minuti di gioco:

Un fondale tipo

In questa immagine ci dovrebbe essere un quadro (sulla sinistra), un frigorifero (sulla destra) un fast food (sempre sulla destra in alto).

Gli sprite inoltre come si può meglio vedere nell’immagine successiva presa dalla stessa scena

Esempio di sprite

sono talvolta appiattiti (l’impressione è che siano direttamente disegnati sullo sfondo) e senza terza dimensione, pur essendo a tutti gli effetti interagibili, con un aspetto piuttosto irreale, come se fossero delle sagome di cartone appoggiate per terra.

Le cose, non capiamo perché, migliorano per la verità decisamente dal terzo capitolo, dove si nota un’accuratezza di realizzazione di fondali e sprite (ma con la comparsa di insopportabili hotspot di dimensione minima che danno luogo ad un intollerabile pixel hunting). La sensazione è che ci sia stato un progressivo miglioramento delle capacità di trasferimento in digitale dei disegni iniziali, senza che si sia tornati ad adeguare il livello qualitativo dell’intera avventura, o che i capitoli siano stati sviluppati da persone diverse e/o in tempi piuttosto distanti. Anche questo concorre a dare la sensazione di trovarsi di fronte ad un semilavorato piuttosto che ad un prodotto finito.

Un fondale ben disegnato e progettato.

Interfaccia

L’interfaccia è, strutturalmente facile e comoda da utilizzarsi. La gestione dei caricamenti (Salva-Carica-Esci) è implementata tramite menù a scomparsa visualizzabile posizionando il puntatore nella parte alta della schermata di gioco. Solo occasionalmente si verifica il caso di attivare involontariamente il menù, in genere gli hotspot non sono posti in quella zona dello schermo.

L’inventario, invece, è visualizzabile con il classico clic del tasto destro del mouse. L’inventario è – eventualmente, nel caso che il numero degli oggetti in inventario lo giustifichi – scorribile attraverso due tasti freccia dx-sx.  Questi tasti freccia soffrono anch’essi del difetto lamentato prima: quasi mai cliccando sopra la freccia (come invece viene naturale) attiverete lo spostamento, ma solo posizionandosi un po’ più a destra, fuori dalla immagine della freccia. Peccato che così facendo si rischia di far scomparire l’interfaccia dell’inventario. I verbi utilizzabili per agire sugli oggetti sono i medesimi disponibili per visualizzare gli hotspot a video. E’ possibile combinare gli oggetti in inventario tra di loro, semplicemente “draggandone” uno sull’altro; il fatto che esistano più schermate per visualizzarli forse rallenta (e alla lunga stanca, soprattutto nel “prova tutto con tutto”, pratica che purtroppo, come vedremo più avanti è drammaticamente necessaria) e rende poco pratico combinare un oggetto presente in una schermata con uno di un’altra.

La combinazione di oggetti, stranamente, non è simmetrica (se combinate A con B, con esito negativo, combinando B con A potreste avere successo). Questo potrebbe avere senso in casi  particolari come “martello” e “chiodo” , ma così non è sempre. Inoltre, può capitare che combinando un oggetto con un altro, molto spesso su un hotspot, non si abbia in risposta neanche una frase di default (quelle tipo “Non puoi utilizzare A con B”) il che non è molto “carino”; viceversa, per quegli oggetti che presentano in fase di combinazione con altro oggetto una frase di default, questa frase sarà sempre restituita, anche quando sarà combinato con un oggetto che dà luogo ad un risultato (nella fattispecie la creazione di un nuovo oggetto); cioè otterremo prima la frase di default, e poi la frase che descrive positivamente la combinazione fatta, a volte con espressioni discordanti.

Quella che sembra un po’ raffazzonata  è la traduzione dell’interfaccia, probabilmente è stato lasciato lo standard del modulo AGS. Questo “stona” perché per certi tratti dell’avventura il testo visualizzato a video è per metà in inglese (i verbi, le azioni e le preposizioni) e per metà in italiano (i nomi degli oggetti); anche qui ribadiamo che un minimo sforzo avrebbe consentito di raggiungere un risultato proporzionalmente molto maggiore del tempo perso.

L’ultimo comando generato resta sul video per tutto il tempo di un eventuale sequenza animata che ne consegua.

Come peccato veniale, ma non troppo, citiamo la poca leggibilità che alcune frasi a video presentano per la scelta non felice di contrasto tra il colore del testo e lo sfondo.

Altro fenomeno che avrebbe potuto essere facilmente evitato è l’artificiosità del passaggio tra una “stanza” e l’altra (ricordiamo che nel gergo delle avventure grafiche e non solo, la “room”, la “stanza”appunto, è un qualsiasi ambiente suddiviso in una o più schermate che sia liberamente esplorabile e che è collegato alle altre stanze attraverso delle “uscite”). Perché mai, se correttamente l’uscita di una stanza è evidenziata da “Vai al ponte”, tanto per fare un esempio, non posso passare all’altra stanza semplicemente cliccando sopra allo hotspot “Vai al ponte”, come qualunque altra avventura grafica? Invece è necessario aprire l’inventario, selezionare il verbo usa e cliccare sullo hotspot. Da rivedere senza riserve.

Suono/Musica/Doppiaggio.

Assente, come probabilmente ci si può aspettare da un’avventura amatoriale, il doppiaggio, ci concentriamo su effetti sonori e musica.

Gli effetti sono spartani ed essenziali, esiste un suono di default che ci avvertirà quando si è compiuta un’azione che dà luogo ad un risultato utile all’avanzamento dell’avventura.

Una piacevole sorpresa viene dalla musica, formata da brani liberamente reperiti dagli autori Bjorn Lynne e Kevin MacLeod che hanno rilasciato alcuni brani di loro esecuzione come file midi liberamente scaricabili senza necessità di pagamento dei diritti per fini non commerciali. Alcuni temi sono noti, come Chattanooga Choo Choo di Glenn Miller.

Ogni locazione ha la sua musica assegnata e, dato che non si persisterà a lungo in una stanza, alla fine la sensazione generale è piuttosto piacevole. Forse però si sarebbe potuto attingere ad una colonna sonora che avesse avuto di più un carattere comico.

Da segnalare, nel mezzo delle gag e battute di non eccelsa comicità, un piccolo gioiellino di filmato, citazione (volontaria?) del ballo degli scheletri di Monkey Island 2, della Skeleton dance di un cartone della Disney, e della canzone finale di Discworld 2That’s death” (a sua volta parodia di “That’s Life” di Frank Sinatra) interpretata appunto da uno scheletro. La canzone è un vecchio titolo anni  ’50 a firma di Fred Buscaglione, “Giorgio del lago Maggiore”.

Qui, non ho vergogna ad ammetterlo, il recensore si è rotolato dalle risate.

Veramente ben fatto ed ideato; è con questo stile e questo tipo di ironia che ci sarebbe piaciuto giocare tutta l’avventura; per il futuro ci si permette di consigliare di continuare in questa direzione. Per chi non avesse il tempo di giocare tutta l’avventura, ma vuole vedere questa piccola ma incisiva realizzazione, essa è presente come file *.wmv come tutti gli altri filmati nella cartella del gioco.

Enigmi.

Gli enigmi sono uno degli elementi strutturalmente imprescindibili di una avventura grafica. In Space Hunter ne abbiamo una grande quantità che si basano sul “prova tutto con tutto”, alla fin fine.

Non ci risulta ben chiaro ad esempio il perché un lucchetto che rifiuta di aprirsi scassinandolo con qualsiasi oggetto dovrebbe saltare sparandogli una caramella “ciancicata” fino a ridurla a forma di proiettile. O perché scarabocchiare con un pennarello rosso un dispositivo ad un incrocio per farlo andare in tilt?

O perché un copri fronte, senza alcun altra indicazione né visiva né testuale, dovrebbe riflettere la luce? (perché il coprifronte di Naruto è metallico? E che ne posso sapere io che vedo tutto ciò che è giapponese, tranne la cucina, come il fumo negli occhi? Almeno si metta un suggerimento quanto si fa “Guarda Coprifronte” con risposta: “E’ riflettente!”. Dall’immagine nell’inventario dell’oggetto non si evince nulla.) O ancora perché da un bretzel combinato con un jetpack rotto e poi con uno gnorkettino (!) si ottenga un jetpack funzionante.

“Enigma demenziale” non vuol dire “enigma assurdo”. In ogni momento per la risoluzione  si deve avere un indizio che ci possa far esclamare alla fine: “Ma certo, come ho fatto a non pensarci?”. Così come, quanto mi vengono assegnate le consuete “missioni” o “liste di cose da fare” (famose le tre prove per diventare pirata di Monkey Island) devo poter avere l’occasione di riepilogarle o sentirle ripetere, da un dialogo, da un appunto, o da un diario automatico. Ad aggravare la situazione, c’è il problema del non perfetto puntamento degli hotspot, unito ad un certo numero di hotspot millimetrici (pixel-hunting), che rende la risoluzione di alcuni enigmi puramente casuale.

Sia detto una volta per tutte: non riuscirete a venire a capo di Space Hunter senza consultare un walkthrough; ci è capitato di venire a conoscenza di alcuni oggetti da prelevare affetti da pixel hunting solo dalla soluzione presente sul sito, ed anche in questo caso avere difficoltà a puntare l’oggetto, perché oggettivamente invisibile o indistinguibile, sullo schermo (esempio, la freccia sul cartello turistico, o la roccia della talpa gigante).

Anche l’applicazione degli oggetti agli hotspot è discutibile: perché dei tappi per le orecchie funzionano sulle note fastidiose prodotte da un chitarrista punk, e non sul protagonista Kolt, se poi è Kolt che se le ficca nelle orecchie?

L’astrusità della maggior parte degli enigmi spezza parecchio l’andamento della storia: avremmo preferito senz’altro che ci soffermasse di più e si spendesse più tempo (lo stiamo ripetendo allo sfinimento) nell’aggiungere nei dialoghi, nei commenti emessi guardando gli oggetti dell’inventario e gli hotspot un maggior numero di indizi che rendessero più logica la risoluzione anche a discapito della durata complessiva di gioco.

L’avventura demenziale deve far ridere, non esaurire il giocatore nel rincorrere una logica (che può essere anche surreale, ma ci deve essere) che non c’è.

Storia.

La trama, a dispetto della natura amatoriale del titolo, è articolata e ricca di colpi di scena. Molto per sommi capi, il protagonista è Kolt, un cacciatore di taglie di cui nel prologo (in realtà presentato erroneamente come “Epilogue”, nell’intro) possiamo  rivivere il suo primo caso; tornati alla narrazione al presente, Kolt verrà “incastrato” da un criminale che riesce a far credere che Kolt abbia liberato tutti i criminali della città mettendosi dalla parte del crimine. Kolt dovrà dunque tra alterne vicende ristabilire l’ordine per riabilitarsi.

Gli spunti e le citazioni (un intero capitolo è ispirato a Dune) di film e classici del mondo noir e cyberpunk si sprecano. Sulla resa di uno dei fini di un’avventura grafica demenziale, cioè far ridere, abbiamo qualche perplessità; non solo alcuni riferimenti ci sembrano piuttosto legati a contesti e realtà abbastanza di “nicchia” (la Quanza (che supponiamo sia una traslitterazione di “kwanzaa”, festività moderna afroamericana), l’”Hannukà”, festività ebraica, o certa oggettistica ninja), ma in alcuni casi ci è sembrato che si facesse riferimento a vocaboli regionali (spaciuco) se non amicali o di comitiva degli autori.

L’avventura spesso non riesce a raggiungere il suo fine …

… di far ridere, marcando troppo…

Il problema è che le battute sembrano essere state buttate giù di getto e molte, nel migliore dei casi, supponiamo con l’intenzione di essere “aggiustate” in un secondo momento. Ci pare che questo, per la qualità e la maturità, sia un testo “adolescenziale”, con ciò intendendo un “prima opera”, sebbene esistano degli indizi che lasciano credere che si sarebbe potuto fare benissimo meglio. Anche qui, lo ripeteremo sino a farci sanguinare la lingua, si sarebbe dovuto avere la pazienza di spendere ulteriore tempo per studiare con più calma e in un momento di maggiore ispirazione molte delle battute.

Non basta l’assurdità o l’astrusità per fare comicità.

C’è uno stuolo intero di personaggi, alcuni dei quali dalle oggettive potenzialità comiche, che non vengono, nel nostro giudizio, adeguatamente sviluppati e sfruttati per veicolare la parte comica dell’avventura. Quello che difetta, intendiamo dire, è una maggiore regia che orchestri al meglio le interazioni e i dialoghi tra i vari personaggi e dia quel senso di “commedia” (niente di male se fosse “dell’arte”) che deve avere un titolo del genere. Non sappiamo desumere se si sia scritta precedentemente una sceneggiatura (sì, una sceneggiatura: fare un’avventura grafica non è, in linea di principio, molto dissimile dallo scrivere un film) e se tutti i dialoghi fossero stati buttati giù con carta e penna (o video e tastiera, adesso non stiamo a disquisire), ma da molti indizi ci pare proprio di no: e questo è un peccato, perché il gioco ne soffre molto: speriamo che questi difetti siano stati evitati nelle avventure prodotte in seguito, e se no, invitiamo l’autore a riprendere in mano con coraggio il codice e lavorare di pialla e lima, perché ne vale veramente la pena.

…la componente demenziale.

Anche se, a dire il vero, le cose migliorano, pur essendoci ancora dei residui di problemi un po’ in tutti i comparti, decisamente nell’ultimo capitolo, i dialoghi sono più scorrevoli, tornano alcuni personaggi incontrati precedentemente dando una profondità maggiore all’intreccio e fornendo ulteriori spunti comici, gli enigmi, pur restando di stampo demenziale, migliorano, restano purtroppo gli hotspot affetti da pixel hunting, la storia converge verso l’inevitabile inseguimento e sfida finale, certe battute un paio di sorrisi li strappano.

Considerazione e giudizio finale, tirando le somme: non è possibile considerare quest’avventura un prodotto finito, invitiamo l’autore/gli autori a riprenderla in mano e ripulirla dai difetti, perché ha ottime possibilità di uscirne fuori, pur essendo amatoriale, una buona avventura, a patto che si arricchiscano, in profondità, dialoghi e indizi e si correggano alcuni difetti grafici evidenziati sopra.

Questa sinceramente non l’ho capita. Quello accanto al protagonista è lo Yellow Budger che dovrebbe andare in tilt se ci scrivete sopra col pennarello rosso. Bello ed accurato il fondale; peccato che lo sprite lo percorra in maniera discutibile.

Lo scontro finale

Il quadro generale italiano nel quale Space Hunter si colloca, quello delle avventure grafiche comiche/demenziali amatoriali, per di più italiane, pur essendo sparuto, non è completamente deludente: possiamo rivolgerci a “La Terribile Minaccia degli Invasori dall’Audiogalassia”, ai vecchi titoli della Nexus Entertainment (Wonder World) e a quanto riuscite a trovare googlando “avventura grafica amatoriale italiana”.

Voto.

Ahahahah.

Ci cascate sempre.

Non metto voti.

Ma so che ho l’odiosa tendenza a fare il “professore”.

E’ che mi disegnano così.

Eeeeh? Cosa? – Lo Sviluppo di Sanitarium di DreamForge (2/2)

(…continua)

Il racconto dei programmatori

Inizialmente avevamo pianificato di convertire un motore per avventure grafiche esistente. La prototipazione iniziale dimostrava che era più probabile una nomination all’Oscar per Jackie Chan. Così decidemmo di creare un motore nuovo, riutilizzando il codice esistente laddove possibile. Usando codice da altri prodotti finiti, evitammo la seccatura del debug. Ah, ah. Che spudorata menzogna. Però dovemmo preoccuparci di meno, sapendo che aveva funzionato in qualche modo.

Il motore di base era completamente allo stadio iniziale, lasciandoci tempo nel progetto per sparapanzarci nelle sdraio a sorseggiare tequila dalle bocce dei pesci. In realtà non è vero niente. Una volta  terminato il motore, la maggior parte del parte del tempo la spendemmo a creare i livelli. Un sistema di linguaggio per i livelli basato solo su azioni, flag e controllo del flusso semplificava il lavoro. Il tempo restante (quelle ore di solito riservate alle funzioni fisiologiche fondamentali come il sonno) era dedicato al codice di interazione e alla programmazione dei casi particolari, come le finestre degli enigmi e le aree di azione. Avevamo previsto in un primo momento di creare un editor per gli enigmi, ma non ci fu abbastanza tempo. Afferrando il toro per le corna, scrivemmo direttamente nel codice ogni enigma.

Decidere a quale codec video affidarci fu come tagliare le unghie a un leone. Il primo che considerammo, True Motion, aveva una migliore qualità, ma difettava di supporto e facilità di implementazione. Il secondo, Smacker, aveva le caratteristiche opposte. Non potevamo starcene ad aspettare che qualcuno raggiungesse l’equilibrio di cui avevamo bisogno perché, primo, non avevamo tempo, secondo, non sapevamo se qualcuno ci fosse riuscito prima o poi. Alla fine decidemmo nel corso dello sviluppo: supporto e facilità d’implementazione vinsero sulla qualità del video.

Per il test di Sanitarium, escludemmo completamente l’ipotesi di tracciare i bug su carta. Sia i nostri tester interni che il gruppo della ASC Games usavano FileMaker Pro 4.0 per generare, ordinare e tracciare lo stato di tutti i bug. Dal momento che usavamo lo stesso programma, potevamo scambiarci le basi dati facilmente, fare la dovuta valutazione delle priorità, confrontarle, ed eliminare i doppioni. Sanitarium ad oggi è stato il titolo della DreamForge più accuratamente testato.

Ma anche con questo intenso regime di test, il gioco raggiunse gli scaffali con l’infame bug dell’accesso vietato del Livello 2. Se il giocatore girava per la città per un certo tempo e si verificavano determinate condizioni, era impossibile entrare negli edifici. Questa fu una grande delusione. Nelle innumerevoli ore/persona dedicate al test tra quelli della ASC Games e della DreamForge, nessuno incontrò questo bug. Ciò racchiude una importante morale, o cicala. Non esiste gruppo di test che possa scovare un bug meglio di diecimila acquirenti iniziali.

Il Dolce …

Sanitarium ha rappresentato un successo significativo per la DreamForge sotto diversi aspetti. Molti di questi hanno a che fare con il nostro personale senso del risultato nel fare questo gioco, ma altri li abbiamo appresi strada facendo.

1. BRING IT ON HOME. Essendo un gioco progettato internamente, a Sanitarium fu dedicato un enorme dispendio di energia e di amor proprio. Ricordo che questo progetto cominciò da un gruppo di persone che incontrandosi dopo l’ufficio si dicevano: “Non sarebbe forte se realizzassimo il gioco a cui ci piacerebbe giocare?” Anche dopo mesi di lavoro, non eravamo sicuri se il gioco avrebbe mai raggiunto gli scaffali. Appena il duro lavoro del gruppo iniziò a dare frutti, l’entusiasmo e la forza dell’intera compagnia aumentò, sostenendoci nei periodi difficili. Quella sensazione di possesso personale di un prodotto non si può sottovalutare. Essa ha caratterizzato l’esperienza di Sanitarium di noi sviluppatori.

Non solo, il nostro personale ci offrì un gruppo di discussione a costo zero. Nella fase iniziale del progetto, le idee dei progettisti saltavano da una parte all’altra come delle vecchie palle di gomma. Ci servivano altre opinioni dall’esterno per dare prospettiva al progetto. Invitammo dei piccoli gruppi di impiegati della DreamForge a unirsi a noi nella stanza di progettazione. Come in una caverna degli orrori a Disney World, conducemmo questi gruppi attraverso il gioco enigma per enigma, colpo di scena per colpo di scena. Le domande e i commenti ci fornirono preziose informazioni su ciò che sembrava interessante e su ciò che sembrava poco chiaro.

Tra i risultati di queste revisioni vi fu che si fece dolorosamente chiaro che il Livello 6 era insufficiente. Era come se Al Gore fosse entrato nella stanza. Alla gente si appannavano gli occhi in quel punto della carrellata; si moltiplicavano gli sbadigli. Ci guardavamo l’un l’altro e dicevamo “Così non va bene.” Dunque chiedevamo alla gente cosa sarebbe risultato interessante, ingegnoso e inquietante? Gli insetti, sembrò essere la risposta giusta. Basato sulle risposte del personale, il Livello 6 di Sanitarium è risultato più solido e divertente del nostro progetto iniziale.

2. FILM AMATORIALI. Dagli inizi del ciclo di sviluppo, volevamo dare a Sanitarium un’atmosfera cinematografica dark. Nella maggior parte dei giochi, i filmati sono considerati in male necessario o peggio – una mostra dei plug-in del momento volta a stupire gli spettatori ed distogliere l’attenzione dallo svolgimento del gioco. Eravamo decisi a caratterizzare uno stile delle scene animate, per integrarle nel gioco. Volevamo specialmente che i flashback impattassero emotivamente sullo spettatore, perché avevano  a che fare direttamente con la vita, l’amore e le sofferenze di Max. Per portare avanti l’idea, girammo le scene imitando il formato letterbox dei film. Il nostro coordinatore dell’animazione , Marty Stoltz, attinse ai suoi trascorsi cinematografici nel guidarci nella giusta direzione. Anche Joe Skivolocke fece ricorso alla sua esperienza di post-produzione per gli effetti di tutti i video dei ricordi. Molto lavoro andò via assicurandosi di un corretto uso dell’inquadratura e nella post-produzione dei filmati, in particolar modo i flashback, che dovevano proprio sollecitare emozionalmente il giocatore.

Tutti i filmati vennero al mondo come storyboard, attentamente prodotti in Adobe Premiere e passati ai grafici. Il gruppo 3D lavorò sugli storyboard per creare dei semplici .AVI. Il nostro gruppo di post-produzione lavorò su questi .AVI, ritoccandone i contorni ed applicando gli effetti speciali con Adobe Photoshop, Adobe After Effects, e Strata MediaPaint. Qualche materiale in  .AVI originario è stato poi scartato alla fine (perché non funzionava, perché qualcosa non andava, perché si vedeva un addetto alle luci che mangiava un tramezzino sullo sfondo). Inoltre, il nostro shooting ratio era di 3:1 (per ogni secondo di materiale di ripresa, scartavamo 3 secondi) – che non è male se si consider ache un film ha in media uno shooting ratio di 20:1. Le scene rifinite che entrarono nel gioco erano le migliori che la DreamForge avesse mai prodotto, tenute insieme tematicamente da un’unica visione coerente.

3. PROGETTAZIONE A MODULI. Avevamo lavorato già tutti su altri giochi e avevamo familiarità con la potenziale minaccia insita nel tagliare livelli, enigmi e tutto ciò che sembrava sacrificabile quando il momento si faceva critico, non importa quanto filu’e ferru potevi bere. Dall’inizio della progettazione, eravamo preparati a simili evenienze avendo strutturato il gioco secondo uno schema modulare. Avevamo suddiviso il gioco in parti che avrebbero aggiunto gameplay e fatto progredire la storia, ma che non avrebbero sminuito complessivamente il gioco se fossero stati tolti. Alla fine, eravamo in grado di ridurre al minimo i tagli. Una vasta area di combattimento e alcuni puzzle complicati fecero il volo,  altrimenti i tagli sarebbero stati ridotti. La progettazione modulare sino dall’inizio del progetto consentì che il gioco finale rimanesse coerente alla sua visione iniziale.

4. MA CHE BELLE RISORSE. Per prova il capo programmatore Chad Freeman implementò un sistema di gestione degli oggetti utilizzando un database Paradox, che desse una vista centralizzata di tutti gli oggetti del gioco in un solo luogo. Altri strumenti sviluppati in Delphi e Visual C++ accedevano gli oggetti da questo database. Questa soluzione presentò diversi benefici. Per prima cosa, potemmo facilmente le risorse e prendere delle adeguate contromisure se il totale complessivo della capacità delle risorse bucava il massimo prestabilito per livello. Potevamo anche vedere il nome del file e la descrizione di ciascuna risorsa. Il sistema del database ci consentiva di raggruppare le risorse per livello od altro criterio. Un livello aveva centinaia di file sonori e grafici. Cercare una risorsa in particolare per filename era come trovare il ragazzo grasso con la maglietta di Star Trek ad un raduno di fantascienza. Naturalmente, la possibilità di ordinare le risorse velocemente faceva risparmiare tempo ed energia.

Poiché questo processo era sperimentale, non eravamo in grado di sfruttare a pieno il sistema. Per esempio, i programmatori erano gli unici che utilizzavano il sistema nel processo di creazione dei livelli. Ad ogni modo, Chad Freeman alla fine estendeva il sistema in modo che i grafici e i tecnici del suono potessero aggiungere risorse al database e i creatori di livelli potessero accederli direttamente da lì, eliminando spazio disco superfluo. Inoltre, il sistema poteva anche contenere informazioni sui livelli, consentendo di estendere ai livelli stessi  le medesime liste, ordinamenti, ed altre utilità. In generale, lo sviluppo di Sanitarium non fece mai uso completo di questi strumenti di gestione del database. Via via che i contenuti di un gioco andranno crescendo (DVD ed oltre), l’uso di questi strumenti aiuterà sempre di più gli sviluppatori.

Abbiamo anche usato Visual SourceSafe per la prima volta durante lo sviluppo di Sanitarium. Tradizionalmente, i programmatori sono sempre stati assillati dal lavoro estremamente dispendioso e noioso dell’unione manuale dei sorgenti. Ora non più. Come un raggio di luce divina che llumina le nostre altrimenti malsane e buie squarcia le oscurità dei nostri stanzini, SourceSafe ha reso l’assemblaggio del codice molto più semplice e sicuro. SourceSafe presenta anche altri vantaggi, come la possibilità di versionare precisamente il codice, in modo da poter tornare indietro dall’inevitabile “passo falso” di programmazione.

Abbiamo scelto proprio SourceSafe perché consente degli accessi multipli; la struttura dei nostri file C prima dell’adozione di SourceSafe era tale che era comune che più di una persona lavorasse su uno stesso file contemporaneamente. SourceSafe consentiva anche di ramificare un progetto, lasciando che uno lavorasse su una demo, mentre un altro continuava a sviluppare il gioco. Il progetto poteva poi essere ricongiunto più tardi, in modo che le correzioni nella demo potessero essere integrate nel sorgente principale.

5. PROJECT MANAGEMENT  DA IMPAZZIRE. Usando Microsoft Project e le sue contorte tabelle di tracciamento preparate in Microsoft Word, il capoprogetto Scot Noel riaggiornava il progetto ogni una-due settimane. Questo metodo veniva applicato a tutti gli elementi del gioco, dagli enigmi alle modifiche grafiche alle implementazioni di codice. I diagrammi GANTT documentavano Il flusso di lavoro tra le direzioni e le persone. Queste ci consentivano di rispondere prontamente ai problemi più critici mostrando quanto il ritardo di consegna di un singolo oggetto spostava in Avanti la data di rilascio finale di giorni o settimane.

I percorsi critici venivamo tracciati usando i diagrammi PERT di Microsoft Project. Vedendo queste reti dedaliche prossime alla complessità infinita, molti di noi cedettero che Scot fosse divenuto, finalmente ed irrevocabilmente, pazzo. Ma una volta penetrati i misteri del diagramma PERT, ci rendemmo conto del valore del tracciamento delle interdipendenze degli obiettivi attraverso i percorsi critici. Quando direzioni diverse o anche singoli individui, raggiungevano un altro o avanzavano di quanto previsto, il percorso critico cambiava. Forte di questa conoscenza, Scot poteva andare da un qualsiasi programmatore e dirgli “Il percorso critico sta passando proprio da te in questo momento.”

Un tale monitoraggio aiutava a dirigere il carico di lavoro e a motivare le giuste persone, lasciando che gli altri andassero a casa a farsi una bella dormita. Come tutti i sistemi, I diagrammi PERT non erano perfetti. Alcuni sembravano stare sempre sul percorso critico, specialmente Chad Freeman, il capoprogrammatore. Tutti noi qui in DreamForge speriamo che Chad possa lasciare presto l’ospedale. Abbiamo già montato il respiratore accanto alla sua scrivania.

6. L’ASSENSO DELL’EDITORE. Il nostro editore, ASC Games, credeva in ciò che stavamo cercando di realizzare e ci forniva un prezioso contributo nello sviluppo. Si comportavano come se stessero sposando la nostra visione, piuttosto che semplicemente comprandola. Per lo più, non interferirono, e richiesero solo modifiche che erano sicuri che avrebbero aumentato in maniera significativa la qualità e la vendibilità del gioco. Travis Williams, produttore esecutivo di Sanitarium, mise anima e cuore nel progetto – per non parlare di tutti i giochi e giocattoli in anteprima che ci mandò. Gli fummo così grati che mettemmo la sua testa nel gioco.

Eravamo molto contenti dell’impegno della ASC Games nel promuovere Sanitarium. La sola scatola è un’opera d’arte, e il manuale ha ricevuto apprezzamenti per la sua incisività e semplicità. Gli annunci pubblicitari sono di grande effetto e rispecchiano lo spirito del gioco. Un fatto semplice per cui il gruppo sarà eternamente grato: la direzione marketing della ASC Games non rivelò la trama del gioco sulla scatola o nel manuale. E’ sempre un sollievo quando vedi che il mistero al centro del tuo gioco non viene stampato a chiare lettere capitali sul retro della scatola.

…e l’amaro.

Se Sanitarium rappresenta un successo fenomenale per noi qui alla DreamForge (sia professionalmente che personalmente), sfortunatamente si presentarono alcuni scogli insormontabili sul percorso. Noi ci ripetiamo continuamente: quel che non ci ha uccisi, ci ha rafforzati. Chi se ne frega della cicatrice.

1. ANIMAZIONI. Per via della dimensione del gioco, ogni personaggio aveva un numero limitato di frame di animazione. In molti casi, ciò comportava che il movimento sembrasse rigido e innaturale. Ripensandoci, avremmo preferito delle animazioni più fluide con più angolazioni – specialmente per il protagonista, Max. Se avessimo tenuto conto di ciò da prima nel corso del progetto, avremmo potuto avere l’opportunità di apportare correzioni. Quando ci accorgemmo che otto angolazioni sembravano un po’ rigide, era troppo tardi. La limitatezza delle angolazioni causò anche problemi ai giocatori nel guidare Max per i livelli. Spesso rimaneva incastrato negli angoli, per poi marciare sul posto come un mimo impazzito o frustrava il giocatore con una litania di “Non posso andare in quella direzione.”

Fornire delle illuminazioni coerenti tra le animazioni standard dei personaggi (immobile, camminando, usando, e così via) e le particolari animazioni che richiedevano interazione con l’ambiente (come prendere a calci la porta della scuola) era un altro incubo. Queste animazioni erano state fatte da grafici differenti mesi prima, e ciò fu una lotta continua dall’inizio alla fine. Un enorme quantità di tempo fu spesa a mettere a posto qualcosa invece che a far avanzare il progetto.

2. ZONE DI COMBATTIMENTO. Le scene di azione avrebbero avuto bisogno di maggior attenzione. Erano importanti nel guidare il ritmo della storia, ma non avevano l’atmosfera che cercavamo nel prodotto finale. L’idea originale dietro queste aree era basata su uno dei primi titoli della DreamForge, Veil Of Darkness. Aveva delle magnifiche aree di combattimento che contribuivano a rompere il ritmo tra gli enigmi. Comunque, in Sanitarium, vari fattori ci costrinsero ad annacquare le zone di combattimento o in alcuni casi a tagliarle del tutto. All’inizio avevamo progettato una grande area di combattimento per il livello del Favo. Speravamo di fare di “Grimwall vs. il Favo” una delle aree di combattimento più divertenti ed integrata, ma fu tagliata per varie ragioni.

3. STURM UND DRANG. Quando si ha una compagnia di quaranta – cinquanta persone. È impossibile fare qualcosa senza pestare I piedi a qualcuno. Sanitarium fu costruito da una squadra di progettazione che in parte si formò spontaneamente e in parte fu messa insieme da Chris Straka, il capo dello sviluppo creativo. Alcuni impiegati (per lo più Chris) avevano progettato da soli i nostri precedenti titoli. Ma avevamo deciso che il team di progettazione era la strada da percorrere. Mentre il gruppo di progettazione aveva le potenzialità per fratturare la visione unificata di un gioco, i suoi vari membri alla fine avevano finalità ed interessi complementari, dando più spessore al gioco. Questo è un modo elegante per dire “La squadra discuteva molto, ma poi si inventava delle soluzioni migliori come gruppo.”

Le difficoltà non finivano qui. Una volta che Sanitarium divenne un progetto a tempo pieno, molti membri dello staff si lamentarono, “Perché non ho avuto l’opportunità di stare nel gruppo di progettazione?” Si generò una certa tensione perché la gente si sentì come snobbata. Sfortunatamente, un gruppo di progettazione raggiunge il punto di massa critica oltre i sei membri. I gruppi di progettazione lavorano grossomodo alla stessa maniera delle auto dei pagliacci. Troppa gente ammassata nella progettazione, avrebbe di sicuro portato un processo giù instabile ad un brusco stop. Allo stesso tempo, la struttura di potere del personale di Sanitarium aveva creato senza volere diseguaglianze tra i dipendenti.

DreamForge imparò molto sui gruppi di progettazione da Sanitarium, e stiamo ottenendo soddisfazioni nel mettere insieme i gruppi di lavoro sugli attuali progetti. Abbiamo preso le misure necessarie per riconoscere aspettative e spirito d’iniziativa, e distribuito le responsabilità a chi voleva prendere posizioni direttive. Ora, più che dire: “Perché non mi hanno considerato?” tutti si lamentano: “Chi me l’ha fatto fare?”. E’ un bel divertimento.

4. TEMPI DI CARICAMENTO. Se da un lato i lunghi tempi di caricamento dei livelli furono una limitazione di progettazione accettata sin dall’inizio, un sistema per gestire meglio la memoria e consentire la trasmissione di una maggior quantità di dati dal CD avrebbe potuto avvantaggiare il gioco. I tempi stretti fecero sì che un tale sistema fosse impossibile da realizzare. Uno schema di gestione della memoria più sofisticato avrebbe consentito d’avere tempi di caricamento minori, livelli più grandi, e così via.

5.  I NUOVI COMPAGNI DI CLASSE. Sanitarium è un gioco enorme. Ci ha lavorato molta gente, il che significa maggiori sforzi per coordinare ed organizzare il lavoro di ciascuno. Far prendere familiarità alla gente con la visione del gioco dal punto di vista grafico e progettuale è stata una vera sfida. A volte, fare andare tutti d’accordo era un’ardua impresa. Specialmente quando arrivava gente nuova sul progetto.

Si spendeva molto tempo per far capire alla gente lo stato del progetto e la direzione che stavamo percorrendo. Un nuovo grafico chiedeva: “Perché sto facendo questo tizio con un occhio solo?” e noi rispondevamo: “Perché, non te l’ha detto nessuno?” Facemmo l’errore di pianificare i tempi di progetto come se i nuovi assunti, dopo un breve periodo di apprendistato, fossero capaci come le nostre persone più esperte. Alcuni di questi stavano svolgendo compiti amministrativi e di formazione, quindi non stavano producendo molto. Gli oggetti grafici prodotti dalle nuove leve avevano spesso dei problemi una volta giunti nelle mani dei programmatori. Ciò significava fare le cose due volte, a volte tre. Le previsioni e i flow chart andavano in picchiata, tenuto conto del flusso rappresentato dalla consegna delle risorse, l’identificazione dei problemi, la loro correzione e la reimplementazione delle risorse. Poiché i ritardi degli oggetti grafici stavano rallentando la programmazione, provammo ad usare materiale grafico temporaneo. Ciò non funzionò perché creare della grafica temporanea utilizzabile dai programmatori si rivelò avere lo stesso ordine di grandezza in termini di tempo di quella definitiva. E, come ciliegina sulla torta, perdemmo due grafici durante la produzione.

Anche se Sanitarium ebbe dei tempi di produzione più lunghi di ogni altro precedente progetto DreamForge, c’erano ancora alcune cose che ci sarebbe piaciuto ritoccare o migliorare. Per di più, affrontammo un mucchio di situazioni difficili per fare in tempo. La quantità effettiva di grafica richiesta per il gioco ci sommerse quasi.

Fine. (Liberamente tradotto da un’intervista pubblicata su Gamasutra. Tutti i diritti appartengono a Gamasutra)

Lo Sviluppo di Sanitarium di DreamForge (1/2)

Vi presento un’interessante resoconto relativo alla nascita ed allo sviluppo di Sanitarium (l’avventura grafica, non la canzone) contenuto in una vecchia (1998, praticamente subito dopo l’uscita del gioco) intervista e mai tradotta in italiano.

Sanitarium di DreamForge

Sanitarium è un’avventura grafica, da un soggetto originale, piena di pazzia, illusione, ed angoscia. La medesima cosa si potrebbe dire delle sue fasi di sviluppo. Sanitarium è stata sviluppata dalla DreamForge Intertainment Inc., di stanza nel cuore di Greensburg, in Pennsylvania. La DreamForge dà lavoro a circa 45 persone che lavorano su tre-quattro progetti per volta. Abbiamo già sviluppato un’avventura grafica che si chiamava Chronomaster, ed il nostro personale ha una forte esperienza  nello sviluppo di GDR per computer. Sanitarium è stato per un punto d’arrivo, soprattutto perché il progetto è nato internamente, e ci abbiamo messo dentro molto di noi stessi.

Il Racconto dei Progettisti

Sanitarium è nato dal semplice desiderio  di creare qualcosa di speciale, qualcosa di diverso. Circa due anni fa, alcuni di noi in DreamForge si sentivano un po’ fusi. Ci eravamo stancati di giochi di tendenza,  avevamo bisogno di un’idea nuova da scavare con entusiasmo. Cosa ancor più importante, volevamo fare un gioco divertente nella sostanza e nello spirito.

Così, mangiando qualche cheeseburger tiepido, Chris Straka (il Direttore dello Sviluppo Creativo) chiese a Chad Freeman (Capo Programmatore), Jason Johnson (Coordinatore Grafico 3D), Mike Nicholson (Grafica e Progettazione), Eric Rice (Direttore Grafico), e Tracy Smith (Coordinatore Grafico di Post-Produzione) quali giochi preferissero e perché. Ci furono delle proposte, seguirono delle controproposte, i cheeseburger si fecero freddi e solo occasionalmente venivano addentati. Discutemmo delle altre forme di intrattenimento che avevano  a che fare con il gioco che avremmo volute fare. Si citarono film come Allucinazione Perversa, Seven, e L’Esercito delle Dodici Scimmie , e si parlò di programmi televisivi come Oltre i limiti e degli episodi originali di Ai Confini della Realtà. Ad un certo punto della discussione, fu chiaro che volevamo realizzare un’avventura grafica.

Comunque, come prevedibile, ognuno di noi aveva una propria idea su cosa avrebbe dovuto vertere il gioco. Quando il suono delle teste umane che cozzavano una contro l’altra assunse un livello assordante, Chris Straka propose di fare un gioco che unisse tutte le idee. Disegnò una semplice ruota su un pezzo di carta, con un mozzo centrale e dei raggi. I raggi sarebbero diventati alla fine i diversi mondi contenuti nel gioco. Il mozzo, la struttura centrale della trama che univa tutti i mondi, era ancora da decidersi. Presto capimmo che queste idee separate potevano essere sviluppate per mezzo di episodi psicotici visti attraverso l’occhio di un personaggio affetto da disturbi mentali. Da allora in poi, il progetto ebbe il nome in codice Asylum. Avrebbe dovuto essere questo il titolo, ma poi scoprimmo che era già stato usato da qualche altra parte. Così lo intitolammo Sanitarium.

Una volta partita sul serio la fase di progettazione, Sanitarium fu in cima ai nostri pensieri ventiquattr’ore al giorno. Ognuno di noi ha profuso moltissimo impegno nel progetto, stringendo i pugni, col batticuore, fino al mal di milza. Era una fase gratificante per noi, perché la maggior parte del gruppo era nuova all’esperienza della progettazione. Talvolta alla fine della giornata rimaneva  qualche questione in sospeso – cose relative a un elemento della storia o a problemi con la configurazione di un certo enigma. Più di un progettista è andato a letto sconvolto con visioni di gargolle e bambini deformi che gli giravano attorno. Quando si faceva giorno, nuove angolazioni e prospettive li facevano sembrare vivaci lampeggianti alla luce del sole nascente.

Sapevamo di star lavorando su qualcosa di valido. Sebbene la storia principale sia venuta solo in un secondo momento rispetto a quei primi incontri di progettazione, eravamo decisi a creare una trama principale che tenesse il gioco insieme e che evocasse delle forti emozioni nel giocatore. Partendo da diversi appunti di progettazione, Mike Nicholson, coordinatore grafico e progettuale, si assunse il grave onere di scrivere la sceneggiatura e l’albero dei dialoghi. Come se fosse catapultato all’improvviso in un film di Roger Corman, Mike si ritrovò velocemente immerso fino al collo in battute scarse e personaggi mediocri. Dopo parecchi giorni di smarrimento, capì che il problema stava nei mondi di gioco stessi. Non avevano una vera storia alle spalle, rendendo così impossibile il creare dei dialoghi realistici e dettagliati per gli abitanti dei mondi. Ritornò sul documento di progettazione e scrisse un retroscena per ciascuno dei mondi, rimpolpando i temi di fondo e i profili dei personaggi,  e limando tutte le incongruenze. Mike promosse anche il legame Sarah/Max e  abbozzò la tristemente nota “scena della morte”. Quando lesse la sua proposta al team di progettazione, tre di loro si misero quasi a piangere. Con una storia solida a posto, i personaggi avevano tutti dei retroscena sostanziosi dai quali attingere e dei punti di riferimento comuni ai quali indirizzarli. Dal quel punto in poi la sceneggiatura si fece relativamente semplice.

Dopo che Mike mise insieme una prima bozza di sceneggiatura, la DreamForge assunse Chris Pasetto in qualità di scrittore del progetto. Il suo compito principale fu di rifinire tutti i personaggi e le sceneggiature dei filmati. Via via che il processo di sviluppo procedeva, i copioni divennero più complessi (allorché notavamo parti mancanti) poi più semplici (cercando di snellirli). Alla fine, i file del copione sembravano come pezzi di carne di testo macellato sparsi alla rinfusa come scarti di carne molle.

Per mantenere un flusso continuo di gioco e di storia, Chris dovette bilanciare la quantità di dialogo svolto da ogni personaggio non giocante [d’ora in poi PNG] con il numero di PNG distribuiti nei livelli. In fase di beta test, i collaudatori si lamentarono che molti dei dialoghi erano troppo lunghi e che gli alberi delle parole chiave erano troppi complicati in taluni casi. Inoltre, i personaggi potevano giungere a parlare di argomenti che sembravano stranamente inappropriati, saltando da un argomento all’altro come in un pessimo notiziario. Dato che molti di noi qui tendono a lavorare così comunque sia, non trovavamo ciò molto confusionario.

Travis Williams, nostro produttore esecutivo, insisteva  affinché tagliassimo alcune delle interazioni e legassimo molte parole chiave tra loro per evitare confusione. Molto del dialogo originale era semplicemente d’atmosfera e dispendioso per il giocatore in termini di tempo per farsi strada in cerca di risposte reali. La versione finale aveva un flusso narrativo migliorato e un miglior bilanciamento tra dialoghi ed azione.

Ci preoccupavamo continuamente che i contenuti emotivi del gioco si perdessero nel mezzo espressivo. Il nostro intento era far provare i brividi al giocatore. Ci prendemmo del tempo per riflettere a cosa volevamo che il giocatore provasse in ogni livello, quale messaggio e stato d’animo volevamo far passare. I nostri sforzi nel creare un’atmosfera coesa comprendevano non solo una buona trama, ma anche un’esperienza sonora immersiva.

Sanitarium era il primo prodotto della DreamForge ad utilizzare un sonoro stereo. Il sistema sonoro a sorgente puntiforme produceva un effetto molto naturale in ogni livello. Ma la sola tecnologia non può fare grande il suono senza le giuste persone che la sfruttino. Steve Bennet, il compositore della musica e degli effetti sonori, fece uno splendido lavoro con la colonna sonora. Lavorando su una lista stilata dal gruppo di progettazione,  Steve frugò un’enorme libreria CD di suoni per gli effetti sonori necessari. Poi elaborò i suoni usando Cool Edit Pro e Sound Forge, a volte effettuando più passate su un effetto sonoro per raggiungere l’atmosfera del livello. La musica suggestiva che introdusse, tutte composizioni originali composte con una tastiera Kurzweil, dette ai livelli uno stile particolare che elevò l’atmosfera inquietante.

Tuttavia, il doppiaggio poteva essere migliorato. E’ difficile competere con altri sviluppatori che si possono permettere attori di fama e soddisfare le attese di tutti. Questa non vuole essere una scusa, ma una semplice considerazione di mercato. Ci sarebbe piaciuto avere, tanto per dire, James Earl Jones per la voce di Morgan? Ovviamente. Ma con 80 PNG ed un budget limitato per il doppiaggio, i grandi nomi erano inavvicinabili.

L’ultimo ostacolo nella fase di progettazione ce lo mise l’editore. A progetto avanzato, durante il beta test, l’ASC Games ci richiese una variazione di progettazione significativa. Dave Klein, il presidente della ASC Games, ci sosteneva con passione e gli piaceva il nostro gioco. Ma… “Potreste renderlo più facile da giocare?” Ci spiegò che la ASC Games voleva che Sanitarium fosse appetibile per il mercato di massa e che fosse accessibile a chiunque, non solo ai giocatori di avventure grafiche.

La faccia ci divenne viola come il dinosauro Barney dall’indignazione. Sentivamo che un mossa del genere avrebbe compromesso la qualità del gioco e seriamente pregiudicato il completamento del progetto. Mancavano poche settimane alla data di rilascio del gioco e ci chiedevano di subire una revisione importante del nostro approccio di partenza alla progettazione. Eppure, eravamo testardi.

Travis Williams finì per discutere cosa si potesse fare in un lasso ragionevole di tempi e cosa no. Il nostro approccio iniziale potrebbe essere riassunto come “Sei un giocatore di avventure. Trova la soluzione.” Questa nuova concezione ci costrinse a fare delle domande difficili, tipo “Nel gioco dove viene trasmessa questa informazione al giocatore?” In molti casi, non veniva proprio trasmessa. Ciò portò ad un sacco di semplici correzioni – facendo pronunciare al personaggio principale un pezzo di dialogo strategicamente piazzato o modificando un dialogo esistente per aiutare il giocatore a fare dei collegamenti con gli enigmi. Quando non era possibile far eciò senza una vagonata di espedienti, correggevamo l’enigma perché fosse più abbordabile.

Bisogna ammettere che le modifiche resero Sanitarium più orientate all’intrattenimento che alla frustrazione. I giocatori non erano perennemente bloccati su enigmi difficili, e dunque partecipavano alla storia con ritmo costante e potevano meglio apprezzarla. Anche i giocatori hardcore di avventure a cui inizialmente puntavamo, rimasero soddisfatti del bilanciamento tra la difficoltà degli enigma e la profondità della storia.

Il Racconto dei Grafici.

Durante tutto la  concentrazione dei progettisti sulla storia di Sanitarium, molti degli elementi del gioco furono ideati in termini grafici. Sapevamo che l’atmosfera visiva del gioco sarebbe stata estremamente importante nel dinamica del gioco. La parte grafica convogliava le emozioni che il giocatore avrebbe provato, nonché la condizione psicologica. Poiché è tutta basata su emozioni e condizione psicologica, Sanitarium è un gioco ad elevato contenuto grafico. Per questo, già in fase iniziale, il gruppo di progettazione ha passato molto tempo nel determinare il corretto aspetto di ciascuna parte del gioco.

Una delle prime cose che facemmo fu di raccogliere del materiali di riferimento. Facemmo delle visite sul campo presso i cimiteri, prendemmo figure della cattedrale di San Vincenzo, e razziammo le biblioteche del posto. Eric Rice ricavò addirittura un’immagine di una lapide stregata da una delle nostre foto del cimitero.

Nel retrobottega, ferveva il duro lavoro. Dagli schizzi ai modelli 3D fino alla grafica toccante, ci sforzavamo di conservare quanto più possibile quello stile visivo inquietante e realistico.

Uno dei primi ostacoli fu individuare un’inquadratura accuratamente isometrica. Escogitare un modo per riprodurre una panoramica di sei schermi per quattro da ventiquattro punti d’osservazione e cucire fra loro le immagini senza alcuna deformazione di prospettiva era scoraggiante. Tracy Smith lavorò su questo tipo di bug. La soluzione finale fu arretrare le telecamere fino a quello che sarebbe stato l’equivalente di osservare un isolato con il telescopio Hubble.

Il collo di bottiglia più grande che capitò durante lo sviluppo di Sanitarium fu nella fase di post-produzione grafica. Chiamiamo la direzione di post produzione “5D,” non perché esista in qualche superficie pentadimensionale alla Lovecraft, ma perché lavorano combinando grafica  3D e 2D. Quando il materiale tipo schermate, personaggi, e animazioni scorrono lisce in 3D come un ottimo scotch, devono passare da un programma 5D a dodici step prima di essere pronti per la programmazione.

Per quanto riguarda la grafica di gioco, Jason Johnson coordinava il gruppo grafico della DreamForge che usava 3D Studio MAX per rendere reale la visione dei progettisti. I grafici ritoccavano i fondali 3D in Photoshop, poi generavano una tavolozza temporanea. Gli ostacoli fissi venivano definiti in colori reali, poi passati nella tavolozza temporanea; venivano poi calcolate le coordinate. Le animazioni 3D venivano sottoposte a modifiche, ritocchi, ed effetti speciali per quanto necessario. I grafici poi montavano le animazioni sui fondali ritoccati. La tavolozza finale veniva così generata ed applicata a tutte le parti grafiche per ogni livello. Era dura creare una tavolozza che potesse gestire le ambientazioni massive e tutti i PNG. L’enorme numero di colori usati nel gioco fu l’incubo della nostra squadra di post-produzione. Utilizzando DeBabelizer Pro, questi ragazzi dovevano ridurre interi livelli realizzati a truecolor a meno di 230 colori. A quel punto, il grafico che l’aveva realizzato arrivava e diceva “Ehi, che avete fatto al mio livello?” o la direzione chiedeva “Rimane uguale a come era stato disegnato?”

Le attività fervevano. Gli ostacoli fissi dalla tavolozza temporanea vennero riformattati nella nuova. Si ritagliarono le animazioni e si definirono le coordinate. I PNG liberi di muoversi furono ritoccati e ritagliati. Cursori, icone, ed inventario furono ritoccati e ritagliati. I personaggi giocanti vennero definiti in una tavolozza a 24 colori, ritoccati e ritagliati. Questo fu un lavoro mortalmente tedioso, a volte. Anche se il cervello si trasformava in un budino proteinico e gli arti perdevano sensibilità, la grafica stava prendendo forma.

Tutto ciò occupava dalle 50 alle 350 ore/persona per ciascun livello. Si trattava di un impegnativo succedersi di azioni che richiedevano non solo capacità tecniche, ma anche una precedente esperienza di lavoro sui giochi, e di sapere come consegnare gli oggetti grafici al gruppo di programmazione in uno stato di usabilità perfetta. I problemi che sorsero furono dovuti soprattutto all’inesperienza.

L’aspetto finale e la qualità dei livelli e delle animazioni di Sanitarium sono la prova tangibile di alcuni grafici molto determinati che fecero le ore piccole, lavorarono i fine settimana,  e si scusavano quando erano troppo ammalati per trascinarsi alla scrivania.

(continua…)

Embè? Che succede?

No, non mi sono arruolato nella Legione Straniera (esiste ancora?).

Non ho deciso di lasciar perder col blog, e non mi sono neanche stufato di dedicarmici.

Nessun problema familiare o di lavoro mi sta impedendo di postare.

E’ che uno dei pochi furfanti che si mischiano a noi persone perbene che siamo la maggioranza, ha approfittato con notevole tempismo di una mia disattenzione (aver lasciato la borsa del notebook, con dentro il disco esterno dove c’era dentro tutto il lavoro degli ultimi due anni sul banco dei giornali). Ora sto cercando di recuperare tutti i salvataggi parziali, digitali e non, che avevo effettuato in tempi e su mezzi diversi, e mi sto anche guardando attorno per valutare l’acquisto di un notebook (e questa volta mio e non aziendale) . La cosa che mi fa arrabbiare di più è che dentro c’era anche un sacco di roba comprata in digital delivery … oltre al dvd di Black Mirror 2…

Buona (parzialmente) notizia: il programma di EditMADS, l’editor per i testi delle avventure grafiche Microprose, l’avevo stampato pochi giorni prima, quindi, con un programma OCR piano piano dovrei riuscire a recuperarlo piuttosto che riscriverlo daccapo. A presto!

DrawFontMADS – An Editor for Microprose Adventure Games Font Files

Here it is, a little program that let you edit almost as you please font files from adventure games developed with MADS system. I personally checked that the fonts so modified  are still compatible with the game engine.  Help and instructions are contained here ; you can download the program executable (released under Creative Commons – Attribution-NonCommercial-NoDerivatives) from here.

Have fun, waiting for the text editor program (it will not take that time).