Allora, visto che il forum ha ancora da nascere, vediamo di dargli una spintarella.

Vorrei discutere un po' di tecnologia atta a facilitare il beta testing. Nelle condizioni peggiori, un tester e' costretto a testare un gioco e poi a descrivere (su carta, o a computer non importa) il bug che e' avvenuto e come riprodurlo (se possibile). Se si tratta di un crash inspiegabile o di una condizione strana, il bugreport e' quasi inutile: di solito se c'e' un database elettronico, i programmatori lo flaggano come TOC ("Tester on Crack", famosissima categoria di bug) e passano ad altro.

Ho sentito di gente con engine con sistemi di replay stabili e avanzati: ogni volta che c'e' un bug/crash, il tester allega al filereport il file di replay che teoricamente e' SEMPRE in grado di riprodurre ESATTAMENTE il bug ogni volta che viene rieseguito. So che tecnicamente e' possibile, ma c'e' qualcuno che lavora proprio in questo modo?

Altri, per affrontare i crash, fanno si' che il gioco dumpi giu' lo stack e tutto questo genere di cose quando crasha (caso peggiore: l'indirizzo di crash), cosi' che il tester possa allegare questo dump che poi il programmatore si guarda a mano per avere un'idea di cosa e' successo. Ora tra l'altro, per i giochi PC, WinXP + VS .NET fanno tutto in automagico (dump del contesto e caricamento del debugger esattamente in quel momento), ma questo e' un altro discorso. Commenti? Esperienze?

In entrambi casi, c'e' poi una domanda che mi sorge spontanea: la gestione delle revisioni. Se c'ho un replay generato con la build #123, non e' detto che nella build corrente (o qualunque cosa abbia il programmatore nella sua directory) il replay funzioni. Il minidump del contesto e' praticamente garantito che non abbia senso invece. Vi e' mai capitato problemi del genere? Teoricamente con una buona organizzazione tutto e' possibile (il programmatore puo' usare un sistema di source control per riottenere i sorgenti esatti dalla build #123 e debuggare su quella), pero' e' anche possibile che i tester, per questo motivo, siano costretti a riprodurre lo stesso bug 1000 volte perche' il codice viene aggiornato troppo in fretta. Questo fa perdere tempo a tutti. Commenti? Esperienze?

Beh, pero' alla fine magari risparmi un sacco di tempo, no? Se e' una feature che prevedi fin dall'inizio puo' non essere difficile tenerla funzionante. In realta' mi stupisco che un gioco di macchine (che _DEVE_ avere il replay, e lo si sa fin dal primo giorno di sviluppo) non abbia cercato di implementare subito stabilmente il replay per poterlo sfruttare per il betatesting.

Si', quei tipi di test di resistenza sono obbligatori, la Sony li impone infatti. Mi pare un gioco PS1 dovesse girare almeno 24h in attract mode senza morire. Su questi tipi di test chiaramente il replay e' inutile, ma l'altro approccio proposto, cioe' dumpare uno stato di debugging, e' secondo me piu' comodo di una videocassetta. Si completano, nel migliore dei casi.

Ma per tutte le altre categorie di bug piu' normali? Il replay mi sembra sempre una soluzione ottimale, e soprattutto automatica.