Come si ottengono dati utili dai playtester? [chiuso]

Ci sono alcuni tipi di feedback che puoi ottenere dai playtester e mi chiedo come raccogliere al meglio i dati per ciascuno di essi ...

1. Rapporti sugli arresti anomali. Quando il mio gioco in C ++ si arresta in modo anomalo mentre qualcuno lo sta giocando, come posso assicurarmi di conoscerlo e anche meglio ... cosa lo ha causato? Anche ottenere qualcosa di semplice come il numero di file e riga che ha causato un arresto sarebbe incredibilmente utile.

2. Feedback sul design. Quando un tester di gioco sta giocando, come posso capire se si stanno divertendo, perché si divertono, perché non si divertono e cosa dovremmo dedicare del tempo ad adattarci?

Presumo che tu stia parlando di playtesters in loco e non di beta tester internet.

Regola n. 1: non aiutarli . La frustrazione dovrebbe essere la cosa migliore che dovresti controllare. La situazione ideale sarebbe uno specchio a due vie con la tua squadra su un lato e il playtester su un altro con una videocamera sul viso e un altro sullo schermo. Ovviamente questo non è fattibile per la maggior parte delle persone, quindi fai il meglio che puoi. Solo avere i tuoi designer seduti e guardare dove le persone rimangono bloccate è un'informazione molto utile. Non starai alle loro spalle quando porteranno la partita a casa, quindi dare consigli su come passare determinate sezioni non ti fornirà le informazioni di cui hai bisogno. Modifica : un altro modo di dirlo è questo: non pensare che stiano "giocando male"

Regola n. 2: non dare loro quello che vogliono . Dopo una sessione di playtest hai una sorta di questionario che compilano. I suggerimenti specifici che hanno di solito non sono saggi da prendere al valore nominale. Di solito c'è una causa alla radice che sta innescando la maggior parte delle risposte e loro semplicemente non sanno come esprimerla. Se riesci a capirlo, farai meglio a farlo. Anche se al momento ho problemi a trovare esempi specifici.

Regola n. 3: i dati sono re . Se puoi (e questo è davvero un altro elemento della lista dei desideri, onestamente), traccia tutto ciò che puoi. Traccia dove muoiono i giocatori. Traccia dove finiscono le munizioni da una pistola specifica. Tieni traccia dei pickup che mancano. Tieni traccia degli aggiornamenti che acquistano. Tieni traccia di ciò che i nemici fanno loro del male. Ovviamente questi sono esempi specifici di FPS, ma sono sicuro che ce ne sono di specifici per qualsiasi gioco tu stia facendo. Se tutti stanno facendo qualcosa o non stanno facendo qualcosa, quelle sono di solito aree che dovresti passare un po 'più di tempo a guardare.

Fondamentalmente, non ti importa cosa pensano i giocatori . Ti interessa ottenere numeri grezzi per quello che fanno i giocatori . Hai bisogno di occhi vergini per vedere il tuo gioco e dirti cosa li rende frustrati e cosa sono portati a fare.

Per gli arresti anomali, esaminare i minidump . Non sono perfetti, ma sono uno strumento molto utile per capire dove si trovano gli arresti anomali.

Considera anche uno strumento di segnalazione bug integrato. Qualcosa in cui l'utente può fare uno screenshot, aggiungere una descrizione e inviarlo via e-mail automaticamente a qualcuno dall'interno del gioco. Idealmente con un'istantanea del mondo (ad es. Salvataggio rapido o una sorta di dump della memoria) se il gioco lo supporta.

Espandere i dati è un po ' re sentiment (da +1 a Tetrad!):

Verifica la registrazione e la riproduzione :

• Se il tuo gioco è deterministico e basato su frame, potrebbe essere necessario memorizzare solo un seme casuale iniziale e una tupla (key/button state, joystick/mouse coords, frame #)ogni volta che cambia lo stato di input. La riproduzione è semplice come reindirizzare i tuoi input a questo stream. (Abbiamo fatto questo per molti giochi di salto con la piattaforma in passato.)
• Se il tuo gioco ha API o sistemi di messaggi ben definiti per eseguire azioni (un gioco di strategia a turni, un gioco di carte, un gioco da tavolo o simili), potresti essere in grado di raccogliere chiamate o messaggi API in un determinato punto di contatto . (Lo abbiamo fatto per un gioco di carte per una piattaforma portatile.)
• È più difficile su alcuni sistemi (i sistemi timestep meno deterministici, thread o arbitrari possono essere una seccatura) ma può valere comunque la pena registrare i dati; puoi ottenere risultati "abbastanza vicini" per alcuni usi.

Un sistema "replay" basato su questi metodi presenta numerosi vantaggi:

• usarlo per riprodurre crash in un debug o build o ambiente altrimenti strumentati;
• caricare i replay in una build di profilazione e ottenere dati sulle prestazioni o sull'utilizzo delle risorse;
• collegalo al gioco per fornire la funzionalità di "replay istantaneo", magari con una fotocamera diversa o un passo temporale;
• impostare un gameplay di dimostrazione in "modalità attrattiva" se l'utente si attacca senza fare nulla su un menu;
• mettilo sul tuo sistema di build come test del fumo: se riesco a riprodurre questo replay senza crash, è più probabile una buona build;
• guarda esempi di persone che giocano per vedere cosa hanno fatto e cosa non hanno fatto.

Collega input casuali piuttosto che un flusso registrato e hai un ottimo test delle scimmie che puoi lasciare in ammollo durante la notte o quando le macchine di sviluppo sono inattive.

Successivamente, esegui la registrazione di un evento . Per un ipotetico FPS, inizia con qualcosa come "tempo T: X ucciso Y nel punto Z con l'arma W": mettilo in un registro.

Dopo aver raccolto alcuni dati, scopri come automatizzare la raccolta . Non deve essere elegante durante lo sviluppo:

• connettersi a un server SQL e inserire righe,
• attiva e dimentica i pacchetti UDP su alcuni semplici server syslog-ish,
• invia il log per e-mail al prossimo avvio del gioco,
• avvolgere semplicemente l'eseguibile in uno script shell o in un file batch che rinomina e copia un file .log su un'unità condivisa comune,
• (più tardi, per build di produzione) utilizzare Windows Error Reporting o un servizio simile per raccogliere i dati sugli arresti anomali ...

Non importa, purché tu possa raccogliere dati.

Ora estendilo: raccogli i dump di arresto anomalo, le tracce dello stack e le registrazioni di input o eventi. Aggiungi più eventi e più origini dati:

• campiona la posizione o la mano del giocatore ogni 10 secondi, tracciala su una mappa - "hey, nessuno usa questo angolo che ho trascorso una settimana a modellare, il tempo di mettere un power-up lì"
• getFreeMemoryBytes() ogni mezzo minuto
• getFPS() periodicamente
• scattare una foto o un video di ciò che l'utente sta facendo tramite una webcam (ottimo per i test di usabilità automatizzati - solo con il permesso e la comprensione dell'utente, ovviamente)
• afferrare le informazioni di sistema (di nuovo, con il permesso dell'utente)

La cosa "tracciala su una mappa" può diventare davvero fantastica dopo un po ': immagina una vista aerea di una mappa RTS o FPS. Metti un cursore su di esso, che rappresenta il tempo dall'inizio del gioco. Seleziona un tipo di evento ("ottenuto l'oro", "ucciso qualcuno", qualunque cosa). Seleziona un set di dati: forse un gioco, forse 500 giochi negli ultimi mesi. Inizia a tirare il cursore verso destra e osserva l'attività pop sulla mappa.

E se non riesci a trovare buone librerie per aiutarti con queste cose (ce ne sono alcune qua e là, però!), Considera l'idea di farne una tua: è una bella esperienza di apprendimento e non deve essere particolarmente elegante per essere utile.

Ottieni i dati, scoprirai cosa farne. =)

Ovviamente questo dipende molto da ... a) che tipo di test vuoi fare, eb) che tipo di gioco stai testando, e c) che tipo di tester e infrastruttura hai a disposizione ...

Differisce anche molto se stai testando per a) funzionalità, b) bilanciamento c) progettazione del gioco

Ma in generale potresti voler considerare questi aspetti ...

* a) Scegli la persona giusta per il lavoro Sembra troppo semplice da menzionare, ma l'ho visto molte volte e l'ho visto di nuovo dal vivo. Come sempre, ci sono differenze significative tra le persone per quanto riguarda la loro bravura in diversi lavori. Alcune persone che sono disposte o forse desiderose di fare test potrebbero non giocare abbastanza a fondo per trovare bug insoliti (o anche semplici). Alcuni non sono bravi a descrivere i bug. Alcuni sono più bravi a testare i problemi di bilanciamento, altri sono più attenti alle debolezze visive, altri sono più creativi nel giocare in modo insolito e trovano bug nascosti / rari, alcuni sono più attenti alla qualità tecnica o visiva, altri sono più bravi a comprendere gli aspetti della meccanica di gioco e potrebbe anche essere in grado di suggerire cambiamenti significativi (se vuoi che i tuoi tester lo facciano;).

* b) Utilizzare un software Issue-Tracker / Bug-Tracker Questi strumenti possono non solo aiutare a organizzare i problemi, ma anche ad aumentare la qualità dell'output dei tester dando loro un frame su cui lavorare e imparando dai feedback che ottengono dagli sviluppatori sui loro problemi. Aiuta a migliorare la qualità dell'output dei tester molto più velocemente rispetto a quando lavori senza di essa. (Aiuta molto anche con i tester remoti) Il software tipico usato dagli studi di gioco è Mantis, JIRA (e ovviamente molti altri ..) Vedi Wikipedia per un elenco generale e anche questo post su SO.

c) Aggiungi strumenti di test del gioco In genere sono le scorciatoie per testare livelli o sezioni specifici del gioco. Visualizzazione di informazioni extra durante il gioco ai tester in modo che possano aggiungerli ai report dei bug. Questa potrebbe essere la posizione in un livello, il numero di oggetti attivi in ​​una scena, la quantità di texture-ram o palette attualmente in uso, qualcosa di utile per gli sviluppatori.

d) Combina tester esperti con sangue fresco Sempre una buona cosa avere tester che hanno molta esperienza con il tuo gioco e hanno imparato quali sono i problemi tipici e come (ri) testarli. Allo stesso tempo vuoi nuovi giocatori "vergini" di tanto in tanto, soprattutto per il bilanciamento.

e) Avere un responsabile del test Qualcuno che coordina il processo e lo adatta al gioco attuale, alle priorità attuali e ai tester disponibili e all'ambiente di test.

f) Avere un documento del piano di prova Questo varrebbe la pena di un post aggiuntivo.

Come menzionato da Tetrad, ottieni quanti più dati oggettivi possibile. Mettere in agganci per memorizzare determinati eventi e scaricarli tutti su un .csv non è molto difficile. E una volta ottenuto in Excel, puoi studiare, rappresentare graficamente e tracciare fino a quando le mucche tornano a casa.

Inoltre, hai domande specifiche a cui stai cercando di rispondere. Gli scienziati non si limitano a sedersi, accendere alcuni esperimenti e "fare scienza". Hanno domande specifiche e misurabili su cui desiderano dati. Otterrai spesso il massimo dal playtest se segui lo stesso approccio. Cercare di capire se il tuo gioco è "buono" è molto difficile da quantificare. Ma capire se la semplice missione tutorial richiede solo i 5 minuti che ti aspetti, o se i tester stanno lottando per risolvere un certo puzzle, può effettivamente essere valutato.

A volte, il modo più efficace per testare è iterativamente in raffiche brevi. Chiedi a un paio di tester di andare per circa un'ora al mattino, apportare alcune modifiche ai problemi che identificano e andare di nuovo con i nuovi tester la mattina seguente. Ovviamente devi guardare una funzione abbastanza piccola da migliorare in un pomeriggio. Ma per un problema che è stato particolarmente testardo, questo metodo può avere molto successo.

Sicuramente d'accordo con la regola n. 1 di Tetrad. Non aiutarli. Direi che un avvertimento è spiegare loro che non li aiuterai e se hanno bisogno di aiuto per favore chiedi. In questo modo il giocatore non finisce per essere frustrato.

Il questionario dovrebbe porre domande aperte, anziché semplici Sì / No, a seconda dell'età e del numero di tester, questi possono essere moduli che compilano, oppure è possibile porre le domande. È anche importante porre domande sulla loro storia e la loro familiarità con il genere di gioco che stai testando; questo aggiungerà contesto alle loro risposte specifiche sul tuo gioco.

Fortunatamente quando il mio gioco si arresta in modo anomalo, mi viene fornito un dump di informazioni sull'errore, quindi posso fare una foto e prendere nota di ciò che il giocatore stava facendo. Normalmente collaudo le fasce di età più giovani, quindi quando si verifica un incidente devo ricordare di aver spiegato loro che stanno facendo un ottimo lavoro: possono arrabbiarsi dopo aver interrotto il gioco. I playtester hanno davvero dimostrato di essere bravi a trovare bug oscuri che il team di sviluppo non si sarebbe mai imbattuto nel gioco nel modo "giusto".

È possibile scrivere codice che rileva gli arresti anomali e registra lo stack di chiamate. Questo può aiutare molto con le segnalazioni di bug. Anche avere un utile file di registro generato aiuta. Puoi chiedere all'utente di inviare questi file la prossima volta che giocano, o avere uno strumento autonomo che viene eseguito dopo la chiusura del gioco o si blocca se lo desideri.

Per i rapporti sugli arresti anomali, dovresti fare affidamento sul personale addetto al controllo qualità, non sui playtester. Il QA è qualcuno che assumi specificamente per la sua capacità di trovare bug e segnalarli in modo significativo, e un buon tester vale il loro peso in oro (e costa solo un decimo del loro peso in oro, rispetto ai programmatori!).

Se sei preoccupato per "oh, e se scoprissero accidentalmente un incidente, non vorremmo perderlo solo perché non stanno testando per questo" ... questo è ciò che serve per la registrazione. Un sistema di registrazione sufficientemente buono dovrebbe registrare abbastanza elementi di gioco per essere in grado di riprodurre esattamente un incidente.

Per un feedback sul design, non c'è alcun sostituto per far sì che i progettisti del gioco li guardino giocare (o utilizzare un videoregistratore se necessario, ecc.). Non fare affidamento sulla memoria o sulle opinioni di Playtester, entrambe notoriamente povere. Ma se li guardi suonare in tempo reale, è palesemente ovvio solo guardando la loro posizione del viso e del corpo se sono fidanzati, annoiati o frustrati.