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.