Sono presenti dei bug della fisica, per cui gli oggetti hanno dei comportamenti strani. Mark li risolve. Bug Distrutti.
Bene, allora, questo bug era divertente. Stiamo apportando una serie di grossi cambiamenti al motore di gioco e purtroppo quando iniziamo a mettere insieme le varie build per il rilascio successivo, scopriamo sempre delle parti non funzionanti che dobbiamo ripulire. L’intero problema fisico si verifica quando stacchiamo qualcosa da un punto di aggancio ed è dovuto ad un’enorme revisione del sistema di trasporto degli oggetti. Dal momento che avevamo bisogno di un fix per il prossimo rilascio, abbiamo implementato questo sistema proprio per ribadire che avevamo bisogno che fosse funzionante; stiamo lavorando alla correzione vera e propria, ma ovviamente richiederà tempo. E dopo aver risolto questo bug, passiamo a rispondere ad alcune delle vostre domande.
Ardent Hammer – Bel video, continua così. Mi sono sempre chiesto, quando si lavora su progetti grandi come SC, come fate a tenere traccia dell’intero codice sorgente?
Allora, in realtà si tratta di una questione davvero impegnativa con cui dobbiamo vedercela giorno dopo giorno. Abbiamo un paio di approcci. In Visual Studio sono implementati tanti strumenti, come ad esempio Visual Assist, che ci permettono di ricercare nel codice sorgente ciò di cui abbiamo veramente bisogno. E questo è il primo. Il secondo consiste nella nostra struttura di organizzazione. Il codice riguardante le funzioni di base del motore di gioco vengono raccolte sotto la dicitura ‘Funzioni basi del motore’, ogni aspetto correlato alle animazioni va nella cartella delle animazioni, e lo stesso vale per gli elementi collegati al rendering, al gameplay e così via: ognuno ha una propria sezione. Questo ci aiuta a restringere il campo. E poi, ogni volta che vogliamo inviare del materiale, dobbiamo effettuare una revisione obbligatoria del codice, ed inoltre c’è l’aspetto della responsabilità, nel senso che alcune persone si interessano di porzioni precise del codice di gioco, per cui se si hanno domande a riguardo, si può andare a chiedere direttamente a loro. Abbiamo anche una wiki. Abbiamo ogni genere di informazioni possano servire per trovare qualsiasi cosa o sistemare i problemi, persino le email di skype. E’ un progetto davvero enorme, ed utilizziamo ogni sorta di piccolo gadget divertente.
Frazziboy – Essenzialmente, vuole avere delle informazioni su un aspetto su cui ci sarebbe da parlare un po’; riassumendo, vuole sapere perché si preferisca usare la gestione degli eventi piuttosto che controllare se il giocatore sia morto oppure… Blah, fatemi riniziare da capo. Allora, ho ricevuto un’altra domanda da Frazziboy, è una argomento su cui ci sarebbe da discutere un po’, per cui cercherò di restringere la questione. Essenzialmente, vuole sapere perché si preferisca usare la gestione degli eventi piuttosto che controllare continuamente un certo valore.
Beh, controllare in continuazione un certo valore può risultare troppo costoso in termini di prestazioni. Inoltre, potresti aver bisogno di memorizzare o avere un puntatore del valore dell’oggetto che si vuole controllare. E’… Potrebbe valerne la pena o no, dipende dall’elemento su cui si sta lavorando. Il vantaggio implicito nell’avere un sistema di gestione degli eventi è costituito dal fatto che, quando si verifica un evento, lo si registra immediatamente ed così è possibile gestire quello stato, piuttosto che dover verificare in continuazione se sia cambiato. Conservare il vecchio stato e quello nuovo può essere un po’ caotico, ma dipende sempre da quello che si vuole fare. A volte la gestione degli eventi potrebbe essere migliore di un semplice controllo della presenza di eventuali aggiornamenti, o viceversa. Dipende dall’approccio scelto per risolvere il problema.
La gestione degli eventi è ottima per un sistema grande come il nostro perché, per esempio, quando un radar aggiorna una firma, posso inviare un aggiornamento a tutti i sistemi piuttosto che impostarli perché controllino e controllino e controllino e controllino il valore di questo stato, cosa che potrebbe inficiare sul tempo di frame perché starebbero continuamente effettuando un aggiornamento delle proprie funzioni, piuttosto che eseguire un semplice push & pull.
Spero che abbiate ricevuto delle brevi risposte divertenti, e qualora abbiate altre domande da farmi, risponderò loro la prossima volta.
Saluti!
…
Non avevo alcuna idea di come chiudere.
Salve a tutti, sono l’uomo che sussurra ai bug, Mark Abent, e sono qui per mostrarvi Bugsmashers 2, il mondo perduto.
Salve a tutti, oggi abbiamo un piccolo bug divertente. Inizierò con una piccola divertente lista delle modifiche apportate, che ci servirà come introduzione al bug di oggi. Allora, un po’ di tempo fa, più precisamente la settimana scorsa, abbiamo riscontrato un problema con i nostri oggetti, cui non veniva assegnata un’entità fisica nel momento in cui venivano staccati dai nostri punti di trasporto. Un oggetto è, sostanzialmente, qualsiasi cosa potrete attaccare alla nave o ad una rastrelliera, come un rack missilistico agganciato ad una nave. In questa build abbiamo apportato parecchi cambiamenti sostanziali al codice che, fondamentalmente, hanno distrutto tutta la parte relativa alla resa fisica degli oggetti, e questo è stato semplicemente un veloce primo tentativo del buon vecchio Paul di sistemare la questione. Per buona parte ha funzionato, eccetto per il fatto che ha avuto delle brutte conseguenze sul Multiplayer. Il problema è dovuto al fatto che abbiamo una sezione del codice che si occupa del sistema degli attacchi, ed un proxy che invece lavora sulle entità fisiche, ed entrambe gestiscono le entità fisiche dei nostri missili o dei nostri oggetti. Ma mentre in modalità giocatore singolo è piuttosto semplice stabilire chi abbia il possesso di qualcosa, in quella multi giocatore, a causa del fatto che ci sono continui pacchetti in uscita e problemi di priorità, la componente fisica potrebbe essere assegnata al sistema di aggancio invece che a quello di trasporto, o al proxy, e quando l’oggetto si aspetta che l’assegnazione di questo componente sia da tutt’altra parte, ciò causerà problemi. Stabilire una scala di prioprità tra tutto questo è una questione molto delicata.
Dunque, quello che ha fatto il buon vecchio Paul… Guardiamo le differenze, saltiamo tutta questa parte, e ci siamo. Ogni volta che qualcosa viene collegato ad un punto di trasporto, viene disabilitata la fisica di quell’oggetto, che poi viene riabilitata quando l’oggetto menzionato lascia il punto di trasporto. In tutto questo, il problema consiste nel fatto che potrebbe verificarsi una serializzazione, l’oggetto potrebbe serializzare e dire al sistema di assegnargli un’entità fisica mentre questo si trova ancora attaccato ad un punto di trasporto, o viceversa. E ciò causerebbe delle divertenti collisioni fisiche.
Quello che ho fatto io… Se disfo la mia piccola sezione del codice… Doo doo doo… Allora, io ho introdotto una cosa definita ‘fisica desiderata’. Il sistema si comporta ancora allo stesso modo: richiede di sincronizzare un certo oggetto e di assegnargli un’entità fisica, ma a questo punto introduciamo un ritardo sul frame in maniera tale da non avere questi problemi, che si verificano quando un oggetto viene attaccato o scollegato da un punto di trasporto nello stesso frame, serializzando tutti questi strani stati fisici che fanno casino, per cui adesso aspetterà il prossimo frame e vedremo se si riverificherà lo stesso problema. Questo sistema funziona praticamente ovunque, eccetto che in multiplayer. E la ragione è che… Compiliamo questo codice, vi posso dare una dimostrazione live.
Allora, ho tolto questo punto perché ho dimenticato che si tratta di uno stato valido, ma è proprio da qui che nasce il problema. Lo impostiamo in ritardo sul frame, ma il problema è che il proxy fisico ancora non esiste, per cui quando cerca di serializzare questa informazione, non lo può fare perché il puntatore non ha alcun valore, quindi blocca la procedura e ciò causa la disconnessione del giocatore. Non possiamo permettere che succeda una cosa del genere, per cui dobbiamo assicurarci che nel nostro proxy fisico ci sia, fortunatamente, un altro parametro che ci permetterà di creare il proxy stesso. Lo possiamo fare soltanto perché abbiamo un ritardo sul frame. In precedenza, ogniqualvolta serializzavamo questa informazione, il sistema avrebbe immediatamente creato l’entità fisica. Ma adesso, dal momento che c’è un piccolo ritardo, dobbiamo creare l’entità fisica in maniera tale da poter effettuare la serializzazione.
Ma è possibile che la fisica non sia stata ancora creata, ed è proprio questo lo scopo del nuovo parametro, che riguarda anche il proxy: sostanzialmente, inserirà questa informazione nel sistema fino a quando non sarà pronto per l’assegnazione dell’entità fisica. Ora proviamoci di nuovo.
Mentre carico il nuovo codice, è importante notare che dal momento che sia il gestore degli agganci che il proxy dell’entità fisica gestiscono la fisica, fare in modo che ciascuno di essi non causi qualche casino con l’altro è sempre un lavoro strano. Stiamo sviluppando un componente che ci assicurerà che sia la fisica che la serializzazione degli oggetti vengano gestite soltanto dal proxy fisico e non dal gestore degli agganci, ma si tratta di una modifica enorme ancora in corso che prima o poi termineremo, per cui nel mentre dovremo ricorrere a queste piccole birbonate per essere sicuri di avere un gameplay come si deve, perché vogliamo che i nostri missili siano effettivamente in grado di muoversi nel multiplayer, così che nel frattempo potremo implementare quell’altra grossa modifica.
Dunque, come potete vedere sono stato in grado di entrare in partita, e se avessi un altro personaggio, potrei sparargli dei missili. Voliamo un po’, weee.
Questo è tutto. Divertenti angosce fisiche.
