Il test del software è diverso quando abbiamo a che fare con lo sviluppo del gioco?


11

Stavo leggendo questo documento sulle differenze tra lo sviluppo del software in generale e lo sviluppo del gioco e gli autori hanno fatto alcuni punti positivi riguardo ai test del software, sottolineando, ad esempio, che

... gli sviluppatori di giochi sono restii a usare i test automatici a causa della rapida obsolescenza di questi test di fronte ai mutevoli desideri creativi dei game designer.

Quindi, questa lettura mi ha fatto pensare, quali altri aspetti del test del software dovremmo considerare diversi o particolari quando abbiamo a che fare con / testare un gioco? Qualcuno ha esperienza con questo o qualcuno ne ha sentito qualcos'altro?


Ti dispiace collegarti al documento? Sarei curioso di leggerlo.
RubberDuck,

1
Ecco il documento: microsoft.com/en-us/research/wp-content/uploads/2016/02/… . Oh, e dai la tua opinione su questo se non ti dispiace. Grazie. :-)
Ronnie Edson l'

9
Temo che la rapida obsolescenza (dei test) di fronte ai mutevoli desideri dei poteri che si verificano anche nello sviluppo non di gioco. Il che suggerisce che forse lo sviluppo del gioco non è così diverso dagli altri sviluppi?
Erik Eidt,

Direi che la più grande differenza tra software aziendale e giochi non è "requisiti di spostamento", che è comune praticamente ovunque, ma l'enfasi sulle prestazioni e il lavoro intenso dell'interfaccia utente che compone un gioco. Nel software aziendale, i dati e i modelli logici tendono a essere separati dalla presentazione, rendendoli candidati facili per i test unitari. I giochi non hanno sempre questo lusso. Questo non vuol dire che la parte dei giochi online sul lato server non può essere testata in modi più tradizionali, allo stesso modo pura logica di gioco, tassi di
generazione dei

1
Diverso è una chiesa molto ampia. E piuttosto dipende da cosa lo stai confrontando.
Robbie Dee,

Risposte:


10

I giochi moderni sono in realtà un sacco di contenuti di arte creativa sviluppati utilizzando un motore di gioco interno o proprietario. Il motore stesso è unitamente testabile per la maggior parte (rendering, geometria, fisica, moduli AI ecc.). Allo stesso modo, è possibile allegare semplici test a singole parti di contenuto sviluppato. Ciò significa che i test su unità e white box sono effettivamente fattibili e di successo.

Per quanto riguarda il "prodotto nel suo insieme", un gioco è una simulazione. Potrebbe avere una maggiore complessità generativa rispetto a un semplice programma aziendale. Pensa a mondi infiniti, unici e generati procedurali rispetto a un pianificatore di risorse aziendali con comportamenti numerabili ben pianificati. In poche parole, il numero di possibili modi unici di fare qualcosa nel contesto dei giochi, può essere matematicamente, molto grande. In realtà è considerato un punto di forza per i giochi.

Aggiungete a ciò il fatto che l'uscita finale è puramente audiovisiva e non esiste uno standard deterministico di assoluta correttezza di tale uscita. I chip GPU non hanno davvero bisogno di eseguire calcoli precisi, solo molti calcoli, anche se alcuni non sono precisi.

E infine, l'obiettivo principale è l' intrattenimento . I giocatori sono a posto con problemi tecnici se esegue oltre 60 FPS, sembra fantastico e ha infinite ore di contenuti divertenti.

Questo mette semplicemente le idee di test automatizzati tradizionali in black box nella regione "non così tangibile e degna" quando applicate ai giochi.

Tuttavia, ci sono stati recenti tentativi di addestrare le NN a giocare , che è effettivamente una forma di test esplorativo e di autoapprendimento delle scimmie.


2
Che cos'è il "programma aziendale medio"?
whatsisname

1
Sì ! Non è tanto il numero di interazioni che è diverso (prendi un ERP principale con diverse migliaia di tipi di transazioni correlate e un panorama di processo che può essere riconfigurato all'infinito). È più che un software aziendale dovrebbe fornire un comportamento ripetibile che può essere facilmente verificato in un test di integrazione. I giochi devono intrattenere e tutto ciò che è ripetibile è noioso. Quindi è difficile per lo strumento di test misurare il grado di intrattenimento o la coerenza e il realismo delle scene che l'utente vede. Potrebbe essere con un po 'di IA tra 30 anni ....?
Christophe,

@Christophe dipende dalla portata del ripetibile - ad esempio "quando il personaggio viene colpito, dovrebbe perdere 5 punti salute" è perfettamente ripetibile e perfettamente testabile. Ciò che conta è che la logica di gioco ripetibile e testabile sia ben astratta dalle parti con stati meno tangibili da asserire.
Ant P,

2

Sono passati molti anni da quando ho fatto il gioco, ma oltre alla bella risposta, ci sono alcune cose che voglio aggiungere e dettagli.

La prima cosa già menzionata è che l'output è solo visivo e uditivo rispetto a vincoli "FPS-critical" e budget computazionali / di memoria. Le idee di correttezza diventano sfocate quando le domande sono più simili: "Ha un bell'aspetto? Funziona senza intoppi? Sta bene?" mentre gli sviluppatori stanno modificando, sintonizzando e approssimando, mentre le collaborazioni tra progettisti / sviluppatori portano a cose che sembrano e sembrano leggermente diverse ad ogni iterazione rapida.

Un altro è che i tester possono essere fantastici! Non ho mai trovato un gruppo più dedicato di tester in nessun altro dominio, dal momento che voglionoper testare il software. Si stanno divertendo. Sono dipendenti e dormono accanto al computer mentre esplorano ogni angolo del tuo gioco. Diventa abbastanza facile scoprire anche i difetti più oscuri quando le persone sono effettivamente intrattenute test approfonditi ogni angolo del software mentre sono praticamente dipendenti da esso. Nella mia attuale industria i tester sono un po 'più difficili da lavorare poiché molti di loro sono professionisti che legano il proprio sostentamento al software, e quindi fanno affidamento su una manciata di funzionalità per svolgere il proprio lavoro e non sono necessariamente interessati a esaurire ogni angolo e tutte le volte. Naturalmente quando non possiamo fare affidamento su tester umani, abbiamo bisogno di ulteriori test automatizzati.

Ancora un altro è che la base di codice per un gioco in genere non viene mantenuta, modificata ed estesa per anni e anni. Non è come se gli sviluppatori di Super Mario che lo svilupparono originariamente nell'assemblaggio 6502 dovessero mantenere qualcosa di simile a quel codice originale molto tempo dopo la spedizione del gioco. Doom 3 probabilmente usa zero righe di codice (o chiudi) da Doom 1. Se c'è un franchising continuo, i giochi più recenti sono più simili ai "sequel" che agli "upgrade". La maggior parte dei giochi viene rilasciata e forse rilasciano alcune patch, DLC e quindi il codice è terminato. Questo è un enorme contrasto con il mio settore VFX in cui ho lavorato per mantenere il codice risalente ai giorni di Amiga che era stato portato e mantenuto per decenni. I giochi in genere non

Uno dei motivi di questa natura di breve durata delle basi di codice dei giochi è che sono così legati all'hardware. Se combinati con la loro natura all'avanguardia e requisiti critici FPS, spesso non possono essere sviluppati in un modo che astragga i dettagli hardware, nemmeno vicino. Sono spesso scritti in modo molto specifico per la generazione di hardware di destinazione, e di solito non passa molto tempo prima che PS3 venga sostituita da una PS4 che poi diventa obsoleta e sostituita da una PS5, e così via, e tutto molto rapidamente. Le funzionalità hardware svolgono un ruolo così importante nella progettazione e nello sviluppo del gioco che in genere non vale la pena provare a mantenere molto dello stesso codice scritto per PSX come per PS4, ad esempio la maggior parte dei franchise di giochi che durano per generazioni continuano a scrivere i loro motori di nuova generazione in gran parte da zero per l'hardware più recente.

Con una base di codice di breve durata arriva un tempo di manutenzione limitato (ovvero un tempo limitato in cui il codice deve essere modificato). Con un tempo limitato per la modifica del codice che non si estende su anni con l'ambito del motore sempre più grande ad ogni aggiornamento, e combinato con il fatto che i giochi non sono in alcun modo vicini a mission-critical, non esiste un tale assolutamente necessità critica di applicare l'unità più esaustiva e i test di integrazione. Non vi è alcun vantaggio nel garantire l'integrità delle modifiche future se non verranno apportate modifiche future e l'aspetto di test unitario e refactoring delle basi di codice legacy è naturalmente irrilevante se non c'è "eredità" in primo luogo.

Un altro piccolo che non è sempre rilevante è che un gioco potrebbe scegliere come target solo una gamma molto ristretta di hardware senza porte desktop. In questi casi viene eliminata un'enorme fonte di anomalie imprevedibili in questi contesti, ovvero gli utenti che eseguono il software con hardware e driver radicalmente diversi.

Detto questo, i test di integrazione al livello più alto / più grossolano tendono ad essere più immediatamente utili. Ad esempio, molti giochi potrebbero utilizzare un modo per registrare come lo stato del gioco cambia nel tempo per i "replay". Tali funzionalità di replay possono garantire che il gioco sia deterministico e possa essere utilizzato anche come forma di strumento di test per riprodurre una sessione di gioco registrata in precedenza da qualcun altro.

Ho anche incontrato gamedev che lavoravano in piccoli studi che facevano cose come scrivere robot per il loro gioco e avevano i robot a giocare alla massima velocità e ho eseguito quella simulazione, originariamente incontrando un oscuro incidente dopo un giorno o due, quindi risolto, quindi ha ripetuto la simulazione e si è ripetuto fino a quando non si sono verificati altri arresti anomali anche dopo averlo eseguito per settimane intere. Quindi ci sono tipi interessanti di approcci pragmatici come quello che ho visto da Gamingevs per testare il loro software, ma spesso in modi che assomigliano al livello più grossolano di test di integrazione e simulazione di cose molto vicine a come i giocatori interagiscono effettivamente con il gioco.

Finalmente questi grandi motori di gioco AAA stanno iniziando ad assomigliare a un tipo completamente diverso di bestia: più longevo, astraggendo un po 'meglio l'hardware un po' meglio, con basi di codice più grandi e intervalli di manutenzione più lunghi mentre i loro editor di livello stanno iniziando ad assomigliare ad ambienti di sviluppo completi. Immagino che quei grandi motori richiederebbero probabilmente una procedura di test più approfondita, specialmente se il tempo in cui il loro codice viene mantenuto si espande considerevolmente. Molti studi di gioco non scrivono enormi motori di gioco AAA: li licenziano o sviluppano un piccolo motore proprietario che ha un ambito notevolmente più piccolo e non sarà mantenuto per anni.


1
Motori di ricerca. Sì, è un approccio collaudato.
SD
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.