L'industria dei giochi utilizza test automatici per parti visive di giochi / rendering? Come?

Alcune parti di un gioco sono facili da testare in modo automatizzato (logica, matematica, gestione degli input); ma ce n'è anche molto puramente visivo e non facilmente testabile.

Sarei sorpreso se l'industria dei giochi lasciasse tutto questo ai test manuali; ci sono abbastanza soldi che immagino che sia stato fatto uno sforzo per poter testare la regressione almeno su alcuni aspetti visivi dei giochi.

È vero? In tal caso, quali sono i modi possibili per testare il rendering dei giochi? Catturare l'output e confrontare le immagini (può essere affidabile?)? Intercettare i dati dalla scheda grafica a un livello basso? Catturare informazioni sui vertici (ecc.) Sulla strada per la scheda grafica? Sembra che ci siano molte possibilità; ma non riesco a trovare alcuna informazione al riguardo :(

Nota: questa domanda è stata contrassegnata come una copia di questa , ma non sto chiedendo informazioni su tecnologia / framework / strumenti specifici su come farlo, ma più in generale le idee su questa pratica e su cosa faccia l'industria dei giochi (se lo fanno affatto).

unit-testing testing game-development

— Danny Tuppeny
fonte

Direi che probabilmente usano solo una libreria grafica ben collaudata (di terze parti o sviluppata internamente). Quando arrivano a progettare un livello di gioco, non controllano che ogni oggetto sia esattamente alle coordinate X, Y, Z o se la prospettiva è giusta, ma cose più semplici come garantire che gli oggetti siano lì e non siano bloccati da muri, ecc. E se la libreria grafica è sviluppata internamente, i test sono automatizzati e più basilari.

— SJuan76,

@ SJuan76 Immagino che se stai costruendo su un motore, la domanda si applica alle prove del motore

— Danny Tuppeny,

Questa domanda non è forse un po 'più ampia di quella che è stata contrassegnata come duplicata? L'OP non ha menzionato C ++ o OpenGL. L'industria dei giochi è più grande di così.

— toniedzwiedz,

Probabilmente è più facile dimostrare formalmente che il codice è corretto dato che le API grafiche sono prive di bug piuttosto che testare che l'hardware stia facendo il suo lavoro. Poiché i driver AMD e NVidia sono proprietari, immagino che qualunque protocollo sia coinvolto nella comunicazione con la scheda grafica sia 1) proprietario, 2) soggetto a modifiche e 3) varia da scheda a scheda. Inoltre, anche se i dati inviati alla scheda grafica sono corretti, come fai a sapere che la scheda grafica non ha un difetto hardware?

— Doval,

Ho provato a riaprirlo poiché l'obiettivo dupe era più specificamente sulle strategie di test automatizzati della grafica OpenGL. Questa non è la mia specialità, ma mi fido del feedback di altri che conoscono molto bene l'industria del gioco, quindi voglio dargli un'altra possibilità. Per riferimento alla domanda simile vedi qui: programmers.stackexchange.com/questions/150688/…

— maple_shaft

Qualsiasi azienda lo farà in modi diversi, anche i diversi giochi verranno testati in modo diverso.

Forse la mancanza di informazioni sulla grafica è perché il rendering è in effetti abbastanza "ripetitivo" (non posso pensare una parola migliore, scusate) e in una scena complessa tipica ci saranno abbastanza combinazioni primitive in modo che la maggior parte delle persone di solito riesca a vedere facilmente la maggior parte dei glitch ( ad eccezione degli shader meno utilizzati, ma è possibile utilizzare un livello / demo speciale per lo shader da stress). Ricorda che gli umani sono stati cacciatori per migliaia di anni :) quindi probabilmente siamo stati progettati per vedere problemi tecnici.
Anche la libertà di movimento presente nella maggior parte dei giochi e la randomizzazione di altri elementi in un gioco tipico che lo fa sentire più "realistico" sono di solito un incubo per l'applicazione di test automatizzati puri: in realtà un tester umano troverà più rapidamente e di più errori rispetto a qualsiasi test automatizzato. Puoi codificare una logica per tempi di registrazione, statistiche e posizioni / angoli / altre variabili ogni volta che un tester sta giocando ... quindi anche su test non automatizzati avrai un feedback simile a test automatici. Di solito è utile essere in grado di eseguire una riproduzione di qualsiasi sessione di beta tester registrata (e di solito è una buona funzionalità anche per il gioco finale).
Per quanto riguarda il rendering delle statistiche, ad esempio puoi ottenere: le statistiche del conteggio delle chiamate per ogni shader (man mano che effettuerai le chiamate, è sufficiente mantenere alcuni contatori), il caricamento conta (lo stesso, controllerai quando i buffer della GPU vengono aggiornati), i tempi (non solo i fps, ma anche i giri tra una chiamata) e così via. Se necessario (ma credo che non sia consigliato tranne quando si cerca un errore specifico) è possibile ottenere statistiche dalla scheda grafica stessa (ad esempio è possibile ottenere tassi di riempimento e altri utilizzando le query di occlusione).
Infine, un altro motivo per utilizzare i beta tester è che diverse schede grafiche avranno probabilmente comportamenti diversi ... potrebbe essere necessario disporre di una fattoria di macchine di prova o_O. Gli amati beta tester umani ammorbidiranno tutto quel casino.

Spero che sia d'aiuto!

Disclaimmer: Non sono un betatester, sono uno sviluppatore XDDD.

— user1039663
fonte

Sono pienamente d'accordo con gli esseri umani progettati per vedere schemi, difetti, ... Siamo davvero esseri visivi.

— Trilarion,