00:42 – Produttore o Project Manager
03:12 – Fumare mentre si combatte
05:15 – Essere un Artista degli Ambienti 3D
08:55 – Unire le build di AC ed SM
11:09 – Come diventare un Produttore
14:30 – Rapida iterazione di un gioco in Alpha
17:03 – Pagina dello Stato del Gioco
19:46 – Periodi di tempo
23:15 – Combattere il Feature Creep
27:43 – Dall’idea iniziale al suo completamento
Erik Kieron Davis: EKD
Darian Vorlick: DV
Wintermute chiede:
project manager. E’ una questione di terminologia dell’industria, oppure un produttore ha più responsabilità, nell’ambito della gestione dello staff, di un tipico project manager? Potrei diventare un project manager nella mia attuale compagnia e poi, un giorno, fare il salto diventando un produttore di videogame?
EKD: Ottima domanda!
DV: Vero, ma con tanti si e no come risposta.
EKD: Credo che la ragione per cui questa domanda è così difficile sia da imputare al fatto che questi due ruoli presentano tante responsabilità sovrapposte.
DV: Si, hanno parecchi campi in comune.
EKD: Il termine viene cambiato a seconda della regione, dell’organizzazione, della compagnia e delle precedenti esperienze delle persone coinvolte. Ma ci sono parecchie somiglianze e sovrapposizioni. Noi ci occupiamo di ricontrollare il budget, programmare lo sviluppo, gestiamo i team, il personale e persino all’interno della CIG ci sono alcuni project manager e produttori, e le nostre responsabilità si sovrappongono in maniera incredibile.
DV: Già.
EKD: Dunque, per rispondere alla tua prima domanda: si, i due ruoli presentano parecchie similarità e l’utilizzo di questo o quel termine dipende dalla compagnia stessa e dalle precedenti esperienze delle persone coinvolte. Per quanto riguarda invece la seconda domanda, la possibilità di diventare un project manager nella tua compagnia, la risposta è: si, senza alcun dubbio. Ma per diventarlo è necessario imparare della capacità che potrebbero essere insegnate in qualsiasi normale compagnia software, abilità riguardanti soprattutto la gestione del progetto…
DV: Ci sono persino delle certificazioni. Come le certificazioni PMP su Scrum.
EKD: Senza dubbio. Tutte queste sono tecniche che ti aiuteranno a comprendere cosa sarà necessario fare per completare un progetto nell’ambito videoludico.
DV: Un ottimo esempio di ciò è mio fratello. E’ il project manager tecnico di un’altra compagnia di videogiochi ed in realtà lui non si è mai occupato del gioco in se, che è il motivo per cui nella compagnia in cui lavora non è considerato come produttore. In pratica, è un produttore che si occupa di questioni interne, per cui viene considerato come un project manager perché si occupa perlopiù della porzione ‘da console’ degli aspetti tecnici del lavoro, mentre le persone del suo team che si occupano di questioni correlate al gioco vengono considerate come produttori.
EKD: A volte alcune compagnie definiscono una persona come produttore perché questa dispone anche, diciamo, di abilità artistiche che non sono necessarie ad un project manager. Per cui la definizione dipende parecchio dalla compagnia. Se volete scegliere uno di questi due lavori, è molto più importante guardare la descrizione del lavoro stesso, oppure le responsabilità della figura specifica che la compagnia sta cercando, piuttosto che qualsiasi altra cosa.
Entrambi: Ottima domanda!
Nostromo1997 chiede:
Considerando l’evidente stile di combattimento a tema Seconda Guerra Mondiale di Star Citizen, la CIG introdurrà nel gioco qualche prodotto da tabacco, come ad esempio sigari, sigarette e pipe, in maniera tale che i giocatori possano fumare mentre girano per l’Universo, o pensate che sia sbagliato?
DV: Beh, questa domanda non è direttamente correlata alla produzione, ma riguarda alcuni aspetti esterni dello sviluppo del gioco, ovvero i sistemi di classificazione come lo ESRB, nonché la classificazione in cui ricadrà il nostro gioco. Dal momento che questa tipologia di attività è considerata come qualcosa di riservato unicamente agli adulti, ciò potrebbe portare la nostra classificazione a ‘Mature’ o superiore. Di contro la violenza in-game, dal momento che è molto vignettata, potrebbe venire declassificata fino alla fascia di età dai 13 anni in su. Dunque, la presenza o l’assenza di elementi simili in-game… In realtà, non abbiamo ancora stabilito quale sarà la nostra classificazione ESRB. Pertanto è uno di quegli aspetti del gioco ancora sconosciuti, ed in genere dipende dal tipo di mercato cui il gioco è rivolto. Titoli come Grand Theft Auto presentano ovviamente tanti temi adulti e pertanto ricadono nella classificazione ‘Mature’. Vogliamo essere classificati anche noi in questo modo? Non lo so, è una decisione che spetta a Chris. Ma credo che la direzione che abbiamo intrapreso sia quella di rivolgerci al mercato generale, perché vogliamo che questo gioco sia accessibile ad una larga utenza. Per cui, sebbene ci potranno essere elementi come dei bar squallidi in cui sarà possibile ottenere delle missioni da cacciatore di taglie e cose simili, le tipologie di attività che i personaggi potranno intraprendere sono ancora da definire.
EKD: Già, ed è qualcosa che riguarda la storia e gli scrittori. Cosa dovrebbe essere presente nell’Universo? I personaggi cosa dovrebbero poter fare o possedere? Penso che siano tutti elementi cui Chris ha già pensato.
DV: Giusto, devono essere funzionali.
EKD: Esattamente. Non so se elementi di questo genere siano qualcosa di preimpostato, qualcosa che dovrà essere implementato ad ogni costo. Piuttosto, credo che sia una questione di ambientazione, o di ispirazione dell’ambientazione del mondo in cui metteranno piede i giocatori. E’ qualcosa che aiuterà i giocatori ad immergersi in questo universo? Se si suppone che fumare aiuti tutto questo, allora credo che sarà un’attività presente nel gioco, giusto?
DV: Oppure potrebbe essere semplicemente qualcosa di proibito in tutto l’universo.
EKD: Hai colto il punto. Non è detto che si tratti di un’attività presente nel futuro, potrebbe essere del tutto scomparsa. Tutte le piante di tabacco potrebbero essere andate.
DV: Tutte morte.
EKD: Non si può mai dire.
DV: Già.
EKD: Tuttavia era un’ottima domanda. La prossima è di… Fallen? Penso che si dica Fall-un o Fal-lun?
DV: Fal-lun?
EKD: Vedi? Fal-lun. Bene, Fall-un o Fal-lun, in entrambi i casi è un bellissimo nome.
Fallun chiede:
Salve a tutti, ho in programma di entrare nell’industria videoludica appena terminati i miei studi universitari e vorrei diventare un artista degli ambienti 3D. Dall’esperienza che avete accumulato lavorando al loro fianco, soprattutto quella riguardante i neo-laureati, suggerireste ad un aspirante artista di investire il proprio tempo lavorando su un tema o uno stile in particolare, su una qualche preferenza estetica o di adattarsi ad una resa più realistica a prescindere da tutto il resto?
EKD: Questa è un’ottima domanda.
DV: Tutta tua.
EKD: Dunque, basandomi su quello che ho visto fare dagli artisti con cui ho lavorato, il trucco è occuparsi di qualcosa che ti ispiri piuttosto che, semplicemente, lavorare su ciò che l’industria richiede. Per esempio, se ti piace il genere sci-fi, se ti piacciono le astronavi, ti consiglierei di concentrarti su quelle, sugli ambienti 3D che le riguardano. Ci saranno sicuramente compagnie, come la nostra, alla ricerca di quel genere di talento. Se invece ti piace lo stile vignettato, oppure i grandi mondi o le ambientazioni sgargianti, allora lavora su quelle, ma personalmente io raccomando sempre ai nuovi artisti che hanno intenzione di entrare in questo tipo di industria di cercare la compagnia o il gioco dei loro sogni e di costruire il proprio portfolio su quella. Se ottieni un colloquio con una compagnia che si occupa soltanto di ambienti 3D costituiti da foreste e simili, mentre tutto quello che hai sono ambienti industriali arrugginiti e mal messi, allora ti diranno che non sapranno come valutare te e le tue capacità perché non sapranno come collocarti nel gioco che stanno facendo. Per cui la questione si riduce ai temi dell’industria che ti potrebbero interessare, a quali pensi siano i tuoi punti di forza ed alla realizzazione del tuo portfolio attorno a questi aspetti. Ho visto molti bravissimi neo-artisti che si sono occupati un po’ di tutto, ed in quel modo hanno potuto capire in cosa erano bravi e portati. Così facendo hanno potuto adattare il proprio portfolio alla compagnia in cui sarebbero andati a lavorare e questo è un ottimo approccio che permette di capire quali siano i propri punti di forza e di sfruttarli appieno. Tornando alla tua domanda riguardante gli aspetti su cui ti dovresti concentrare: non posso darti una risposta precisa, perché dipende dal tema su cui vorresti lavorare e da quale tipologia di prodotti artistici vorresti realizzare, oltre che dal tipo di gioco o film o qualsiasi altra cosa ti interessi e ti entusiasmi. Da quello che ho visto, la maggior parte degli artisti lavora meglio sui temi che li appassionano.
DV: Inoltre questo atteggiamento aiuta a mantenere una mentalità aperta e ad essere versatile, perché si potrebbe verificare il caso in cui un artista abbia sviluppato un set di abilità e stili artistici utili alla compagnia, ma questa gli chieda di occuparsi di qualcosa completamente scorrelato dalla sua sfera abituale semplicemente perché le necessità della compagnia o del progetto potrebbero richiedere di sviluppare altro. In queste circostanze, se non si dispone delle abilità necessarie a portare a compimento tale mansione, la compagnia potrebbe non essere contenta dei risultati. E’ utile avere un set di abilità diversificato.
EKD: Non sono in disaccordo con quanto detto, ma questo non è il caso con alcuni dei portfolio che ho analizzato per alcuni dei nostri artisti e direttori artistici: diciamo che tu voglia fare domanda per il ruolo di artista senior dei veicoli e tutto quello che hai è soltanto una serie di panorami di foreste. Non potrei associare le tue capacità ed il tuo passato con quello che potresti fare con i veicoli o con il ruolo per cui stai facendo domanda. Se hai intenzione di fare domanda per una certa posizione o in una determinata compagnia in cui vorresti lavorare… Cerca di avere un portfolio variegato, ma comunque costruiscilo attorno a quello che stai cercando in quel momento. Questo perché non disponiamo di molto tempo per analizzare le centinaia di paginate di immagini di ogni artista che fa domanda di assunzione per controllare se è davvero bravo in questo o quello. Vorrei avere il tempo per farlo, ed è per questo che diciamo ai candidati di inoltrarci direttamente le loro opere migliori, così da poter capire meglio che tipo di persona siano e quali siano le loro capacità. Ma sicuramente non fa male fare i compiti a casa e prepararsi per la compagnia in cui vorresti lavorare, costruire il proprio portfolio attorno ad essa e, quando farai domanda, inviare direttamente queste opere.
Xtodmanx chiede:
Darian,
mi chiedevo cosa vi avesse portato a decidere di unire in una fase così preliminare le build di Star Marine e dell’Arena Commander. Non avreste potuto tenerle separate, così da poter aggiornare indipendentemente Arena Commander mentre continuavate a lavorare su Star Marine?
EKD: Questa è un’altra ottima domanda.
DV: E’ rispondervi è molto difficile perché sono tante le motivazioni dietro quella decisione. Ma alla fine è stato Chris a scegliere di procedere in questo modo. Parte di questa scelta è da ricollegarsi alla facilità di sviluppo. Tenendo separate le due build mentre continuavamo a lavoranre all’Arena Commander… Nel momento in cui ci saremmo dovuti preparare alla pubblicazione di Star Marine, avremmo comunque dovuto fondere le due build, e ciò avrebbe potuto causare ogni genere di problemi e di bug. Questo perché, mentre reiteravamo le build, abbiamo dovuto sviluppare per l’Arena Commander delle funzioni speciali ed uniche che sarebbero potute non essere necessarie per Star Marine, per cui quando avremmo unito le build tutti i bug che avremmo risolto nell’Arena Commander sarebbero potuti ricomparire in Star Marine o viceversa. Pertanto sviluppare le due build contemporaneamente in un unico ambiente ha semplificato di molto il lavoro. Unificare elementi come le modifiche allo scheletro dei personaggi per il miglioramento delle animazioni è stato utile ed ha evitato di dover fare i conti a posteriori con altri problemi. Probabilmente la maniera migliore di motivare tale scelta, senza dover discutere per ore di tutti gli aspetti logistici della faccenda, è dire semplicemente che lavorare in un unico ambiente, e quindi in un contesto simile per entrambi i moduli, ha reso tutto più facile in termini di sviluppo ed ha permesso di evitare di introdurre nuovi bug in Star Marine o Arena Commander.
EKD: Già.
DV: Spero che questa risposta ti piaccia.
EKD: La domanda era rivolta a te.
DV: Beh, inoltre, se date una rapida occhiata al sito, soprattutto all’aggiornamento di Chris Roberts su Star Marine e sul modulo FPS, troverete qualche informazione in più sullo stato di sviluppo di questa componente e sul perché si sono verificati determinati avvenimenti durante il suo sviluppo. Per cui vi raccomando caldamente di leggerlo, perché potreste trovare delle altre informazioni importanti.
Alex Valentine chiede:
Sono curioso di sapere se per fare domanda per la posizione di produttore sia necessario avere un qualche tipo di esperienza standard. Ho preso in considerazione la possibilità di entrare in questa industria (forse persino in uno degli studi di Star Citizen), ma non dispongo di alcuna vera e propria esperienza diretta in questo campo. Comunque, sono un veterano dell’esercito che ha prestato servizio per quasi quindici anni e mi sono occupato di svariati progetti anche nella mia vita civile. La mia esperienza pregressa mi impedirebbe di entrare in questo campo in quanto non dispongono di una laurea, oppure potrei trovare una compagnia di larghe vedute disposta ad assumermi?
EKD: Grazie per il servizio reso alla patria.
DV: Oh, è un’altra ottima domanda.
EKD: Vero, e no, la tua esperienza passata non ti impedirebbe di essere assunto per questo ruolo. Dipende dal lavoro. Con il tuo background avrebbe senso assumere direttamente il ruolo di produttore all’interno di una qualche compagnia? Forse no, giusto? Ma comunque hai esperienza in ambito gestionale, vero? Cioè, ti sei occupato di diversi progetti di vario genere e sei in grado di parlare in maniera consapevole ed intelligente della maniera in cui hai gestito quei progetti dall’inizio alla fine. Tutte queste sono caratteristiche importanti, abilità che hai appreso e che utilizziamo quotidianamente, per cui sicuramente ti sarebbero d’aiuto nell’ambiente in cui lavoriamo. Avrebbe più senso se in determinate compagnie tu ricoprissi il ruolo di un assistente alla produzione, di un coordinatore o persino di un produttore associato? Probabile, giusto? Ma sicuramente non sarebbe… Non esiste una laurea specifica in grado di aiutare in questo ruolo più dell’esperienza maturata nel corso della propria vita.
DV: Tra tutte le tipologie di industrie in cui ho lavorato, questa è l’unica che da a tutti le stesse possibilità. E spesso ad essere importante non è necessariamente quello che si impara a scuola, ma quello che si apprende dalla vita di ogni giorno.
EKD: Si, senza alcun dubbio.
DV: Prendiamo il caso della Blizzard: quanti sono i produttori ed i produttori senior che sappiamo non essere mai andati al college?
EKD: Già.
DV: Uno di loro faceva il tecnico dell’aria condizionata. Un altro lavorava ad un sito di vendite online. Ma alla fine sono diventati produttore senior e capo produttore.
EKD: Vero. E’ un’industria molto giovane. Per cui abbiamo ancora molti… Non esiste un programma di studi che contempli tutte le materie e gli argomenti necessari. Credo che soltanto adesso stiano iniziando a comparire dei corsi creati appositamente per i videogiochi. Ma noi non… La maggior parte dei leader di questo settore non vengono da scuole incentrate sullo sviluppo dei videogiochi, giusto? Ci sono entrati per caso, hanno amato questo lavoro e si sono dati da fare per raggiungere la posizione che occupano oggi. Hanno imparato quanto c’era da sapere lavorando e vogliono rendere migliore l’industria stessa. Credo che mettendo insieme tutto questo, si, potresti senza dubbio riuscire ad ottenere un ruolo di produttore in qualche studio di videogiochi. Non vedo perché non sia possibile.
DV: Vorrei aggiungere a quanto detto un’altra cosa, una piccola allusione ad Alex Mayberry. Qualcosa che mi ha detto quando eravamo ancora alla Blizzard.
EKD: Già.
DV: Se hai intenzione di entrare nel ramo della produzione, non considerarla come l’ultima spiaggia soltanto perché non hai capacità artistiche, di programmazione, di design o ingegneristiche. E’ la ragione sbagliata. E’ un reparto che richiede passione e dedizione, perché bisogna guardare e riguardare in continuazione i fogli di calcolo e tenere tutto in ordine. Tu disponi di una formazione militare e questo ovviamente… La disciplina sicuramente ti aiuterà molto. Ma da sola non basta, è necessario avere la passione per queste cose. Se invece hai semplicemente pensato che, non potendo fare altro, ti saresti potuto buttare nella produzione, ti avviso immediatamente: ho visto molte persone fare questo tipo di ragionamento e, successivamente, ritrovarsi in un mare di guai. Per ti consiglio di cercare qualche… Se vuoi entrare a far parte di questo settore, scegli la direzione che vorresti intraprendere davvero. Se vuoi diventare un designer, inizia a realizzare delle mod per vari giochi, cose del genere. Se invece vuoi entrare nella produzione, devi perseguire un insieme di competenze ed una disciplina molto particolari.
EKD: Vero. Ottima domanda, e c’è sicuramente una qualche opportunità che ti sta aspettando da qualche parte.
DV: Senza dubbio.
EKD: Certamente.
Booyakashasta chiede:
Questa è una domanda che mi sono posto diverse volte dall’avvento dei giochi ad accesso anticipato.
Considerando il fatto che Star Marine richiederà di effettuare iterazioni ed aggiornamenti continui ad una build giocabile comprendente già Arena Commander e, a breve, anche Star Marine, tutto questo aiuta o ostacola lo sviluppo complessivo del progetto? Non dovendo programmare queste build giocabili, la produzione del gioco andrebbe più spedita o, piuttosto, si tratta semplicemente di un altro livello del processo di sviluppo che richiede poche attenzioni e risorse?
DV: E’ una questione di efficienza, perché svilupparle assieme e contemporaneamente permette di mantenere le build unificate man mano che si fanno progressi. Se ciò aiuti o ostacoli lo sviluppo complessivo del progetto? Probabilmente fa un po’ di entrambe. So che le persone interessate all’Arena Commander preferirebbero che lo sviluppo si concentrasse più su questo modulo, e lo stesso vorrebbero i fan di Star Marine, ma dal momento che i nostri uffici devono tenere traccia di tutto in un contesto più ampio, seguendo il lavoro svolto da ciascuno dei nostri sviluppatori, l’accesso anticipato aiuta ed ostacola contemporaneamente il progetto.
EKD: Già, questa è un’altra grandissima domanda, perché ci sono tante compagnie che stanno iniziando ad adottare questa stessa strategia. Fondamentalmente, essa consiste nel fornire un gioco live che i giocatori supportano e provano proprio mentre viene sviluppato il progetto completo. Molte compagnie fanno ciò separando il team di sviluppo da quello delle componenti live, creando così due team distinti che si occupano di aspetti differenti.
DV: Cioè ci si occupa contemporaneamente della produzione e della preproduzione.
EKD: Esattamente. Ma questo non è il nostro caso. Non so se il nostro approccio ostacoli lo sviluppo complessivo del progetto, perché ci sono vari elementi che si fondono bene tra loro. Traiamo grandi benefici da tutto ciò che salta fuori durante la creazione delle build live, elementi che possiamo contemporaneamente implementare e sistemare anche nelle build di sviluppo e vice versa. E dal momento che stiamo lavorando contemporaneamente su entrambi questi aspetti, il processo di sviluppo stesso è più agile e veloce, è più semplice spostare questo o quel componente, a seconda delle necessità. Probabilmente tutto questo ci ostacola anche in parte, ma penso senza alcun dubbio che i benefici siano maggiori degli svantaggi, perché possiamo ottenere un mare di feedback live e far provare il gioco ai nostri fan, cosa che ci entusiasma parecchio. Ci spinge a fare di più.
DV: Inoltre, essere i primi ad abbracciare una strategia simile di certo non ci aiuta. Il nostro è un tipo di progetto completamente nuovo, e noi siamo una specie di pionieri, stiamo preparando la strada per chi verrà dopo. Non dico che stiamo imparando a gestire questo processo man mano che andiamo avanti, ma che stiamo infrangendo ed esplorando tante situazioni nuove da cui apprenderemo parecchio.
Herrmatthias chiede:
Che ne dite di presentare la pagina di stato del progetto
https://robertsspaceindustries.com/project-status
in una maniera migliore e più dettagliata, così che ogni backer che sia stato via per, diciamo, sei mesi o più possa immediatamente rendersi conto dello stato attuale del gioco e su cosa stiate attualmente lavorando per la prossima patch?
DV: Whew.
EKD: Si riferisce alla pagina che qualcuno stava utilizzando più come una sorta di bacheca dello stato dei lavori. Anche questa è un’ottima domanda. Riguarda un argomento con cui abbiamo continui problemi – ogni giorno lavoriamo su tanti elementi ed internamente dobbiamo tenere traccia di tante cose, dobbiamo gestire parecchi processi, dobbiamo tenere sotto controllo svariati lavori e dobbiamo fare in modo che i nostri sviluppatori e noi stessi rimaniamo concentrati sul nostro lavoro, sulla realizzazione del prodotto finale. Abbiamo un meraviglioso team della comunità che lavora a stretto contatto con noi soltanto per cercare di farvi pervenire il maggior numero possibile di informazioni. Per cui credo che quanto proposto sia un’ottima idea e qualcosa che ci piacerebbe tanto fare, sia ad alto livello – ovvero riassumendo lo stato di un progetto o sotto progetto in una sola parola – sia ad un livello molto più basso, dividendo ciascuna mansione nelle singole componenti. Tuttavia, per quanto mi piacerebbe farlo, non so se sia un approccio praticabile nel breve termine. Potremmo fornirvi in qualche modo e velocemente tutte le informazioni necessarie così che, se non potrete seguire i lavori per un po’ di tempo, o se avrete intenzione di tornare a farlo soltanto quando ci sarà qualcosa in più da giocare, potrete farlo e, al vostro ritorno, potrete aggiornarvi immediatamente sulla situazione. Credo sia un’ottima idea. Sicuramente è qualcosa che abbiamo già preso in considerazione, ma non so se attualmente siamo nelle condizioni di applicarla.
DV: Non so neppure quanto la trasparenza potrebbe aiutare. Suppongo che, dal momento che ci sono così tante funzionalità che si portano avanti ogni giorno già soltanto nel team dell’Arena Commander… In un certo momento Calix potrebbe star lavorando su una qualche componente, ma a causa dell’avvicinarsi di una data di consegna la sua attenzione potrebbe essere dirottata verso qualcosa di completamente differente. Ed a meno che non ci sia un ragazzo o una ragazza della Cloud Imperium costantemente impegnato/a ad aggiornarvi su questi cambiamenti di rotta, spiegandovi di volta in volta il motivo alla base di questa decisione, probabilmente dall’esterno vi sembrerebbe soltanto che lo sviluppo di questa o quella funzionalità sia stato interrotto. E non vogliamo che voi ragazzi vi facciate un’idea sbagliata, che pensiate che abbiamo posposto o bloccato lo sviluppo di un certo elemento quando in realtà quello sviluppatore sta semplicemente spostando temporaneamente la sua attenzione su un qualche altro argomento.
EKD: Assolutamente.
DV: Per cui, sebbene vi vorremmo poter fornire regolarmente queso tipo di aggiornamenti, dovremmo anche consolidare la maniera in cui darvi queste informazioni e come farvi capire il contesto che vi è dietro. Credo che sia qualcosa di molto complicato, specialmente considerando quanto già sia aperto il nostro modello di sviluppo.
EKD: Senza dubbio, ed in riferimento a quanto detto da Darian riguardo l’esplorare situazioni nuove, stiamo già provando cose nuove. Alcune di queste riguardano aspetti di cui molti di noi non si erano mai occupati nelle precedenti esperienze lavorative, mentre altre le stiamo apprendendo interagendo con voi. Per cui credo che stiamo imparando continuamente qualcosa di nuovo lungo la via del… Come possiamo essere trasparenti e fornire le informazioni che volete, ma al tempo stesso come possiamo continuare a lavorare sullo sviluppo del progetto, perché, di fatto, è una situazione equivalente all’avere due lavori a tempo pieno. Dunque stiamo ricercando in continuazione nuovi modi per fare tutto questo. Ottima domanda ed ottimo riferimento, grazie per aver citato quel link!
Gravy chiede:
Avete qualche consiglio da dare su come programmare dei periodi di tempo realistici per il completamento di un qualche elemento, soprattutto quando si ha a che fare con qualcosa di cui il team non si è mai occupato prima? Pensate sia meglio lavorare all’interno di una finestra temporale flessibile, assegnando del tempo extra rispetto a quanto inizialmente programmato qualora le cose vadano per le lunghe, oppure quando un piano non viene rispettato preferite riprogrammare tutto da zero, a partire dalla situazione attuale?
DV: In realtà questa domanda definisce proprio il compito del produttore – mantenere le cose sulla giusta rotta. Ci saranno sempre degli imprevisti. Se le cose andassero sempre lisce come l’olio, la produzione sarebbe un lavoro fin troppo facile, per cui c’è sempre qualche contrattempo dell’ultimo momento. La pianificazione ne viene alterata. All’improvviso possono comparire dei bug pesantissimi – qualcosa che ci impedisce di completare il nostro compito o di pubblicare quanto sviluppato, ed ovviamente in questi casi la loro risoluzione ha la priorità su tutto il resto e richiede la riallocazione di parecchie risorse da altri settori, la cui entità reale dipende dalla gravità del problema. Per cui, in breve, la risposta è si e no.
EKD: Certo… E penso che la tua prima domanda riguardante la maniera in cui sia possibile capire la portata e le implicazioni di un compito, nell’eventualità in cui si lavori a qualcosa di completamente nuovo o che qualcuno stia lavorando ad un progetto con cui non ha mai avuto a che fare in passato…
DV: E come sia possibile fissare dei tempi di completamento realistici…
EKD: Già, penso che sia una domanda davvero interessante e complicata. Specialmente se… Diciamo che non sei di questo campo, ma vuoi sviluppare una funzionalità già esistente per un certo gioco oppure ottenere una SDK ed iniziare a costruire qualcosa assieme ad un designer, un programmatore ed un artista. Ma non hai mai fatto nulla del genere e non sai come comportarti. Innanzitutto, è importante cercare di utilizzare ed apprendere dalle persone che si sono già occupate di lavori simili. Giusto? Cerchiamo di contattare quelle persone che ci hanno già lavorato in passato; inizialmente, ci rivolgiamo ai nostri colleghi all’interno della compagnia: “Hey, hai mai lavorato su qualcosa di simile nella compagnia in cui eri prima?” O anche qui, dato che abbiamo più uffici: “Nel tuo team come ti sei regolato per la programmazione?”. Questo ci permette di avere una prima idea sui tempi di sviluppo. Ma se questo non è possibile, allora si cerca di scomporre il lavoro nelle singole mansioni che lo costituiscono con l’aiuto delle persone che ci lavoreranno e si chiede loro quanto tempo sarà necessario per completare ciascuna di esse. Ma quando si sceglie questo approccio spesso le cose non vanno come previsto, la pianificazione si rivela sbagliata e… Si spera che sia stata sovrastimata, nel qual caso si può dire tranquillamente di aver completato il lavoro più velocemente di quanto inizialmente stimato, ma purtroppo non è sempre questo il caso. A volte questo è semplicemente un processo di ‘trial and error’, ed è così che si fa quando si sta lavorando a qualcosa di mai fatto prima, giusto?
DV: Sostanzialmente diventa una sorta di set di capacità che vengono sviluppate ed affinate nel tempo. Nel caso in cui si stia sviluppando un modello di siluro completamente nuovo, si va a guardare lo storico dei progetti simili già effettuati: ad esempio, Dan potrebbe aver impiegato tre giorni a realizzarlo, mentre Patrick lo ha animato in un giorno e mezzo… E se il progretto sarà più grande di quelli precedenti, come potremo scalare queste previsioni? Okay, diciamo che l’ultima volta abbiamo impiegato quattro giorni, per cui aggiungiamo un paio di giorni extra per il QA, per i test di gioco… Diciamo una settimana. E’ in questo modo che si inizia ad imparare come misurare le cose, ma sostanzialmente ogni volta che si realizza una pianificazione per una qualche attività di produzione – si può dire che la regola d’oro in questo campo è che, nel momento in cui verrà pubblicata quella programmazione, questa sarà già vecchia ed errata.
EKD: Proprio così.
DV: Questo perché la programmazione si basa sempre e comunque sulla formulazione di una serie di ipotesi.
EKD: Giusto, ed è nostro compito aggiornare e spostare le cose ogni giorno per segnalare quando il progetto non riuscirà a rispettare la data inizialmente stimata e ricontrollare cosa sarà possibile fare per sistemare la situazione. E’ una cosa che facciamo in continuazione.
Aragornbh chiede:
Quali sono gli indizi che vi permettono di capire se l’approccio ‘feature creep’ ha iniziato ad infilarsi nel modello di produzione di un gioco? Specificatamente, cosa avete fatto per assicurarvi che ciò non accada con Star Citizen? Infine, avete creato un qualche posto in cui raccogliere tutti quei concetti interessanti/ quelle idee che potrebbero attualmente essere considerate come ‘feature creep’, ma che potrebbero costituire un’entusiasmante aggiunta dopo la pubblicazione ufficiale di SC? Avete già autorizzato qualcuna di queste idee per il post rilascio?
DV: E’ per questo che abbiamo un backlog [NdT: è un registro in cui vengono inserite e si tiene traccia di tutte le operazioni, i progetti o altro che sono in attesa di valutazione o di lavorazione].
EKD: Si. Dunque, posso affrontare questa domanda partendo dall’ultima parte? Non c’è problema, vero? Ok. Abbiamo un backlog per qualsiasi cosa sia stata detta o accennata in ciascuna delle riunioni che abbiamo avuto. Disponiamo di questo enorme, imponente e per quanto possibile vasto…
DV: ‘Sky’s the limit’.
EKD: Giusto. Si cerca sempre di incoraggiare la gente a dire quello che passa loro per la mente. E’ entusiasmante. Sappiamo che tutti noi abbiamo in mente qualche idea su come potremmo sviluppare il gioco o su cosa potremmo aggiungere, soprattutto in relazione alla nostra storia personale, a quello che desideravamo vedere da piccoli, e tutti noi disponiamo di una certa immaginazione, per cui incoraggiamo gli sviluppatori a dire quello che pensano, vogliamo sentire tutte le loro idee, anche quelle più assurde. Successivamente tutto questo viene raccolto in un backlog che riguardiamo quando siamo alla ricerca di qualche funzionalità aggiuntiva, di qualche altra pietra miliare o componente che potremmo implementare in futuro. Esso costituisce la base su cui sviluppare i nostri rilasci futuri. Quando ce ne usciamo con un nuovo aggiornamento, in realtà abbiamo già ipotizzato diversi piani di aggiornamento ed abbiamo preso in considerazione diversi elementi che avremmo voluto pubblicare con quella patch. Per cui si tratta di qualcosa che già facciamo di continuo. Per quanto riguarda invece la domanda sull’assicurarsi che Star Citizen non diventi un ‘feature creep’ – ottima domanda, tra l’altro – la risposta è: stiamo facendo qualcosa di nuovo. Abbiamo tanti grandissimi backer ed abbonati che ci aiutano ogni giorno ad evitare che ciò accada. E vogliamo realizzare qualcosa di davvero figo, un progetto davvero grande ed unico nel suo genere.
DV: Non siamo a corto di idee.
EKD: E non siamo a corto di idee. In quanto produttori facciamo costantemente i conti con questa enorme riserva di idee e cerchiamo di tradurle in realtà, così da poter far uscire qualcosa con cui noi tutti potremo giocare e divertirci. E’ questa la vera sfida. Ed ogni giorno, voglio dire, anche oggi, ci riuniamo per discutere di cose che vorremmo implementare, ottime idee che, però, ci porterebbero fuori strada, ma che potremmo comunque utilizzare per realizzare magari un versione due, tre o quattro di qualcosa che già abbiamo. Ho visto un concetto simile esposto in una domanda cui non credo risponderemo oggi che chiedeva come facciamo a capire quando sia giunto il momento di rilasciare qualcosa che si vuole provare e che intendiamo reiterare. In realtà, è qualcosa che vedete ogni giorno con quei team che sviluppano giochi per console che, quando li andate ad avviare, vi richiedono di scaricare immediatamente una patch da 500mb. E’ la stessa cosa: per fare questo hanno dovuto prendere l’idea, svilupparla, realizzare la versione commerciale del software e pubblicarla. Ma poi se ne escono dicendo che c’erano anche questa o quest’altra cosa che volevamo sistemare o pubblicare, per cui eccovi la patch da 500mb. E credo che questo sia semplicemente il modo in cui vanno attualmente le cose nel mondo fatto di contenuti scaricabili ed in streaming in cui viviamo. In verità è una realtà che non ostacola i nostri giocatori, i nostri meravigliosi fan o le straordinarie persone che giocano al nostro titolo. Per cui stiamo cercando di trovare un equilibrio in questo approccio, è qualcosa che facciamo di continuo. Ma come ci assicuriamo di non ricadere nella trappola del ‘feature creep’? Semplicemente considerando la nostra programmazione, quanto sia realistica e la natura delle nostre date. La maniera in cui possiamo far uscire velocemente le nuove funzionalità ed assicurarci che possano far divertire le persone. E cerchiamo di essere realistici in ogni nostra riunione, ce ne ricordiamo sempre, in ogni momento. Qualcosa del tipo: “Hey, allora, stiamo ancora cercando di completare questo elemento per Venerdì. Di cosa abbiamo bisogno per farlo?”.
DV: Molte volte i produttori devo fare la parte del cattivo e dire: “No, al momento non possiamo fare questo. Magari più tardi, ma non adesso.”
EKD: Già, e nella maggior parte dei casi la gente capisce e collabora con noi per raggiungere quello scopo. Come detto prima, è nostro compito segnalare quando le cose non sono fattibili, e di solito la gente lo riconosce. Come tutti gli altri, anche noi vogliamo portare avanti e migliorare questo progetto, ma ci sono cose che non posso essere fatte fisicamente o umanamente parlando, perlomeno non senza lavorare 24/7.
DV: Ed odiamo dover frenare… Gli ottimi suggerimenti che ci arrivano. Soprattutto quando si ha a che fare con visionari del calibro di Chris, Ben, Dan e tutti coloro che contribuiscono alla progettazione del gioco. Abbiamo una tale sfilza di designer ed idee brillanti che è davvero difficile dire che non è possibile fare questo o quello e che dovremo riprovare più avanti, perché vogliamo davvero implementare tutte quelle fantastiche idee e vederle tradotte in realtà.
EKD: Già, giusto. E per rispondere alla domanda riguardante l’approvazione di determinate funzionalità per il post rilascio: si, abbiamo già qualche idea… Sapete che vogliamo pubblicare parte di quello che stiamo sviluppando entro certe date, ma vogliamo anche implementare tante altre cose, sulla base anche di quanto abbiamo raccolto con il nostro primo kickstarter e di quanto stiamo ancora raccogliendo. In questo caso, ci preoccupiamo di verificare come sia possibile continuare a pubblicare materiale anche dopo aver superato la nostra programmazione originale.
DV: Si, abbiamo già pianificato diverse componenti a lungo termine.
EKD: Ecco.
DV: E queste pianificazioni probabilmente saranno soggette a cambiamenti, ma cerchiamo comunque di lavorare usando una prospettiva a lungo termine.
EKD: Esattamente, al meglio delle nostre possibilità.
DV: Già.
EKD: Si.
DV: Ok, ultima domanda.
Weyoun “Six” of Imperium chiede:
Cari produttori, grazie a Bugsmashers abbiamo avuto modo di dare un’occhiata da vicino al processo di risoluzione dei bug. “Dei meravigliosi programmatori si siedono ad un tavolo, pensano e dalle loro dita escono dei magici fix del codice”.
EKD: *risatina*
DV: Mark fa così?
EKD: Si.
DV: Okay…
EKD: No, lo so.
Il processo di implementazione di una nuova funzionalità è simile? In molti sembrano pensarla così. Potreste ripercorrere con noi il processo di sviluppo di una nuova funzionalità dall’inizio alla fine, a partire da un’idea di Chris Roberts (o qualcun altro) fino alla scrittura ed integrazione del codice, inclusi alcuni degli ostacoli che potreste incontrare e la maniera in cui li superereste?
DV: In realtà è… E’ una sorta di seguito della domanda precedente, cui abbiamo risposto dicendo che spesso dobbiamo limitare il numero di idee che vorremmo mettere in pratica. Un buon esempio di tutto ciò sarebbe… La Vanguard che Calix… Era una variante su cui lui stava lavorando. Ed aveva in mente una certa idea riguardo il ruolo che voleva assegnarle. Era un’ottima idea, ma quando il team delle navi, i designer e la produzione si sedettero a tavolino ed analizzarono come si sarebbe inquadrata questa variante con il resto delle funzionalità della nave, si accorsero che non era fattibile. Per cui abbiamo dovuto eliminare quella variante e semplicemente costruire le altre a partire da quello che avevamo. O quanto meno abbiamo progettato e steso le bozze di design di come volevamo che si sviluppassero le altre varianti. Questo si riallaccia in parte alla risposta di Eric all’ultima domanda, ovvero che abbiamo da parte un enorme quantitativo di idee. Per cui quello che facciamo è sederci ed analizzare gli elementi che vogliamo pubblicare in ogni versione e patch del gioco che rilasciamo. Per esempio, attualmente ci stiamo preparando alla 1.1.5, e dopo questa inizieremo a lavorare sulla versione successiva e così via, versione dopo versione. Sappiamo già quali funzionalità saranno presenti in ciascuna di queste versioni, abbiamo già stilato una lista, e tutto questo ci aiuterà a pianificare le tecnologie che dovranno essere pronte per allora. Quali navi dovranno essere pronte e pilotabili per una certa data. E ciò definirà i compiti che dovremo assegnare ai nostri designer, ai nostri programmatori ed ai nostri artisti. Di conseguenza dobbiamo pianificare lo sviluppo e la pubblicazione di queste idee, e questo richiede un preciso set di abilità e competenze, per non dire che esso stesso costituisce un insieme di capacità specifiche. Non possiamo semplicemente dire che: “Questo mese vogliamo una nave che faccia questo, il prossimo vogliamo che un centinaio di persone siano in grado di pilotare contemporaneamente queste navi attorno al pianeta” e così via. Non sarebbe realistico. Per cui quando pianifichiamo qualcosa dobbiamo stabilire delle date realistiche, e per far ciò è necessaria tanta comunicazione con i designer e gli artisti. Soltanto dopo aver parlato con tutti è possibile raggiungere l’unanimità su quello che possiamo fare, su quali elementi andranno implementati e sulla direzione che vogliamo dare al gioco. E fondalmentalmente l’ultima voce in capitolo è quella di Chris, che decide se qualcosa… Se vogliamo che il gioco prenda una certa direzione o meno.
EKD: Già. E credo che, per rispondere anche a parte della domanda riguardante le funzionalità, le componenti di questa ricetta magica siano tre: la pianificazione, le idee e quindi la produzione. E si tratta davvero di una specie di magia: mettiamo insieme delle persone talentuose, queste definiscono i piani per realizzare ciò di cui necessitiamo e noi li aiutiamo a tenere traccia del lavoro, a mantenere il ritmo per assicurarci di rispettare le scadenza. Lavoriamo insieme, ed i vari compiti vengono passati di mano in mano alla massima velocità umanamente possibile per permetterci di completare quanto c’è da fare. E quindi, magicamente, il lavoro è terminato. Il reparto QA lo prova, ci assicuriamo che funzioni e quindi ve lo mettiamo a disposizione. Dunque, senza scendere nel dettaglio e parlare di chi si occupi di cosa durante lo sviluppo di una certa funzionalità, si può definire questo meccanismo come una specie di magia. Si tratta semplicemente di prendere alcune bravissime persone che sanno esattamente cosa fare, assegnare loro dei compiti riguardanti le singole componenti che costituiscono l’elemento da sviluppare e loro faranno da se, terminando il lavoro. Questo perché siamo tutti super entusiasti di quanto stiamo facendo.
DV: Gran parte di ciò che accade dietro le quinte, e che non avete modo di vedere, riguarda persone che rimangono in ufficio fino all’una di mattina per aspettare che qualcun altro entri nella sede degli UK soltanto per chiedergli di qualcosa che bisogna risolvere il prima possibile.
EKD: Esattamente.
DV: Per cui dietro le quinte si verificano e continuano a succedersi tante sfide. Non è qualcosa di semplice come, ad esempio, le dita magiche di Mark. Per quanto gli possiamo augurare di avere delle dita magiche capaci di risolvere i problemi in un attimo, quello che fa, in realtà, è oscillare la sua bacchetta magica sulla tastiera e sistemare i bug.
EKD: *ride* Giusto.
DV: Ma tutto questo comporta una serie di difficoltà.
EKD: Vero.
DV: Dunque.
EKD: Ecco.
DV: Fantastico.
EKD: Speriamo che le nostre risposte vi abbiano soddisfatto.
DV: Già.
EKD: Meraviglioso.
DV: Um, questo è il team dei Mangiatori di Persone Viola. [NdT: entrambi indossano magliette viola]
EKD: *ride* Non ho idea di come sia successo.
DV: Già, non lo avevamo pianificato.
EDK: Yup.
DV: Allora. Innanzitutto volevamo ringraziare tutti i nostri abbonati ed i nostri backer per aver reso possibile la creazione di show come questo. Nulla di tutto ciò sarebbe stato possibile senza di voi. Per cui a voi va il nostro caloroso ringraziamento.
EKD: E grazie a voi tutti.
DV: Si.
EKD: Grazie a voi tutti che avete guardato questo episodio e che passate del tempo con noi ogni giorno.
DV: Io sono Eric Davis.
EKD: Cosa? No, non lo sei. Non sei Eric Davis. Se lo fossi, dovresti essere Eric Kieron Davis.
DV: Okay, io sono Eric Kieron Davis.
EKD: Ecco, ed io sono Davis Vorlick.
DV: Si conclude così questa puntata. Grazie ragazzi.
EKD: Ci si vede.
