Anche questa settimana Chris Roberts è lontano dagli studi di Santa Monica, per cui al posto del 10 for the President ecco a voi una nuova puntata del 10 for the Producers!


Dato che il presidente è negli UK, ci siamo seduti a tavolino con i Produttori Darian Vorlick e Lisa Ohanian per rispondere a 10 delle domande poste dagli Abbonati. In ogni episodio vengono affrontate 10 domande degli abbonati scelte dagli sviluppatori. Volete che anche la vostra domanda venga presa in considerazione? Potrete trovare maggiori informazioni sulle sottoscrizioni qui.

00:41 – Stabilire le Date di Pubblicazione
03:37 – Quante Persone Lavorano su una Nave
05:51 – Stabilire i Tempi Lavorativi
09:53 – Il Sistema di Produzione dei Componenti
11:58 – La Tempistica di Correzione dei Bug
14:06 – Collaborare con i Vari Studi
17:56 – Supportare i Dispositivi in Rete
20:01 – Lavorare ad un Gioco Crowd Funded
24:12 – Il Sistema di Produzione degli Scrittori
26:58 – Quando un Dipendente Lascia la Cloud Imperium

 

Articolo originale disponibile presso le Roberts Space Industries.


Trascrizione

Darian Vorlick = DV
Lisa Ohanian = LO

DV – Salve a tutti, e benvenuti ad un nuovo episodio del 10 for the Producers. Io sono Darian Vorlick, il coordinatore della produzione dei team Ingegneristici e di Design dell’Arena Commander, e qui con me c’è…

LO – Io sono Lisa Ohanian, e sono il coordinatore della produzione del team delle Navi.

DV – Dunque, prima di iniziare volevamo ringraziare tutti i nostri abbonati per aver reso possibile questo spettacolo. Senza voi ragazzi non avremmo mai potuto creare questa tipologia di contenuti entusiasmanti ed interessanti. Iniziamo con qualche domanda.

1. [0:42] MF140884: Oggigiorno nell’industria videoludica sembra essere diventata pratica comune stabilire una data di pubblicazione di un gioco, per poi rilasciare un prodotto completo soltanto a metà o posporre di continuo la sua uscita. Cosa state facendo per evitare di ricadere in una situazione simile, e quali potrebbero essere le motivazioni dietro questo fenomeno?

LO – La risposta alla prima parte della domanda, cosa stiamo facendo per evitare di ricadere in una situazione simile, è: tutto il possibile. La ragione per cui a volte succedono cose simili è dovuta al fatto che i giochi pubblicati da un grande publisher e destinati ai negozi al dettaglio, per cui sono state fissate delle date di marketing precise, vengono pubblicizzati a partire da un anno, un anno e mezzo prima dell’uscita. Ciò vuol dire che questi giochi dovranno essere pubblicati quel giorno, a prescindere da quanto siano o non siano rifiniti. In questi casi, è molto frequente che vengano rilasciati aggiornamenti o altre patch poco dopo la pubblicazione del gioco stesso per completare quanto era rimasto da fare e per risolvere alcuni dei problemi che non hanno potuto sistemare per tempo. Per quanto riguarda invece l’altro lato della medaglia, quando possibile la gente cerca di posporre la pubblicazione del gioco perché magari si è accorta che il percorso di sviluppo, oppure alcune delle funzionalità o delle cose implementate non funzionano come dovrebbero o come avrebbero voluto, per cui devono ritardare l’uscita per assicurarsi di rilasciare un prodotto di alto livello qualitativo, altrimenti si finirebbe per vendere un qualcosa di ancora incompleto, proprio come detto poco fa.

Per cui è sempre una questione di valutare i pro ed i contro della situazione.

DV – Oltre a questo, quando preordinate un gioco, ad esempio su Amazon, vedrete che sotto di questo è riportata una data di uscita anche qualora il publisher non abbia rilasciato informazioni a riguardo, e molte volte queste date vengono semplicemente fissate dal venditore prima che venga rivelata la vera data di pubblicazione. Ora, quello che facciamo noi della Cloud Imperium è interessante, perché non siamo parte di un’altra compagnia e non sono siamo obbligati a rispettare delle scadenze di marketing o di pubblicazione. Facciamo tutto noi, internamente. E queste date vengono fissate collettivamente dall’intera compagnia, a prescindere che si tratti di Chris Roberts, il team di Marketing, il team di Sviluppo o quello di Produzione; tutti noi possiamo dire la nostra sulla programmazione di queste date.

Nel caso del GamesCom, invece, era chiaro che la nostra scadenza fosse rappresentata proprio dal GamesCom. Dovevamo finire il lavoro prima dell’evento e non potevamo rimandarlo, per cui abbiamo fatto tutto il possibile per terminare per tempo. Per cui tutto dipende dalla natura della scadenza, dai settori coinvolti e da quanto sia importante rispettarla. Se può essere spostata e sentiamo che la qualità del prodotto ne risentirebbe qualora non lo facessimo, allora ovviamente preferiamo rimandarla e raggiungere gli standard qualitativi che ci siamo preposti.

LO – Molti giochi hanno anche una sorta di flessibilità di date interne, o possono permettersi di non annunciare o menzionare il proprio gioco fino a quando non avranno deciso quando farlo uscire o fino a quando non saranno certi di poter terminare il gioco entro tot tempo. Purtroppo, dal momento che abbiamo iniziato prestissimo a discutere e ad intrattenere i nostri backer, noi non ci possiamo permettere una cosa del genere.

DV – Già. lo sviluppo del nostro gioco è molto trasparente.

LO – E’ un’ottima cosa, ma è anche ricca di sfide e difficoltà.

DV – Potete vedere ogni piccola cosa su cui…

LO – Ogni secondo.

DV – Allora, passiamo alla seconda domanda.

LO – Questa mi piace parecchio.

2. [3:44] Archilele: In genere per quante mani passa una nave prima della sua pubblicazione?

DV – Tutta tua.

LO – Dunque, quando ho letto per la prima volta questa domanda ho davvero pensato che fosse ottima, ma mi ci è voluto un po’ per fare mente locale e capire come avrei potuto rispondere, perché è un dato che neppure io conosco bene. Persino nel caso delle navi più piccole, anzi, in realtà proprio nel loro caso, credo che prima della loro pubblicazione ci lavorino sopra circa 30-40 persone. In questa stima rientrano tutti coloro che hanno partecipato alle prime riunioni di design, a quelle di revisione delle immagini artistiche iniziali, tutti gli artisti concettuali, le persone che hanno realizzato i modelli e i direttori che li hanno guidati, anche se non ci hanno lavorato direttamente. In altre parole, in questa stima rientrano tutti coloro che hanno toccato o guidato lo sviluppo della nave, e stiamo parlando di una nave di piccole dimensioni, prima che venga presa in carico del team di QA e prima che inizi la fase di correzione dei bug. Solitamente, quando si arriva a questo punto i numeri crescono parecchio, perché ci lavorano un sacco di persone, tutto soltanto per assicurarci che ogni componente della nave si comporti e sia come vogliamo e debba essere. Quando si inizia a lavorare sui bug, spesso non si chiamano in causa gli stessi artisti, designer o programmatori che hanno inizialmente sviluppato la nave, a volte si affida l’incarico a chi è disponibile sul momento e sa come risolvere il problema, per cui a questo punto le cose si fanno caotiche.

Ma se ci limitiamo soltanto allo stadio di sviluppo, alla bozza iniziale, prima di arrivare al QA ed entrare nella fase di pre-produzione o in quella di produzione, direi che nel caso di una piccola nave la stima sarebbe proprio questa: 30 o 40 persone.

Ovviamente, escludendo anche il team del marketing e tutto il resto. Mi sto riferendo esclusivamente allo sviluppo della nave.

DV – Terminata questa fase, la nave passa per tante altre mani, come quelle del marketing, che si deve assicurare che i nostri piani di vendita siano corretti, che le stime del costo siano giuste, che il QA possa davvero iniziare a testare il modello una volta terminata la fase di produzione, e… Non so cosa altro ci potrebbe essere dopo, non ci ho mai pensato. Anche se l’artista originale non fosse disponibile, in genere viene incaricato di sistemare i problemi riscontrati chiunque abbia il tempo e la competenza per farlo.

LO – Magari c’è una persona libera che è in grado di sistemare le texture, con cui abbiamo qualche problema, per cui il lavoro viene assegnato a lui.

DV – Gran parte di questo lavoro potrebbe così essere assegnato, invece che, ad esempio, a Daniel Kamentsky, che è uno dei nostri artisti, a…

LO – Gage ha dato qualche ritocco a navi che ne avevano bisogno; non le aveva mai viste prima, ma sapeva come risolvere i problemi esistenti.

DV – Insomma, a chiunque abbia le capacità per farlo.

LO – Prossima domanda.

DV – Ooh, questa invece piace a me.

3. [6:00] Gravy: Potreste dare qualche consiglio su come stabilire dei tempi lavorativi realistici, specialmente quando si ha a che fare con argomenti con cui il team non ha mai lavorato in passato (sembra proprio che parecchio del lavoro relativo al netcode ed alla tecnologia per i server costituisce un terreno inesplorato)? Secondo voi, è meglio mettere in conto, insieme alla programmazione iniziale, un intervallo di tempo flessibile in anticipazione di qualche problema o ritardo (che sembrano essere apparentemente inevitabili), oppure ripianificare tutto da zero nel momento in cui si finisce fuori strada, ma tenendo conto della situazione attuale?

DV – Questo è puro lavoro di produzione. Il nostro compito consiste proprio nel creare questi calendari. Una delle cose di cui si occupa Lisa è il calendario di sviluppo di tutte le navi, e la cosa interessante sulla produzione è che nel momento in cui si redige un calendario, questo è già diventato obsoleto. Ciò è dovuto al fatto che ci sono sempre nuovi avvenimenti: le cose cambiano, la scaletta di lavoro degli sviluppatori viene modificata e diventano disponibili nuove risorse. O, viceversa, risorse già presenti non diventano più disponibili.

LO – Sarebbe meglio definirlo come una specie di documento vivente: viene aggiornato e modificato quotidianamente. Ma senza dubbio ci sono periodi, soprattutto quando si è appena iniziato a lavorare su qualcosa, in cui mettiamo in conto per lo sviluppo un intervallo di tempo abbastanza flessibile. Mano a mano che il lavoro procede è possibile effettuare delle stime sempre più precise, solitamente utilizzando come riferimento quanto fatto per le altre navi. Ci sono stati casi in cui non potevamo dare una stima precisa di quando sarebbe stata pronta una nave perché il suo sviluppo prevedeva di affrontare tante nuove questioni, era necessario sviluppare nuove funzionalità uniche di cui andava definito anche il gameplay. Ed in questi casi semplicemente aggiornavamo le stime quando possibile, seguendo il lavoro da vicino, fino a quando, arrivati ad un certo punto, non era possibile iniziare a stabilire delle date più accurate.

Fortunatamente abbiamo un ottimo team di marketing che è molto reattivo, per cui queste cose non sono mai state un problema. Quando alcune navi venivano completate prima del previsto o, come è successo più di frequente, più tardi di quanto preventivato…

DV – Oltre a questo, c’è da dire che parecchie tecnologie sono molto simili tra loro. Per esempio, diciamo che affidiamo un certo lavoro ad uno dei nostri animatori, Mark McCall. Se deve realizzare l’animazione di sparo di un’arma, e questa è molto simile al cannone di un’altra nave che abbiamo sviluppato in passato, possiamo effettuare una stima del tempo che necessiterà per realizzare quell’elemento basandoci su quanto fatto in passato. Per cui quanto meno abbiamo una stima grossolana di quanto tempo potrebbe richiedere quel lavoro.

Adesso, se invece il lavoro prevede di sviluppare qualcosa di completamente nuovo, diciamo che dobbiamo creare una sorta di raggio riparatore istantaneo o un aggeggio del genere… Non è una funzionalità che sarà presente nel gioco, stavo facendo un esempio ipotetico…

LO – Già, stavo giusto pensando a cosa intendessi.

DV – Se si tratta di qualcosa che non abbiamo mai fatto in passato, il nostro compito di produttori prevede di chiedere agli sviluppatori quanto pensano che impiegheranno a terminare il lavoro e di raccogliere le loro opinioni. Se andassimo da un designer, questo ci potrebbe dire che gli servirebbe un giorno per realizzare il progetto, un altro per redigere la bozza del design e forse un altro paio per completare la parte artistica, per cui noi prenderemmo nota di tutto questo ed aggiorneremmo i nostri piani con queste date.

LO – In realtà, è qualcosa che facciamo anche quando pensiamo che il lavoro sia simile o comparabile con qualcos’altro che è stato già fatto in passato, perché il nostro lavoro non prevede di creare qualcosa, ma di facilitare i compiti altrui. E poi non è detto che il tempo richiesto sia lo stesso che è stato impiegato per realizzare qualcosa di simile: mettiamo il caso di avere per le mani un’arma molto simile ad un’altra sviluppata in precedenza, e che il completamento di quest’ultima abbia richiesto tre giorni di lavoro. Mark potrebbe far notare che non abbiamo tenuto in conto un qualche elemento, o che alcuni componenti che sono richiesti per quest’arma non sono ancora stati completati, o che, magari, in realtà sono cose completamente differenti, per cui ogni volta che c’è qualcosa di nuovo su cui lavorare, effettuiamo una serie di controlli per assicurarci di non tralasciare nulla.

DV – Un altro punto interessante è il fatto che impariamo dal nostro lavoro e da quanto fatto in passato. Per cui se vediamo che in precedenza il completamento di un certo processo ha richiesto tre giorni, dal momento che nel frattempo potremmo aver sviluppato nuovi metodi per rendere il lavoro più efficiente e veloce, alla fine quello stesso lavoro potrebbe richiedere soltanto un giorno e mezzo o due invece che i tre originali. Questo è un altro dei vantaggi ricavabili dal lavoro dei produttori, oltre che quello di mantenere le date aggiornate. Siamo in grado di stimare quanto tempo impieghi adesso una cosa rispetto a quello che era stato necessario in passato e possiamo vedere in quali campi siamo migliorati ed in quali, invece, è necessario allocare più tempo di sviluppo.

LO – Ed è quello che stiamo osservando al momento con il sistema di produzione dei componenti. Ciò ci porta alla prossima domanda, quella di Logical Chimp.

DV – Gli scimpanzè sono razionali?

LO – Questo si.

4. [10:05] LogicalChimp: Lo scorso anno si è parlato parecchio del ‘Sistema di produzione dei Componenti’, e di come vi aspettavate di ‘metterlo in azione’ quest’anno. Da allora non si è più saputo nulla a riguardo. Di conseguenza, volevo chiedervi se potevate fornirci qualche aggiornamento in merito e dirci quando potremmo iniziare a vedere nello store qualcosa di diverso dalle solite armi e dai soliti scudi.

LO – Dunque, non so dirvi quando vedrete del nuovo materiale nello store perché quello è il lavoro del marketing, è il regno di Ben. Ma di recente abbiamo fatto numerosi progressi sul sistema dei componenti. Se avete visto l’edizione della Forma delle Navi di qualche settimana fa, abbiamo parlato con Elwin dei piani di sviluppo dei componenti e da allora i ragazzi ci hanno lavorato senza sosta. Abbiamo definito fin nel minimo dettaglio la struttura del sistema di produzione dei componenti, soprattutto a vantaggio del reparto artistico e di quello di design, che è una cosa fantastica. Mi sono presa una pausa dal lavoro riguardante la programmazione dello sviluppo dei componenti da qui alla fine dell’anno per venire qui e concentrarmi su quest’altro aspetto. Abbiamo fatto un mare di riunioni sull’argomento. Abbiamo almeno un primo progetto preliminare di una dimensione di ogni tipologia di componenti, per cui ci siamo già fatti un’idea di quali saranno le loro dimensioni ed il loro aspetto, perché ovviamente, ad esempio, i generatori degli scudi della dimensioni minore e quelli della dimensione maggiore saranno molto diversi. Ma speriamo di poter introdurre degli elementi visivi che permettano di riconoscere immediatamente la natura dell’oggetto che si avrà davanti. Dunque, per il momento abbiamo definito il progetto preliminare artistico del modo in cui potremo fornire questi elementi e Gage, assistito da Elwin, sta lavorando su svariati whiteboxes per sviluppare ulteriormente questo concetto.

DV – Per quanto riguarda il versante del design tecnico, Matt Sherman è il nostro guru degli oggetti/componenti.

LO – E’ fantastico. Anche lui ha iniziato a progettare diversi oggetti e, come abbiamo detto in precedenza, ha ribadito che se per realizzare il primo ci metterà X giorni, per il secondo ne impiegherà soltanto la metà, perché noi tutti sappiamo che dopo aver completato qualcosa di nuovo per la prima volta, lavorarci nuovamente sarà più semplice e veloce. So che abbiamo parlato poco di questo sistema, ma stiamo continuando a lavorarci ed a far progressi; semplicemente parlare dell’argomento non è tanto interessante quanto discutere delle navi.

DV – Come ha già detto Lisa, è un altro campo su cui stiamo lavorando, non ce ne siamo dimenticati.

LO – No, assolutamente. Me ne occupo quotidianamente.

5. [12:09] Mookie: E’ bellissimo che i nuovi rilasci dell’AC stiano risolvendo sempre nuovi bug o introducendo cose nuove, ma la mia domanda è: quando inizierete a sistemare alcuni degli elementi che non funzionano ormai da parecchio tempo? Cose come il problema delle collisioni delle navi o gli oggetti presenti nei nostri hangar, l’impossibilità di usare il greycat nell’hangar Aeroview, oppure il fatto che la voce fuori campo dei compagni d’ala sia sparita. Capisco che non si tratti di questioni fondamentali o super importanti come le nuove funzioni superfighe, ma vorrei pensare che, quanto meno, i problemi esistenti vengano trattati nello stesso modo in cui lavorate a quelli nuovi.

DV – In realtà questo è un argomento di cui si è discusso durante una delle riunioni dei produttori cui hanno partecipato il nostro produttore senior, Eric Davis, Lisa ed anche il nostro compatriota negli UK, Ricky Jutley.

LO – Con quella capigliatura.

DV – Si, entrambi i nostri produttori senior hanno una capigliatura fantastica.

LO – Capigliature fantastiche.

DV – Una delle funzioni presenti nel nostro programma di gestione, JIRA, è un registro di tutti i problemi esistenti su cui dovremo prima o poi lavorare. Questo registro costituisce una sorta di lista dei desideri dei problemi che potremmo aver trascurato da parecchio tempo.

LO – Sono tutti classificati per priorità da blocker a critico, fino ad irrilevante.

DV – In quanto produttori, il nostro compito è di stabilire quanto sia importante sviluppare le correzioni a questi problemi. Per esempio, se stiamo cercando di rendere la Retaliator pilotabile per il GamesCom, un piccolo pezzo di texture compenetrata nell’ambiente dell’hangar non sarà importante come la tecnologia necessaria per far volare la nave. E’ vero, sono due cose completamente differenti. Ma come produttori, dobbiamo stabilire cosa queste…

LO – A chi assegnarle…

DV – Esattamente, chi ci lavorerà, ma se scopriamo che abbiamo bisogno di dedicare delle risorse su alcuni aspetti importanti dell’Arena Commander, allora questi bug puramente estetici verranno messi da parte fino a quando non avremo finito questo lavoro. Ora, tornando a quella riunione della produzione tenutasi di recente, vi posso dire che stiamo iniziando a dare maggiore attenzione alla lista dei problemi passati ancora esistenti e, in preparazione dell’uscita della 2.0, dovremmo avere lo spazio di manovra necessario per risolverne alcuni. A prescindere che si tratti di problemi tecnici, meccanici o estetici, ci dovremo assicurare che per la pubblicazione dell’AC 2.0 il numero di questi bug si sia ridotto e che non siano più così problematici come in passato.

6. [14:17] Acaro: Che percentuale del lavoro distribuito tra i vari studi può essere davvero portato avanti separatamente, e quanto di questo invece richiede che più studi lavorino assieme sullo stesso aspetto del gioco? Come riuscite a sincronizzare il lavoro svolto da studi differenti che probabilmente hanno anche fuso orari diversi?

LO – Questa è un’ottima domanda, ed in realtà è anche una delle nostre sfide più grandi. Allora, quando decidiamo su cosa lavorare, prendiamo come esempio il GamesCom, cerchiamo di dividere i compiti in maniera sensata. Non affidiamo il lavoro riguardante la stessa nave ad un artista ed un designer che fanno parte di due studi diversi, magari il primo si trova negli UK ed il secondo qui da noi, perché non potrebbero comunicare, non potrebbero scambiarsi pareri ed opinioni.

DV – Logisticamente parlando, sarebbe impossibile.

LO – Loro non sono necessariamente a conoscenza dello stato di sviluppo di ogni elemento, e si potrebbe dover aspettare anche per otto ore prima di scoprire la risposta ad una domanda basilare che potrebbe star bloccando il lavoro. Dunque cerchiamo di dividere il lavoro in maniera intelligente. C’erano un mare di navi… Riprendendo l’esempio del GamesCom, gli studi degli UK si sono occupati di buona parte della tecnologia del grande mondo e dell’infrastruttura di quello che avete visto durante le demo, ed hanno lavorato anche su alcuni progetti artistici riguardanti diverse navi, ed ovviamente avevano la capacità ed il talento richiesti per completare il lavoro di impostazione tecnica e di configurazione degli elementi delle navi facendo un ottimo lavoro. Ma dal momento che sapevamo che avevano bisogno di concentrarsi sugli altri compiti, si sono limitati, una volta completata la parte artistica, a passarci tutte le navi in sviluppo così che potessimo completare noi la configurazione tecnica. Questo perché in tal modo avremmo avuto una distinzione netta degli ambiti di lavoro. Alcune parti dell’apparato di produzione delle navi sono fortemente intrecciate e legate tra loro, ma in questo caso, quando ci hanno passato il materiale, avevamo a disposizione un punto di separazione dei compiti ben preciso, e grazie ai file ricevuti avevamo tutto il necessario per completare il lavoro. Aveva senso che fossimo noi ad occuparci di questi ultimi interventi sulle navi perché, fondamentalmente, avremmo potuto dedicare l’intero team locale allo sviluppo di queste mini-funzionalità, mentre loro si sono potuti concentrare su ciò di cui avevano maggior bisogno.

DV – L’altro lato della medaglia riguarda quei casi, peraltro molto frequenti, in cui è necessario collaborare a livello internazionale. Steven Humphreys, uno dei nostri ingegneri degli studi negli UK, ha lavorato su parte del sistema GOST, ma per farlo il team di design e quello ingegneristico hanno dovuto scambiarsi giornalmente una serie di mail in maniera tale che, quando arrivavamo a fine giornata, ai ragazzi negli UK veniva spedita una mail contenente la lista dei progressi fatti fino a qual momento, gli elementi su cui stavamo ancora lavorando, cosa avevamo completato e quali bug erano stati risolti, per cui il team degli UK poteva utilizzare queste informazioni come punto di riferimento per la continuazione del loro lavoro, e quando invece erano loro ad arrivare a fine giornata, facevano lo stesso con noi, mandandoci un riassunto di quello che avevano fatto. Dunque durante lo sviluppo del GOST ci mantenevamo costantemente informati su quello che ciascuno di noi stava facevando, che fosse Stephen Humphreys da loro o Kirk, Dan e Mark Abent da noi, e ciascuno di noi poteva continuare il proprio lavoro basandosi su quello che gli altri colleghi erano riusciti a fare quel giorno. La stessa cosa vale per quando venivano completati gli elementi che facevano parte del GOST. Ci sono diverse collaborazioni internazionali in atto, ma la loro praticabilità dipende dal tipo di funzionalità su cui si deve lavorare. In alcuni casi non è neppure necessario coordinarsi con gli altri studi.

LO – Ed il nostro supervisore CG, Forrest, ci sta aiutando davvero tanto nel nostro lavoro fornendoci maggiori dettagli sui ticket dei bug e su altri elementi del nostro dabatase, in maniera tale che, quando dobbiamo andare a parlare con qualcuno, non solo sappiamo su cosa stanno lavorando in quel momento i vari team, ma anche a che punto è il loro lavoro, quanto tempo impiegheranno per completarlo e da quanto ci stanno lavorando sopra. Sono informazioni assolutamente inestimabili, perché ci permettono di capire come stanno andando le cose e come ripartire meglio i compiti tra gli sviluppatori.

DV – Ipoteticamente parlando, utilizzando JIRA uno sviluppatore potrebbe lasciare un commento su qualcosa su cui sta lavorando in quel momento, e se un altro sviluppatore aprisse quell’elemento o quel compito, potrebbe vedere lo stato del lavoro, quel commento e tutte le altre informazioni necessarie per riprendere lo sviluppo dal punto in cui l’altro lo ha lasciato.

La prossima domanda è di…

7. [18:07] Dastardly: Nel design del simulatore (SC) verranno integrati altri elementi oltre al supporto alle periferiche di rete come tablet e simili? Per esempio, verranno supportate le configurazioni multi monitor con touchscreen? Io possiedo un simpit formato da 4 monitor [NdT: è uno spazio che riproduce l’abitacolo di un aereo, di una macchina o altro], e due di questi sono touchscreen. Mi piacerebbe tantissimo poter usufruire dell’immersione fornitami dall’interfacciarmi con i controlli dell’abitacolo.

DV – Mi piace questa domanda.

LO – Perché è un’idea stupenda.

DV – Lo è. Sebbiamo stiamo lavorando al supporto ai tablet, attualmente non siamo arrivati ad un punto tale da poter dare una risposta precisa in merito. Dunque, per quanto ci piacerebbe che le periferiche avessero un qualche tipo di funzionalità in-game, come ad esempio la possibilità di utilizzare una configurazione a quattro monitor, con ciascuno di essi dedicato ad un comando particolare, uno per la visuale laterale ed un altro per quella posteriore, la fattibilità di tutto questo dipenderà in ultima analisi da Chris, dalla sua visione del gioco e da cosa voglia utilizzare per supportarla. Per cui, sebbene questa domanda riguardi più il design del gioco, rientra nella categoria di quelle di lui leggiamo spesso: “Supporteremo questo? Supporteremo quello?” La risposta è grosso modo sempre la stessa: ci piacerebbe, ma dovremo prima vedere come evolverà il gioco nel tempo. Non abbiamo una risposta precisa a questa domanda, semplicemente dovremo aspettare e vedere.

LO – Un altro aspetto della questione è la scala delle priorità: ogni volta che vogliamo implementare o sviluppare una qualche funzione, dobbiamo sempre prima dare la priorità alle questioni più importanti. Per riutilizzare l’esempio del GamesCom, è preferibile evitare una piccola compenetrazione del bordo delle scarpe con l’ambiente, oppure assicurarsi che la nave esploda? Dobbiamo concentrarci sugli elementi prioritari, ed una volta che è stato compiuto lavoro sufficiente possiamo presentare il budget e la scaletta di sviluppo richiesti per il completamento di questa funzionalità a Chris, che può quindi prendere una decisione più ponderata ed informata.

DV – Per esempio, anche se qualcuno disponesse di due monitor, ci vorremmo prima assicurare che questi mostrassero correttamente l’abitacolo, e che un altro giocatore seduto davanti ad un altro pc possa vedere la schermata ingegneristica o quella delle armi senza riscontrare alcun problema. Vogliamo assicurarci che tutte queste funzioni siano implementate e funzionanti prima di iniziare ad aggiungere nuove elementi sempre più complessi. Prima viene la funzionalità, e soltanto dopo si può iniziare eventualmente a pensare all’estetica figa o agli oggetti di lusso.

8. [20:10] AragornBH chiede: Visto che Star Citizen è il primo tra i giochi crowd-funding che sta tracciando nuovi sentieri nel mondo dello sviluppo dei videogiochi, e che Chris Roberts vi ha chiesto di creare non solo un videogioco ma un intero universo, com’è il morale del vostro team? Come fanno i vostri artisti, scrittori, e designer ad implementare così tanti dettagli per quanto riguarda astronavi, stazioni spaziali, pianeti e/o personaggi che rischiano di far deragliare i piani di produzione? Avete evitato di assumere persone con poca esperienza, perché altrimenti non avreste avuto abbastanza tempo per allenarle ed evitare di far slittare tutto a chissà quando?

LO – Vorrei prima rispondere alla seconda parte della domanda…

DV – Il lavoro dei produttori è proprio questo!

LO – Sì, questo è il motivo per cui esistono i produttori. Non faremmo il nostro lavoro se non assumessimo brave persone. Non abbiamo evitato di assumere persone con meno esperienza. In realtà c’è un alto numero di persone, almeno rispetto ai normali team di tripla A, che non hanno molta esperienza, ma in compenso hanno talento da vendere e lo sanno applicare; alcuni non vogliono ricevere credito per il loro lavoro perché è il loro primo vero grande progetto, il che comporta anche una prospettiva di lavoro unica. Invece di una persona che è in questa industria da, diciamo, 10 anni, si potrebbe prendere qualcuno che non abbia lo stesso livello di esperienza, ma che possa offrire una prospettiva nuova e differente per risolvere quei problemi a cui la prima persona ha lavorato durante i suoi 10 anni di carriera. Come ho già detto, abbiamo più persone con poca esperienza del normale, ma il talento c’è e questo è quello che cerchiamo… E nel team ci sono molte altre persone esperte. E’ una miscela che funziona.

DV – Questo è il motivo per cui esistono i produttori – dobbiamo far sì che tutti rimangano nei piani stabiliti. Però, per spiegare come sia strutturata la nostra gerarchia d’ufficio, almeno per quanto riguarda lo sviluppo – utilizzerò proprio un team di design come esempio – Abbiamo Dan Tracy a capo dei designer, e nel suo ufficio a LA aiuta a mantenere sui binari il lavoro da svolgere ed a dividerlo in più compiti, in modo che sia più facile da completare. Per esempio potrebbe chiedere a Calix Reneau di scrivere qualche nota di design e quella nota viene poi verrebbe passata a Kirk Tome… Che troverà un modo per implementare quel design, e Matt Sherman potrebbe lavorare sui componenti di quell’astronave. Tutti hanno certe responsabilità, ma queste responsabilità devono essere divise dai produttori, che fanno sì che tutto si svolga come si deve.

LO – Voglio aggiungere una cosa, l’aspetto divertente di tutto ciò è che abbiamo un… Diciamo un problema… Chris Roberts ha sempre così tante idee e visioni, e ce ne parla in continuazione, ma così riusciamo a capire meglio quello che intende realizzare per il gioco, nonché come realizzarlo, e grazie a questo siamo in grado di prendere delle decisioni più consapevoli di quando e come certi elementi andranno implementati.

DV – Ma sopratutto, quando si ha una stanza piena di gente molto creativa, tutti vogliono lavorare su tanti aspetti diversi nello stesso momento. Magari hai un designer che si sta occupando di una certa caratteristica – una volta finito quel lavoro gli possono essere balzate in testa tante di quelle idee da voler iniziare ad occuparsi di questo o quel compito, deviando così dai piani di sviluppo, tipo una patch di cui abbiamo bisogno. E’ compito del capo di quella divisione, o dei produttori, ricordargli che deve lavorare in una certa direzione, e solo dopo che avremo finito potrà lavorare su ciò che vorrà. Sono persone creative, ma ci deve essere qualcuno che tenga tutto in ordine.

LO – Far sì che ogni persona ottenga il tempo necessario a svolgere il proprio compito è un’arte ed una scienza – non devono sentirsi come se stessimo per sgozzarli da un momento all’altro, ma non va bene neppure dargli troppa corda.

DV – Già. Se non li lasciamo lavorare di tanto in tanto a quello che vogliono, allora inizieranno a stancarsi. Quindi dobbiamo far sì che abbiano del tempo per sé – non voglio dire una ricompensa, non sono dei cani in addestramento – ma dobbiamo fare in modo che incanalino la loro creatività verso un obiettivo preciso per il gioco.

LO – Bene, abbiamo un’altra domanda. Questa volta è da Kinshadow…

9. [24:19] Kinshadow chiede: In passato vi siene concentrati molto sui piani di sviluppo delle astronavi. Sono curioso, anche gli altri elementi non artistici del PU ricevono lo stesso rigoroso trattamento? Tipo la trama o la creazione delle missioni: esiste un piano di sviluppo per scrittori -> designer del gameplay -> programmatori, o è un qualcosa più ad hoc?

LO – Allora, per prima cosa i piani delle astronavi non sono solo elementi artistici. La maggior parte è materiale artistico perché è quello che prende più tempo, ma include tutto, partendo dall’idea iniziale fino al prodotto finito in Arena Commander e, in futuro, nel gioco completo di Star Citizen. Il tranello con le astronavi è che sono la spina dorsale del gioco, perciò abbiamo bisogno dell’opinione del direttore del PU e quella di chiunque abbia lavorato a qualsiasi elemento di un qualsiasi modulo, così che le astronavi funzionino con qualsiasi cosa abbiano in mente per quella specifica parte del gioco su cui stanno lavorando. Tutto questo richiede continue revisioni delle astronavi, tuttavia ogni cosa ha il proprio piano di sviluppo. E’ un modo sofisticato di dire come viene sviluppato ogni elemento.

DV – Oppure una catena di montaggio.

LO – Sì, per ogni cosa sia che sia stata formalizzata o meno esista una struttura di produzione precisa, che consiste in una sequela di persone che si scambiano varie parti del lavoro, per poi fermarsi per assicurarsi che i responsabili controllino che tutto funzioni a dovere.

DV – Un buon esempio sono i piani di produzione dei personaggi: c’è una struttura di sviluppo specifica deputata alla realizzazione delle animazioni. Quello che facciamo in ogni fase dello sviluppo – come esempio utilizzeremo quello delle astronavi – dopo aver concluso la fase del whitebox ma prima che inizi quella del graybox, dobbiamo effettuare una serie di controlli, del tipo: Abbiamo fatto tutto? L’abbiamo completato? Questa persona qui ha già fatto il suo controllo? Il supervisore è pronto a dare l’ok? E la produzione? Per citare il sistema di controlli di Lisa, ci sono una serie di protocolli il cui scopo è far sì che certi aspetti vengano controllati da chi di dovere. La stessa cosa succede con i personaggi, con Arena Commander, con qualsiasi cosa che abbia a che fare con il design o la programmazione. Se è il codice, allora i responsabili di questo reparto dovranno rivedere il lavoro svolto prima che possa essere implementato nel gioco. Questo è ciò che avviene durante lo sviluppo di ogni parte del gioco: come ha detto Lisa, è un processo continuo dall’inizio alla fine. Qual è il risultato finale? Quali passi sono stati fatti? Succederà la stessa cosa ogni volta che dovremo progettare qualcosa di simile? Ogni astronave deve essere sviluppata in un certo modo, mentre ogni personaggio deve essere creato seguendo un altro processo.

LO – E più aree o moduli hanno a che fare con una certa cosa, più grande diventa il processo. C’è molto di cui discutere quando si lavora alle astronavi, quindi sono molte di più le persone che dovranno intervenire ed è per questo che ne parliamo così tanto. Ogni cosa, però, ha i propri piani di sviluppo.

10. [27:05] Sultan chiede: Ora che il direttore generale è passato alla Blizzard, mi viene da pensare che non aveva fiducia nel progetto. Potete dirci se lo rimpiazzerete con una persona migliore con una vera passione per questo progetto, la stessa che abbiamo noi? Grazie

DV – Per prima cosa voglio chiarire che ogni persona in questo team ha grande passione per questo progetto: non saremmo qui se non condividessimo la passione che Chris ha per questo gioco.

LO – Solo perché qualcuno ha lasciato il team non vuol dire che non erano appassionati. Abbiamo avuto persone che se ne sono dovute andare per motivi personali e persone che hanno ricevuto proposte lavorative che sognavano fin da piccoli. Si può essere appassionati di più progetti allo stesso tempo ed il fatto che si abbia un lavoro non vuol dire che…

DV – In più, il continuo flusso di persone che passano da una compagnia all’altra è una cosa perfettamente normale nel corso dello sviluppo di un videogioco. In ogni compagnia di videogiochi ci sono persone che vanno e vengono, è un’industria molto dinamica in cui nuove persone vengono assunte ed altre si dimettono ogni giorno. Una persona che se ne va non è un chiodo sulla bara del progetto, ne indica che il valore del progetto sia diminuito. Nel corso dell’ultimo anno abbiamo assunto un buon numero di persone che sono appassionate come tutti gli altri. La qualità del videogioco non diminuirà per questo, e non ci vedrete stancarci di questo progetto.

LO – Un’altra cosa, i produttori che ci hanno lasciato di recente sono stati qui per anni, alcuni erano qui persino dall’inizio del progetto. Sarei più preoccupato se vedessi un gruppo di produttori che rimangono per tre mesi e poi se ne vanno. Quello sì che sarebbe un segnale di…

DV – Una mancanza di impegno.

LO – Sì, una mancanza di impegno, ma non è quello che sta accadendo.

DV – Ognuno qui tiene a questo progetto. Siamo qui per rimanere. Alcune persone, come ha detto Lisa, se ne vanno per motivi personali, altre per motivi professionali, alcune ottengono la possibilità di avverare i propri sogni fuori da questo stato. Non vuol dire che sono rimasti delusi da questo progetto, non vuol dire che non hanno fiducia in esso. Ognuno ha le proprie ragioni. Sosteniamo ogni persona interessata a perseguire i propri obiettivi al di fuori di questa compagnia, e sebbene siamo tristi di vederli andare via, siamo riconoscenti per il loro contributo.

LO – Abbiamo mantenuto i contatti con tutti loro.

DV – Assolutamente sì. Ho un sacco di amici che hanno lavorato qui. Se conoscete qualcuno che ha le abilità e la passione per portare avanti questo progetto, verso la visione di Chris, siete pregati di controllare il nostro sito e vedere quali opportunità sono disponibili. Molti dei nostri artisti ed impiegati erano nostri fan, ad esempio Elwin era un backer che ha contribuito a The Next Great Starship.

LO – E Gage e Dan…

DV – Già, li abbiamo assunti per le abilità che hanno dimostrato, perciò se sono appassionati, se hanno le abilità giuste, allora mandateci il vostro curriculum. Non vediamo l’ora di avervi a bordo con noi. E’ un grande progetto e un grande team di cui far parte.

LO – Eccetto per questo tizio.

DV – Già, per lui non saprei.

*LO ride*

DV – E’ difficile stare seduti vicino a lei.

LO – Non stai più seduto di fianco a me.

DV – Grazie a Dio. Dunque, grazie di nuovo per esservi uniti a noi in questo episodio del Ten for the Producers. Io sono Darian Vorlick.

LO – Io sono sempre Lisa Ohanian.

DV – Vorremmo ringraziare tutti gli abbonati per aver reso possibile questi entusiasmanti contenuti. Come vi abbiamo sempre detto, tutto questo non sarebbe stato possibile senza di voi, per cui ve ne siamo grati, e grazie a tutti i backer per aver trasformato in realtà Star Citizen. Come avete avuto modo di vedere al GamesCom, il nostro è un incredibile progetto e siamo fieri di farne parte.

LO – Già, grazie ragazzi.

Traduzione a cura di Darnos e FireWithinMidnight.

 

Trascrizione originale disponibile presso ImperialNews.