Deadly Creatures è un gioco d’azione e avventura in terza persona, basato sulle vite brutali di due spaventosi predatori: una tarantola e uno scorpione. Il concetto base del gioco sarebbe una sfida creativa molto rischiosa per qualsiasi team di sviluppo, ma noi alla
Rainbow/THQ abbiamo affrontato dei rischi aggiuntivi.
Primo: abbiamo pianificato un team di sviluppo molto piccolo e costruito da zero, attraverso assunzioni esterne. Secondo: il titolo era inizialmente pensato per la sola Nintendo Wii, che all’epoca era una nuova console di cui non si era sperimentato a fondo il controller.
Terzo: il gioco era una proprietà intellettuale originale.
Quarto:
Rainbow aveva tradizionalmente prodotto giochi di corse, e la nuova idea era una un distacco dalle competenze principali del nostro personale e dei suoi strumenti. In breve, posso sintetizzarlo così: nuovo team, nuova IP, nuovo genere, nuova piattaforma, nuovo controller. Questi rischi erano grossi e pervasivi. Per avere successo dovevamo guardare fuori dal nostro recinto, e mettere in discussione il nostro status quo, poi identificare e implementare nuovi processi produttivi e tecniche di sviluppo che potessero ridurre i rischi. Questo ha condotto a molte decisioni fondamentali (o azzardi, a seconda del vostro punto di vista) che furono prese nelle prime fasi del progetto, ciascuna delle quali ha avuto un ruolo nel nostro viaggio e per il prodotto finale.
Cos’è andato bene
1) Iterazione, iterazione, iterazione.
Una decisione fondamentale fu quella di concentrarci sui tool che ci consentissero di minimizzare i tempi di iterazione. Abbiamo implementato un framework condiviso che permetteva ai cambiamenti fatti in ciascun tool di essere sincronizzati nel gioco in tempo reale.
Ogni elemento salvato da uno sviluppatore veniva propagato automaticamente al gioco stesso.
Degli strumenti più avanzati erano in grado di implementare nel framework modifiche in tempo reale, così da potere, ad esempio, modificare le proprietà di un oggetto nell’editor di mappe e sincronizzare la prospettiva dell’editor con quella del gioco.
Questa caratteristica ci ha presto liberato dai nostri procedimenti di sviluppo tradizionali. Gli sviluppatori hanno potuto trovare un ritmo di lavoro più naturale, potendo iterare le loro idee senza ostacoli. È diventato inoltre più facile intervenire in diverse aree, perché gli strumenti sono stati semplici da imparare e utilizzare, e questo ha facilitato molto la collaborazione. Abbiamo adottato lo scripting per tutti i settori, e questo è stato un cambiamento radicale nello sviluppo del gameplay. I programmatori hanno scritto gran parte del codice in Lua, che ci ha permesso di iterare l’AI, i controlli e così via, in tempo reale. Abbiamo inoltre implementato un sistema personalizzato di visual scripting, che è stato usato intensamente per creare i contenuti dei livelli, quali ad esempio i tutorial, gli incontri, gli scontri coi boss di fine livello, e gli obiettivi.
Un vantaggio imprevisto è stato che le caratteristiche di editing in real-time hanno portato a strumenti molto meno complessi. In passato, gli sviluppatori preferivano iterare spesso senza controllare gli aggiornamenti nel gioco stesso, perché il procedimento richiedeva molto tempo.
Per compensare questo collo di bottiglia richiedevano procedure complesse e specializzate che potessero massimizzare la loro produttività con uno strumento in particolare. Ma quando abbiamo preso familiarità con l’iterazione in real-time, abbiamo cominciato a preferire semplicità e stabilità alla complessità delle caratteristiche. E molto spesso la semplicità non ha comportato nessun sacrificio.
2) Visione di squadra.
Abbiamo composto con molta cura la nostra squadra di sviluppo, con l’intenzione di sviluppare un gioco basato su una nuova proprietà intellettuale. Prima che ci venisse l’idea per Deadly Creatures, la squadra aveva già una sua identità e una sua vision, che ci hanno poi guidato nello sviluppo. Ecco un estratto dalle nostre best practices, scritto subito dopo la formazione del team: “è vitale che l’intero team segua una sola vision per i processi e gli strumenti di sviluppo. È importante che si unifichino da subito le leadership del progetto, così da poter coinvolgere tutti i membri del team di sviluppo. La squadra deve poi essere abbastanza disciplinata da attenervisi. Quando la squadra cresce, deve trasmettere questa vision a tutti i nuovi membri.”
Detto semplicemente: concordare su una vision, e metterla in pratica. La nostra squadra ha preso a cuore questa filosofia, e l’ha manifestata in molte forme. Per esempio, siamo stati in grado di lavorare velocemente con una squadra organizzata orizzontalmente, senza il bisogno di uno schema di management tradizionale. Questo ci ha reso possibile perseverare attraverso le difficoltà e imparare a risolvere personalmente i problemi che ci sono presentati. Accettando che il successo generalmente segue agli errori, abbiamo potuto concentrarci e andare avanti nel mezzo delle difficoltà. Il nostro successo è dovuto agli alti standard che ci siamo posti e con i quali abbiamo proceduto alle nuove assunzioni.
Abbiamo selezionato attentamente i nuovi membri della squadra sulla base della loro capacità di comprendere e mettere in atto la nostra team vision. Ovviamente questo ha rallentato il processo di assunzione, ma l’abbiamo accettato in quanto ci ha permesso di ottimizzare il lavoro sullo sviluppo.
3) Filosofia generalista.
Quando abbiamo cercato una nuova proprietà intellettuale, ne cercavamo una che permettesse alla nostra squadra di rimanere piccola.
Abbiamo cercato di mantenere l’alchimia del nostro gruppo. Per riuscirci, ognuno ha dovuto accollarsi più responsabilità e assumere un ruolo ausiliario. Abbiamo dovuto assicurarci che ogni nuovo impiegato sapesse e volesse lavorare in questo tipo d’ambiente. Abbiamo impiegato delle piccole squadre formate ad hoc nel processo di sviluppo, e questo ha reso necessario che ognuno di noi assumesse più ruoli. Queste squadre erano sempre interdisciplinari, e in genere responsabili dello sviluppo del gameplay e delle meccaniche di combattimento. A seconda di come erano costruite queste piccole squadre, i suoi componenti assumevano diversi incarichi e responsabilità di volta in volta. È persino successo che partecipassero alcuni elementi emergenti del nostro dipartimento di controllo qualità. hanno contribuito a sviluppare alcuni dei migliori incontri di tutto il gioco.
Sul versante della programmazione, abbiamo spinto questo concetto ancora oltre. Abbiamo abolito completamente i ruoli del programmatore, del programmatore tecnico e del programmatore di tools. Ci siamo riscoperti programmatori generalisti. Secondo la nostra definizione, un programmatore generalista è quello che si occupa di disegnare e sviluppare una vasta gamma di funzionalità, dagli strumenti al gameplay. Ci siamo affidati alle nostre squadre per colmare i gap che inevitabilmente rimanevano nel personale, e abbiamo visto che per ogni necessità c’era sempre una persona dotata di un talento specifico per quello che stavamo facendo. È diventato difficile assumere nuovo personale, perché era difficile trovare degli aspiranti che facessero al caso nostro. Generalmente preferivano tutti assumere un ruolo più definito. I risultati di questa struttura, però, sono andati ben oltre le nostre più rosee aspettative.
4) Concept art come forma di comunicazione.
Durante la preproduzione, abbiamo predisposto uno stile grafico complementare al nostro game design e adeguato ai limiti strutturali della Wii. La concept art è stato il pilastro per comunicare lo stile e gli standard qualitativi lungo lo sviluppo. Il nostro obiettivo era portare il tono e lo stile dei concept direttamente nell’esperienza ludica. Abbiamo usato un mix di artisti interni ed esterni per realizzare una sezione degli ambienti di gioco. Commissionare il lavoro e dividerlo su varie fonti ci ha aiutato a compendiare ed interpretare la nostra vision, e ci ha permesso di generare velocemente un gran numero di parti grafiche. Il concept finale ha rifornito tutti gli aspetti dello sviluppo, e ispirandoci per il design dei livelli e dei mostri ci ha aiutato a finalizzare il tono del gioco completo.
Abbiamo usato questi esempi per comunicare le nostre visioni del design al settore marketing, al trade, allo sviluppo del prodotto e alla stampa. È un’attestazione del talento dei nostri artisti che ci siano tante aree del gioco che hanno incontrato e persino superato i concept originali. I nostri artisti interni hanno creato ampie e dettagliate parti delle texture per ogni materiale immaginabile: rocce, legno, sabbia, metallo. Questo ha consentito di creare delle palette coerenti e stilizzate che i nostri artisti hanno potuto usare per aggiungere le texture ai diversi ambienti.
5) Rimuovere i colli di bottiglia.
I bottleneck nella creazione del contenuto possono essere d’impaccio quando impediscono agli sviluppatori di lavorare. Oltre al tempo di iterazione, abbiamo identificato e risolto due colli di bottiglia significativi che erano la fonte di molte perdite di tempo nei precedenti progetti. Anzitutto, uno sviluppatore potrebbe non poter lavorare per via di strumenti difettosi. Questa situazione può costare cara, perché un bug nello strumento di sviluppo può bloccare un’intera squadra.
Abbiamo pensato che si potesse evitare, e ci siamo prefissati di pensare anzitutto all’integrità degli strumenti. abbiamo stabilito un procedimento formalizzato per il rilascio degli strumenti, che i programmatori hanno seguito lungo tutte le fasi dello sviluppo. In breve, tutti gli strumenti sono stati rilasciati simultaneamente sulla base di un calendario settimanale.
Gli strumenti sono stati testati a fondo e documentati prima di ogni rilascio. Quando saltava fuori un bug determinante, rilasciavamo subito un fix apposito. I benefici sono stati molteplici. Uno, abbiamo adoperato solo strumenti molto stabili che hanno aumentato la fiducia tra programmatori e altri sviluppatori. Due, il totale delle richieste di supporto da parte di ciascun programmatore è scesa. Quando saltava fuori un problema, era facile capire se si trattava di un difetto del programma o se si doveva all’utente o all’inserimento di dati errati. Tre, il supporto per la frammentazione del level editor ha permesso a più utenti di lavorare simultaneamente sullo stesso livello, cosa che prima non sarebbe stata possibile.
Un frammento è un file che contiene dati del livello. Ogni livello contiene un certo numero di file frammento, e ogni frammento può essere controllato e modificato indipendentemente dagli altri. Suddividere questi dati in più file secondo un preciso workflow ha significato poter organizzare meglio il lavoro ed evitare che i programmatori venissero intralciati dalla presenza di altri che stavano modificando i loro stessi dati. Collateralmente, è stato possibile replicare un frammento in diversi livelli, che è stato fondamentale per dati condivisi.
continua in Deadly Creatures: What Went Wrong!
