Test automatici di giochi [chiuso]

Esistono metodi di test automatizzati dei giochi?

Sono apprezzate esperienze specifiche, con informazioni pertinenti sul progetto come piattaforma e tipo di gioco se ciò aiuta a chiarire.

Gioco indipendente per una persona. Era un gioco di carri armati multiplayer con terreno distruttibile e il terreno distruttibile e il codice di collisione si sono rivelati in qualche modo traballanti.

Ho finito per truccare alcune AI stupide di base (per "stupido", intendo "assolutamente idiota" - avrebbero scelto casualmente "guidare verso un carro armato nemico", "allontanarsi da un carro armato nemico" e "guidare in una direzione casuale ", mentre spari casualmente l'arma principale) e gioca al massimo framerate mentre registri i tasti premuti. Ho ottenuto circa 10-15 volte in tempo reale. Il codice è stato ampiamente affermato, quindi se qualcosa andava storto, scaricava su disco l'intero registro della pressione dei tasti insieme a un rapporto di errore e al seme casuale iniziale. Potrei quindi andare a riprodurre nuovamente il registro dei tasti per duplicare esattamente lo stato o semplicemente eseguire il debug dalla segnalazione errori.

L'ho lasciato in esecuzione costantemente per letteralmente mesi. All'inizio raramente sarebbe durata un'ora senza schiantarsi: dovevo sedermi lì e fare da babysitter per una settimana, uccidendo diversi oscuri bug al giorno. Alla fine arrivò al punto in cui era in esecuzione per una settimana tra i guasti, il che si traduce in circa 1500 ore di gioco per incidente.

È stato prezioso e lo consiglio vivamente.

Per un MMO su cui ho lavorato (sviluppatori 100ish, focalizzati sul PC), abbiamo cercato di aggiungere una grande varietà di test automatizzati con successo variabile. Ecco cosa ha funzionato:

• I test di base durante il nostro processo di creazione automatizzata sono stati una grande vittoria. Ciò includeva attività come la creazione di un personaggio, il trasferimento di mappe, l'esecuzione di alcuni test dell'interfaccia utente con script e la ricerca del comportamento previsto. Ciò ha catturato un numero enorme di bug prima che arrivassero effettivamente al resto dell'azienda.
• Sul lato dell'infrastruttura del server, abbiamo sviluppato una serie di diversi test automatici che simulavano le transazioni tipiche dei server MMO. Potremmo quindi riprodurli in una varietà di circostanze per confrontare le prestazioni o garantire la sicurezza. Nel tempo questi test sono diventati sempre più precisi fino a quando non si sono trasformati in una riproduzione di dati registrati dal vivo
• Abbiamo scritto un "giocatore falso" che vagava casualmente in tutto il mondo, saltava, uccideva cose e diceva cose casuali in chat. Ciò ha riscontrato un numero enorme di problemi di fisica e infrastruttura.

Cosa non ha funzionato:

• Abbiamo provato ad aggiungere al costruttore automatico alcuni test automatici orientati al combattimento molto specifici, ma in pratica questo non ha mai funzionato. Funzionerebbe per circa 3 giorni dopo essere stato implementato, fino a quando un designer o un artista non cambiasse qualcosa e il test fallisse, lanciando gli allarmi falliti della costruzione. Il 90% delle volte non è stato un vero problema. Questi test erano troppo fragili e in realtà testare un gameplay specifico su una mappa specifica con poteri specifici può essere irraggiungibile
• Abbiamo provato a implementare un test delle prestazioni automatizzato che avrebbe confrontato le prestazioni del cliente (FPS medio, ecc.) Con le prestazioni registrate di una settimana fa. Questo è stato anche abbastanza fragile poiché le demo che usavamo per questo tendevano a marcire abbastanza spesso, ed era difficile accertare se un rallentamento fosse causato da una perdita effettiva delle prestazioni o da qualche effetto collaterale del processo di test.

Lavorare su un gioco di strategia 4x con combattimento in 3D (pensa che Homeworld incontra Masters Of Orion) che sfortunatamente non ha mai visto la luce del giorno mentre la compagnia finiva i finanziamenti ..

Mi sono sempre assicurato che tu potessi giocare senza giocatori umani in modo da poter lasciare il gioco in esecuzione durante la notte.

Potremmo disattivare il combattimento 3d (semplificato a un risultato casuale) e abbiamo lasciato il motore di strategia di intelligenza artificiale giocare da solo. Questo ha riscontrato numerosi bug e problemi. Non solo mostra bug stopper ma bug di strategia in cui le strategie (ad es. AI) verrebbero bloccate e passerebbero migliaia di turni senza fare "la cosa giusta". Questo tipo di bug era difficile da individuare semplicemente "giocando".

Su uno sparatutto in prima persona su cui ho lavorato (Descent 3 - linux / mac / windows, ~ 30 persone nel team nel 1999), la capacità di registrazione / riproduzione demo si è rivelata estremamente utile. Ho fatto un'opzione in cui è possibile riprodurre la demo il più rapidamente possibile con il rendering dei fotogrammi, e questo è diventato un ottimo modo per verificare le prestazioni dopo aver cambiato un sacco di cose.

Esercitava anche molto del codice oltre il sistema di rendering, quindi era un buon controllo di integrità. Dopo aver apportato alcune modifiche, ho potuto semplicemente eseguire la riproduzione demo di 10 minuti di gioco. Molte volte avrebbe catturato un bug in un'area che non avrei mai pensato di controllare.

Avevamo uno sparatutto openworld (x360, PS3, PC) che utilizzava un rapido test sui fumi sul server di compilazione: caricava il gioco, passava attraverso il front-end, correva [l'avatar] in avanti, scaricava uno screenshot ed usciva. Se cctray ha rilevato l'uscita pulita, la build ha avuto esito positivo.

Lo abbiamo eseguito per circa l'ultimo anno del progetto e con una dimensione del team di ~ 100 sviluppatori.

È stato efficace nel catturare i bug dello showtopping, ma è stato facile creare una build che superasse i livelli più affumicati ma non riuscisse nella maggior parte dei livelli "reali", o non funzionasse nel multiplayer o alterasse l'intelligenza artificiale, quindi non era perfetto. Ne è valsa decisamente la pena.

Ho sentito da quando ho lasciato che hanno iniziato a eseguire una vasta gamma di test sui fumatori, trasferiti su più PC. Apparentemente mantenere i test dei fumatori è un problema, e c'è un piccolo team dedicato a mantenere i server di build e il software mantenuti, quindi non posso dire se è stato un successo o no.

La mia esperienza con i test automatizzati durante lo sviluppo di Crysis 2 è disponibile qui: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Sommario:

• I test automatizzati hanno migliorato la stabilità dei risultati finali, aumentando la produttività sia per i creatori di contenuti che per gli ingegneri
• I test automatizzati sono uno strumento efficace per migliorare la qualità del codice e ridurre le possibilità di dover fare straordinari
• L'industria del gioco nel suo insieme è molto reazionaria in generale, i test automatizzati soddisfano diversi argomenti irrazionali contro
• Non chiamarlo test, chiamalo qualcos'altro, quasi qualsiasi altra cosa (Guarda Behavior-Driven-Development)
• Sii flessibile, scrivere buoni test è difficile e richiede competenze che non sono ampiamente disponibili nel settore dei giochi

Lo sviluppo del gioco è in realtà uno di quei casi in cui i test unitari sembrano avere un senso per me, perché le interazioni tra sistemi discreti sono così comuni. La progettazione per contratto è ovviamente parte di questo, e dovrebbe essere pianificata fin dal primo giorno di sviluppo, ma non vedo perché non possa essere implementato in seguito supponendo che esiste il mezzo per farlo.

La parte difficile è, ovviamente, il test di integrazione. Molti giochi possono essere testati semplicemente eseguendo il loop demo o qualcosa del genere, ma quella roba è concettualmente abbastanza facile da eseguire il debug - dove sarei più interessato a passare il tempo a scoprire bug che si verificano quando un giocatore fa qualcosa, con la mentalità che un bug che il giocatore non vede mai è ovviamente meno importante di un bug che il giocatore vede.

Il che è piuttosto difficile, ovviamente. Le tattiche che funzionano su altre applicazioni (fuzzing, previsto-passa / previsto-fallito, ecc.) Non funzionano così bene qui. Nei sistemi di scripting sembra che costruire una serie di test di script per simulare un giocatore sia la strada da percorrere (vedi la risposta di JZig). Ma i test specifici per le cose che un giocatore può incontrare mi sembrano direttamente il posto migliore per concentrare il tuo tempo sia a fini umani che automatici.