Ecco arrivare anche le domande per gli sviluppatori! Oggi Mark Abent e Randy Vasquez ci parlano un po’ dei bug!


 
[1:22] D: I bug diventano mai ciclici?
R: Sì, tutte le volte, sistemare un problema ne causa un altro e correggere quest’ultimo fa riapparire il primo bug. E così devi tornare sui tuoi passi e sistemarlo. La QA è davvero utile. Tutto questo è successo anche con la 2.4 in certi casi.
 
[3:56] D: Tempo fa c’era quella storia riguardo il movimento delle astronavi buggato e nessuno riusciva a capire quale fosse il problema fino a che qualcuno non disse qualcosa riguardo il CryEngine che simulava come se tutto fosse sott’acqua. Ci sono altre storie simili di bug da incubo che in verità erano semplici da sistemare se solo si fosse saputo una particolare stranezza del motore di gioco?

R: Circa 2 anni fa, John Pritchett era uscito dal Kansas e tutti si stavano impegnando per pubblicare Arena Commander ma le navi iniziarono a comportarsi in maniera anomala. John trascorse 2 o 3 giorni provando a capire quale fosse il problema. Alla fine si avvicinò agli ingegneri e disse “le nostre navi sono sott’acqua”. Praticamente il CryEngine di default ha acqua sottoad ogni livello perciò qualsiasi cosa vada sotto il valore 0 nell’asse Z viene considerato sott’acqua anche se sei nello spazio! Una volta capito questo fu semplice sistemare il tutto.

[7:24] D: Quali sono i pro e i contro di sviluppare i modelli “al chiuso” e “all’aperto” come in Bugsmasher?


R: Lo sviluppo “al chiuso” permette un lavoro più nel dettaglio senza che si debba essere interrotti dal processo di debugging, ma è carente nella quantità di test approfonditi. Lo sviluppo aperto spesso dispone di molti più test, ma può distrarre più spesso dai compiti a portata di mano.

[9:58] D: Venite assegnati per correggere i vostri bug? CIG dispone di un sistema per sistemare i bug di design? Come si confrontano le correzioni dei bug del codice con gli errori di design?


R: Ogni team lavora a stretto contatto con tutti gli altri dipartimenti. Potresti aver bisogno di parlare con qualcuno di un altro team per sistemare un bug. Quando si implementa un nuovo sistema, spesso ci consultiamo con gli altri dipartimenti che usano quel sistema per sapere le loro opinioni sul flusso di lavoro. Ognuno ha i propri processi da seguire e le proprie esigenze.

[12:51] D: Vi capita mai di trovare un bug e di sistemarlo, e in seguito trovarne l’origine dovendo risistemare tutto un’altra volta?


R: Sì! Capita molto spesso di trovare e sistemare un bug, ma la causa viene trovata solo in seguito, certe volte anche dopo diversi mesi nei quali sono state aggiunte funzioni o altri pezzi di codice.
 
[16:30] D: Secondo voi quanta parte della società si impegna per la release? E quanta invece continua semplicemente a sfornare contenuti senza tener conto del ciclo?

R: Dipende dalla release. Ognuno lavora ad una cosa differente puntando ad un obiettivo comune per ogni data di rilascio. Certe volte ti ritrovi una nuova funzionalità per aiutare a sistemare i bug per la release. Cambia per ognuna di esse – sono richieste diverse risorse.

[20:13] D: Qualche tool che avete sviluppato internamente ed è in uso?


R: Un sistema di messa a punto in base all’obiettivo progettato da John Pritchett che aiuta i designer ad inserire le informazioni in un database. DataForge, che evita di dover fare XML o script manuali. Item port editor, che muove/elimina certe cose in gioco.
 
[25:22]D: Com’è stato il passaggio da sviluppatore a produttore?

R: È ancora in corso.

[31:43] D: Per le patch con cambiamenti fondamentali il team del Live fa qualcosa di speciale per prepararsi oppure il passaggio da PTU e D&R è lo stesso?


R: Non è che ci sia un team del Live. Le risorse vengono spostate all’interno dell’azienda dove è più richiesto dalla release – in genere si tratta delle persone che lavorano a contenuti che sono obiettivi previsti nella release. C’è un passaggio di consegne giornaliero tra il Regno Unito e l’America – e il Regno Unito gestisce anche gli affari di Francoforte. A volte abbiamo bisogno di forzare delle release per niente funzionanti nel PTU perché ci servono più informazioni di debug. A volte invece alcuni contenuti sono disabilitati per focalizzare i test su un’area specifica. Le pistole nerfanti fanno male.
 
[35:27] D: Con le patch del PTU e del Live, le nostre segnalazioni dei bug fanno davvero la differenza?

R: Sì, la squadra non finirà mai di ringraziare la comunità per il duro lavoro e la dedizione nel testare e giocare il gioco. Senza il supporto della comunità, non saremmo riusciti ad avvicinarci affatto all’ammontare di QA di cui abbiamo bisogno per rintracciare e cacciare i bug. Anche se non rispondiamo alle vostre segnalazioni, è molto probabile che abbiamo utilizzato e divulgato quelle informazioni, ma non abbiamo il tempo per rispondere ad ogni singola persona che ci ha aiutato.

 

Trascrizione completa originale disponibile presso ImperialNews.