Nuova puntata di Bug Smashers! Questa volta Mark è alle prese con un bug relativo alla transizione delle animazioni di entrata ed uscita dalle navi, un problema che è stato introdotto in seguito ad un’approfondita revisione del codice di gioco.


Mark affronta il bug più buggato che si sia mai buggato e ne esce… Senza bug?

 

Articolo originale disponibile presso le Roberts Space Industries.


Versione Breve

Mark ha fatto in modo che non usciate dalla nave quando cercate di entrarvi, e parla di cose come thread e simili.

Versione Media

Il bug di oggi riguardava la transizione interna dei veicoli. Quando entrate ed uscite da uno di questi, le animazioni dovrebbero venire riprodotte soltanto quando premete il pulsante USA. Ma qualora doveste cadere fuori dalla porta, o dalla nave, queste animazioni non dovrebbero venire riprodotte, ma c’era un bug che è stato introdotto durante la rifattorizzazione completa di un qualche componente, qualcosa avente a che fare con C++. Ogni tanto, quando si effettuano cambiamenti cosi grossi, si verificano problemi del genere, in quanto è sufficiente fare un singolo errore per cambiare parecchie cose tutte in una volta. Ma sono semplici da correggere, succede di continuo, ed è semplicemente necessario sistemare la parte interessata: sono uno degli aspetti che voi ragazzi avete modo di vedere, ma a cui non assisterete mai di persona.

Versione Lunga

Salve a tutti, e bentornati a Bug Smashers! Siamo alla terza puntata, per cui prepariamoci a spaccare qualche altro bug!

*Intro di Bug Smashers*

Salve a tutti, siamo di nuovo nel mio stravagante livello di prova e stiamo per dare un’occhiata ad un bug degli interni che è stato riscontrato in un paio delle nostre navi. Per adesso analizzeremo soltanto il caso dell’Aurora. Se vedete questo piccolo box arancione, quello rappresenta l’interno del nostro veicolo. Attualmente gli interni sono definiti come una specie di box di confine, ma stiamo lavorando su alcune tecnologie che ci permetteranno di adattare la forma reale degli interni a quella della nave. E gli interni sostanzialmente non sono altro che la nostra entità locale, la nostra griglia fisica. Per cui quando vi entrate, e la vostra nave si sposta, voi vi spostate con essa, o se la gravità è invertita o attiva, la vostra posizione all’interno della nave sarà definita su misura in funzione di queste variabili. Dunque, questo è il codice relativo ai nostri interni. Ma, per adesso, si tratta di un semplice box di confine.

Allora, se volessi entrare nella nave, è… Sta riproducendo l’animazione di uscita. Non è una buona cosa. Decisamente no. Dovrebbe riprodurre quella di entrata, non l’animazione di uscita, per cui cosa sta accadendo, e perché?

Qui abbiamo la nostra piccola sezione del codice che gestisce quello che avviene quando la porta viene aperta o chiusa, e questa è la porta in questione. Per cui quando premo F, la porta si apre, e successivamente dovrebbe riprodurre l’animazione di entrata, ma se mi muovo o guardo in giro, l’animazione dovrebbe venire annullata ed io non dovrei uscire o entrare nell’astronave. Ma quello che succede se premo F e sposto un poco il mio mouse è, invece, che il sistema dice al passeggero di uscire, e questo accade perché mi sto muovendo mentre sto cercando di entrare, mentre dovrebbe causare l’annullamento dell’animazione: equivale a dire al sistema che non voglio davvero entrare nella nave, ma che voglio soltanto aprire la porta, ma quest’ultimo richiama comunque la funzione preposta a ripulire l’albero delle azioni, in quanto sfortunatamente le transizioni sono sempre permesse di default, il che è un bel problema. La ragione di tutto questo è… Prendo e copio tutto, andiamo a cercare la sezione del codice relativa ai nostri interni nella build di rilascio, perché questa è una build di rilascio. Questo è il codice che avete adesso e con cui state giocando attualmente.

Se guardate qui, vi accorgerete che la transizione è attiva soltanto se viene impostato questo utilizzo remoto, ma qui il valore è sempre impostato come vero, e ciò è dovuto ad una completa rifattorizzazione dei sedili dei veicoli che abbiamo effettuato da poco, e la porzione di codice relativa a questo utilizzo remoto è stata in realtà eliminata. L’utilizzo remoto faceva parte del codice ereditato nel sistema, suppongo che risalga a Crysis 2, di cui in passato facevano uso, ma è una funzione che non abbiamo mai utilizzato nel nostro codice, ad eccezione di questa piccola sezione.

Questa funzione è stata utilizzata per lo più come una sorta di hack per determinare se la transizione dovesse essere riprodotta o meno. Per cui, dal momento che l’animazione è stata rimossa dal codice, quando alla fine il sistema arriva qui, trova il valore impostato su vero, perché qualcuno ha dato per scontato che le transizioni sarebbero sempre dovute essere attive, che invece è una cosa che non vogliamo.

Dunque, stiamo per aggiungere una piccola riserva a questo passeggero, così che potremo determinare altrove se vogliamo che questa transizione sia permessa o meno. Andiamo ora a cercare altri punti, in maniera tale che sia possibile stabilire, quando stiamo per entrare o uscire, e questi sono gli unici casi in cui si verifica questa transizione, se vogliamo che l’animazione venga riprodotta o meno.

Diamo una ricompilata al codice… Oh, amo i ricodificatori.

Adesso, quello che dovremmo vedere con questa build è che, se premo F e mi sposto, il sistema dovrebbe utilizzare il codice di pulizia per assicurarsi che io non mi trovi all’interno della nave, e dunque non dovrebbe accadere nulla. Dovrei potermi muovere e non dovrebbe venire riprodotta alcuna animazione di uscita. Se invece premo F e non tocco nulla, dovrebbe seguire la procedura che mi porterà all’interno della nave. Quindi premiamo F, ed il personaggio si muove, vacilla un po’, e wooo, non mi porta dentro.

Ho compilato il codice di pulizia nella maniera corretta, per cui proviamoci di nuovo, weee.

Adesso, se non tocco nulla, dovrebbe portarmi dentro. Ed ecco che entra. Dunque, mi porta correttamente all’interno della nave, e posso uscirne qualora lo desideri.

Yaai, porte magiche. Bene, questo sistema quel cattivone. E’ divertente, questo bug causava dei problemi con, credo, la Cutlass. Sul fianco c’è una scala, e se ci salivate sopra, entravate all’interno della nave, forzandovi così a riprodurre l’animazione di entrata, perché la transizione agli interni era sempre permessa. Per cui potevate entrare o uscire dalla nave, e la transizione avrebbe forzato l’animazione anche quando non volevate riprodurla. Vogliamo che queste transizioni si verifichino soltanto quando premete il pulsante F.

Ed ecco fatto. Tutto funziona come dovrebbe, e stiamo lentamente sistemando le cose per il prossimo rilascio. Saluti.

Extra

La scorsa settimana vi ho chiesto di mandarmi alcune domande, ed ho intenzione di sceglierne qualcuna, quelle a cui è possibile dare una risposta semplice e veloce, e soddisfare la vostra curiosità o i vostri dubbi.

Dunque, abbiamo un paio di domande di Digital Pimp, bel nome. “Quale metodo di sviluppo utilizzate?” Allora, principalmente utilizziamo Agile & Scrum. Sfruttiamo Scrum di tanto in tanto: ci riuniamo in un piccolo gruppo e parliamo di quello che stiamo attualmente realizzando e di quello che abbiamo in programma per il futuro. Agile sostanzialmente è un metodo di sviluppo continuo. Usiamo Jira, parliamo con le persone su Skype, teniamo dei mini-incontri e così via. Una serie di piccoli scambi su questa falsa riga. O, quando abbiamo dei dubbi, andiamo alla scrivania di qualcun altro e gli urliamo contro.

La prossima domanda è di Digital: “Quale software utilizzate per gestire il processo di sviluppo?” I due sistemi principali, beh tre in realtà, sono le email, skype e Jira.

“Che sistema di gestione del codice sorgente utilizzate?” Perforce. E’ un software davvero fenomenale.

“Il tuo team utilizza un approccio di integrazione continua o uno di sviluppo continuo?” Attualmente utilizziamo il metodo dell’integrazione continua, cioè aggiungiamo in continuazione nuova roba a Perforce. Ogni giorno aggiungiamo qualcosa, e credo che ci stiamo spostando verso l’approccio di sviluppo continuo, con il quale potremo fondere insieme le varie build secondarie che abbiamo in una di prova, per poi unire queste ultime per ottenere la build vera e propria, ed in questo modo sarà possibile sistemare qualsiasi cosa smetta di funzionare nella build di prova prima che arrivi alla build vera e propria. Non siamo ancora a questo punto, ma ci stiamo preparando per cambiare metodo di lavoro.

Bene, passiamo alla prossima domanda, posta da Holovision. “Alla CIG ci sono altri SpaccaBug, oppure ci sono soltanto apprendisti padawan Spaccabug? Gli allevatori di bug che non hanno raggiunto il vero livello master zen. Avete una lista delle persone che hanno introdotto i bug che risolvete più di frequente, così da mandarli a comprarvi il pranzo quando serve?”

Dunque, per rispondere alla prima domanda: no, non sono l’unico SpaccaBug, solo quello che compare in telecamera. Abbiamo dei SpaccaBug in ogni studio, ed infatti in questi studi abbiamo Oka, che risolve i bug grafici, Brandon, che si preoccupa di quelli relativi all’HUD ed al gameplay, Chad, incaricato di risolvere i bug della AI, e Paul, il nostro capo, che spacca di tutto e di più.

Inoltre, negli studi degli UK abbiamo delle persone che spaccano i bug sia di SQ42 che dell’AC, per non parlare poi degli studi in Germania, che stanno lavorando da dietro le quinte su alcuni bug relativi al motore di gioco. Quindi in ogni studio abbiamo delle persone che si occupano dei bug.

Ottimo, dunque, ultima domanda, da Onetooth. “Magari potete spiegarci i concetti di base del motore di gioco e del multi-threading, e magari approfondire il discorso della gestione degli eventi?”

Allora, fornirò una risposta veloce ad entrambe le domande. Un motore di gioco è, sostanzialmente, un gigantesco pacchetto software che contiene tutto quello di cui si ha bisogno per creare il proprio gioco. Contiene elementi da renderizzare, altri per il multiplayer, software per lo sviluppo di un gioco che riceva input dalla tastiera, cosa del genere. E’ lo scheletro di base di cui si necessita per la creazione del gioco. Per quanto riguarda il multi-threading, pensate a qualcosa del genere: se dovessi scrivere un saggio, sarebbe un’attività in single-thread, mentre se dovessi scriverlo su un pezzo di carta, ma dovessi scrivere contemporaneamente con entrambe le mani su due fogli differenti, allora l’attività sarebbe in multi-thread. Perché svolgerei due compiti diversi nello stesso momento. Ed il funzionamento preciso è molto più dettagliato e complicato, per cui ti invito a googlarlo.

L’ultima domanda riguarda invece la gestione degli eventi. Allora: mettiamo che io sia morto, e che quindi notifichi tutti della mia dipartita. Si potrebbe anche compiere un passo ulteriore e registrare gli eventi in maniera tale che, se morissi, se venissi colpito, vorrei poter seguire questi eventi, per cui in seguito alla morte di un giocatore, questo invierebbe l’informazione a tutti coloro che stanno seguendo i suoi eventi, avvisandoli della sua morte, e sfruttando questo sistema sarebbe possibile realizzare delle cose astute, come ad esempio compiere una precisa azione quando esplode un missile, o qualcuno preme un certo bottone. Fondamentalmente, questa è la maniera in cui funziona la gestione degli eventi. E’ di gran lunga migliore che avere una funzione di aggiornamento che controlli continuamente quello che sta accadendo, in quanto così si può semplicemente impostare un’azione in risposta a qualche altro avvenimento.

Bene, questo è tutto per la nostra piccola sezione delle domande di oggi. Se ne avete altre, proverò a rispondere loro la prossima settimana. E fino ad allora, SPACCATE.

Non ho ottenuto nulla.

Traduzione a cura di Darnos.
Trascrizione originale disponibile presso ImperialNews.