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)