Test Driven Development per giochi complessi

8

Sto codificando un gioco nel mio tempo libero, ma per lo più sono ancora un principiante quando si parla di programmazione. Mi dispiace se questa domanda è fuori tema o se finisce per non essere utile a nessun altro, ma spero che lo sarà.

Ho passato molto tempo a leggere libri sulla progettazione del codice, oltre a diverse metodologie e approcci alla codifica. Nel corso di questa ricerca continuo a correre sul concetto di Test Driven Development. Le persone che sposano questa idea di solito sembrano molto appassionate al riguardo. Credo che possa aiutare la velocità e l'efficienza del software di scrittura. Il tempo è una risorsa molto preziosa quindi preferirei imparare a fare le cose nel modo migliore piuttosto che cavarmela senza cercare di espandere la mia conoscenza del mestiere di programmazione.

Comunque, forse perché sono un principiante, non riesco a immaginare come applicare lo sviluppo basato sui test ai giochi. Ho trovato un paio di articoli sull'argomento ma non sono stati di grande aiuto. La maggior parte degli esempi di test unitari che ho visto sono esempi di piastre semplici, o esempi di software che non assomigliano affatto a un gioco.

Nel mio codice, cerco di avvicinarlo con una mentalità simile per testare lo sviluppo guidato, anche se sono sicuro che in realtà non si qualifica come TDD. Scrivo la quantità minima di codice per provare ad implementare qualsiasi funzione che sto aggiungendo al gioco, quindi eseguo immediatamente il test del gioco per vedere se funziona. Se le cose non accadono come volevo, faccio subito delle modifiche per avvicinarmi a ciò che voglio. Se non funziona o non funziona, e se non riesco a trovare gli errori leggendo il codice, passo i metodi nel debugger finché non trovo il comportamento imprevisto, e poi lo rimuovo. Quello che sto cercando di dire è che sto testando costantemente il gioco, praticamente dopo ogni singolo cambiamento. I test guidano il mio sviluppo. Il "test unitario" è nella mia testa, perché ad esempio so che cosa dovrebbe fare l'unità nel mio gioco, quindi faccio il test per assicurarmi che lo stia facendo, e se no, cerco di sistemarlo subito .

Attivo alla mia domanda attuale. Come si possono scrivere test unitari per un gioco complesso? Per complesso, intendo con molti aspetti emergenti del gameplay, in modo tale che la carne del gameplay emerga dall'interazione tra i molti elementi diversi all'interno del gioco combinati con le scelte del giocatore. Ad esempio, un rpg simile a un roguelike con un mondo procedurale. Che tipo di test unitari scriveresti per un gioco del genere? Come si può applicare lo sviluppo guidato da test a un gioco del genere?

    
posta bazola 19.07.2014 - 16:58
fonte

2 risposte

12

I test unitari non testano gameplay . Non ci sono criteri programmatici per vedere se un gioco è divertente o un livello è la giusta difficoltà. Le unit test metteranno alla prova che il tuo mapgen roguelike produce effettivamente un livello con una scala in alto e una scala in basso. Verificherà che le tue regole di ingombramento sono impostate in modo che il tuo personaggio si muova più lentamente quando ponderato. Si assicurerà che il tuo personaggio non possa indossare 50 cappelli . Si assicurerà che i meccanismi siano tutti implementati correttamente in relativo isolamento.

    
risposta data 19.07.2014 - 17:06
fonte
2

È difficile scrivere test unitari per codice non deterministico. Se hai codice che coinvolge numeri casuali, non sarai in grado di scrivere un test unitario che asserisca un risultato previsto.

Quindi, i test unitari sono più appropriati per il codice che è deterministico. Quando fornisco un metodo a questi input, mi aspetto queste uscite. Ad esempio: quando un combattente con 15 punti forza usa lo spadone a due mani per colpire con successo un ghoul non morto con 10 armature, mi aspetto 8 danni. La parte non deterministica (se l'hit ha avuto successo o meno) non può necessariamente essere un'unità testata, ma quello che succede dopo può essere. Anche se ci si aspetta che la quantità di danno sia entro un intervallo, puoi testarlo.

Se hai difficoltà a trovare il codice per scrivere i test unitari, devi refactoring in modo che la logica deterministica sia isolata in metodi o classi. Tira il dado in primo luogo per determinare il successo, quindi passa gli input rilevanti (classe, forza, armatura, ecc.) A un metodo testabile.

Per il tuo commento sull'avere il test unitario nella tua testa, il punto di test unitario non riguarda solo il codice appena scritto. Si tratta anche di avere fiducia che il codice funzioni ancora dopo aver apportato modifiche inevitabili .

    
risposta data 17.09.2014 - 20:44
fonte

Leggi altre domande sui tag