Quanto sono comuni i test automatizzati nello sviluppo del gioco? [chiuso]

Gli sviluppatori dei giocatori usano per scrivere test di unità e integrazione? Quanto è comune tra gli sviluppatori di puzzle? E tra gli sviluppatori di MMORPG e FPS?

(Non ho alcuna preparazione nello sviluppo del gioco, né sto pensando a come lavorarci - è solo un dubbio che mi è venuto in mente. Quindi, non c'è bisogno di cercare di convincermi a scriverli, anche perché mi piace già scrivere test automatici. )

In generale, i test unitari e di integrazione dei giochi non sono così comuni. Ciò è dovuto principalmente al fatto che l'aspetto di rendering dei giochi è di solito strettamente legato al resto della meccanica di gioco che può essere molto difficile scrivere test di unità che funzionano.

Detto questo, nello sviluppo del gioco possono verificarsi test unitari e, se il codice è impostato per esso, può essere di grande beneficio. Tuttavia, può essere molto più comune scrivere test automatici per i giochi, di solito sotto forma di un programma di intelligenza artificiale che può effettivamente giocare a una velocità superiore rispetto a un normale giocatore. Ci sono alcune storie eccellenti di sviluppatori che fanno proprio questo in questa domanda sui test automatizzati . Questo tipo di test automatizzato è potenzialmente migliore, poiché i test unitari potrebbero non rilevare un bug nel motore di rendering, ma è più probabile che un test automatizzato esponga un tale problema.

Alla fine, però, tutto dipende dallo studio. Alcuni studi effettueranno una sorta di test automatizzati, mentre altri potrebbero assumere 20 ragazzi delle scuole superiori durante l'estate per giocare per ore e ore.

Nella mia esperienza, non è molto comune.

Principalmente i test unitari non si verificano perché la maggior parte degli sviluppatori di giochi proviene da un tempo e da una cultura prima che cose del genere fossero molto diffuse, e quindi è difficile argomentare ora che tali metodi sono necessari. Ciò è diventato ancora più vero negli ultimi anni con l'aspettativa che l'utente sia in grado di correggere il proprio software dopo il rilascio.

In parte è perché il linguaggio dominante nel settore dello sviluppo dei giochi è il C ++ e questo rende i test delle unità un po 'più ingombranti rispetto ad altri linguaggi. Esistono framework di unit test ma non sono così facili da usare come sistemi simili in linguaggi più moderni che possono usare la riflessione e trucchi simili per accelerare il rilevamento dei casi di test.

Inoltre, è perché i giochi generalmente non si prestano al test unitario - gran parte della logica dipende da fonti semi-deterministiche (ad es. Hardware grafico, tempi di input, frame rate), gran parte dell'output è difficile da misurare (ad es. grafica sullo schermo, effetti sonori) e alcuni sono quasi privi di significato al di fuori dell'intero contesto di gioco (ad es. AI reattivi complessi, simulazioni fisiche). Ci sono eccezioni - molte, se lavori sodo per rendere il codice in quel modo - ma nel complesso i test sono più costosi nei giochi rispetto alla maggior parte degli altri tipi di software e quindi il rapporto costi / benefici è più dubbio.

Per quanto riguarda i test di integrazione, non ho mai sentito parlare del termine esplicitamente utilizzato nello sviluppo del gioco, ma molti sviluppatori conducono test automatizzati sull'intero sistema, ove possibile. Probabilmente direi che forse 1 sviluppatore professionista su 3 lo fa, poiché non è sempre facile da configurare e perché i vantaggi sono ridotti dal fatto che praticamente tutti gli sviluppatori di medie e grandi dimensioni (o i loro editori) hanno un QA dipartimento che eseguirà manualmente test simili. Il QA è in genere pagato molto meno degli sviluppatori, quindi può essere considerato economico lasciare test a loro, piuttosto che investire del tempo in più su di esso. (Controverso.)

Non vedo come la scrittura di un gioco sia diversa da qualsiasi altro software per quanto riguarda i test. Ogni componente del software, che si tratti di attivare un evento a tempo, inviare comandi a un personaggio in gioco o premere i pulsanti del menu, deve essere testato per la corretta esecuzione.

Verificare se è possibile completare il gioco è una questione diversa e non rientra nei test unitari o di integrazione.

In generale l'automazione dei test dell'interfaccia utente (anche nei programmi regolari) è più difficile dell'automazione regolare. Quindi, anche se puoi scrivere unit test per i tuoi giochi, testare il gioco reale è più difficile. La maggior parte delle aziende utilizza tester umani che eseguono il gioco più volte .

Ad esempio Ecco un articolo che spiega come lo fanno in un piccolo Game Studio (2 sviluppatori). Da quello che ho letto sembra che la loro convalida non sia molto dettagliata (l'automazione avvia il gioco e registra eventuali errori / asserzioni).

Tuttavia, alcune aziende hanno molto successo con la semi-automazione (come Microsoft Test Studios). Cioè, gli sviluppatori o gli SDET creano strumenti che rendono molto più semplice il test del gioco. Ci sono state discussioni su Gamefest in cui discutono di come hanno testato Crackdown, ad esempio o Fable. Ad esempio, usano ancora tester che verificano che ogni oggetto sia dove dovrebbe essere, ma usano uno strumento che cattura un'istantanea di quella posizione in modo che tutto ciò che l'umano fa sia visivamente verificare che sia lì senza dover giocare.

Ecco una buona chiacchierata su che tipo di strumenti costruiscono / usano per testare i giochi. Si chiama "Test Gemme: uscire di fronte alla crescente complessità dei nostri giochi"

Scommetterei che MMO e il codice server multiplayer, tuttavia, sono un po 'più spesso testati.

Per lo meno, i test di regressione automatizzata sono stati comuni. Ho visto questi implementati come controlli di integrità di massa durante l'avvio del server, ad esempio per assicurarsi che un nuovo server "cloud" sia stato configurato correttamente prima che inizi ad accettare i giocatori; una suite di regressione abbastanza buona costruita in 3-4 anni, in quel caso, è stata eseguita in circa 4 secondi, mentre il richiamo di un host virtuale (da un'immagine del sistema operativo vuota) ha richiesto quasi 10 minuti, quindi ne è valsa la pena. Abbiamo eseguito gli stessi test su un "tinderbox" (sistema di generazione continua) nel nostro repository Subversion per verificare la presenza di errori fastidiosi e abbastanza comuni a cui piaceva insinuarsi. In particolare, la funzionalità multi-server aveva la brutta abitudine di provare a creare duplicati di oggetti mentre venivano passati: l'oggetto istanziazione, memorizzazione nella cache, e il codice di passaggio della rete era coperto quasi al 100%; continuavamo a pensare di aver pensato a tutto ciò che poteva essere testato, e poi scoprire un nuovo "bordo" divertente.

In diversi MMO su cui ho lavorato, svilupperemmo anche "client stub" per eseguire i test unitari iniziali e di solito fornivamo comandi "operatore" per eseguire test unitari ad hoc di nuove funzionalità. Questo ci consente di eseguire il codice del server prima che il client fosse pronto a sfruttarlo e di esercitare situazioni "impossibili" (ad es. Teletrasportare un giocatore all'interno di un muro) per garantire che i gestori di recupero errori funzionassero bene. Portare una nuova funzionalità online sul server a volte potrebbe richiedere molti giorni in meno rispetto al supporto client per essa; al contrario, a volte dovremmo creare un metodo server "fittizio" per il client, restituendo dati falsi ma ben formati, se ci anticipassero.

Tuttavia, lo sviluppo di MMO in generale è soggetto a molti più problemi di questo tipo, che potrebbero riflettere l'ambiente. Quando stavo lavorando su sistemi di gioco incorporati, il "testing" era praticamente inaudito per tutto tranne che per un codice widget riutilizzabile (ad es. Editor di testo).

Un altro motivo per cui i test automatici non sono così comuni nello sviluppo di giochi che si può considerare è che per la maggior parte dei giochi ci sono molti volontari di beta testing che impediscono la partecipazione di Game Beta come "vantaggio" quando il gioco viene rilasciato. I test automatizzati sono ovviamente cresciuti dai requisiti di qualità, ma anche dalle restrizioni di budget. Pertanto, poiché nei giochi ci sono molti tester esperti che sono pronti a testare gratuitamente, forse questo è un altro motivo per cui i test automatici non sono così diffusi.

Ho partecipato a una tavola rotonda sulla sperimentazione automatizzata al GDC 2011 . IIRC, c'erano circa 60 persone nella stanza. Ad un certo punto il moderatore ha condotto un sondaggio sulla copertura dei test unitari. C'era una persona che ha richiesto una copertura del codice superiore al 90%. Tutti gli altri ridevano al pensiero di raggiungere una copertura dell'1% . Se quel gruppo è una rappresentazione equa del settore nel suo complesso, direi che i test automatizzati generalmente non accadono molto, se non del tutto.

Le altre risposte qui forniscono buoni motivi per cui. Ho solo pensato che sarebbe stato utile avere un account di prima mano.