Test Driven Development è praticabile nello sviluppo di giochi?

23

Essendo certificato Scrum, tendo a sviluppare metodologie Agile durante lo sviluppo di un sistema, e utilizzo anche un po 'di tela dal framework Scrum per gestire il mio lavoro quotidiano.

Inoltre, mi chiedo se TDD sia un'opzione nello sviluppo del gioco, se è praticabile?

Se credo a questa domanda GD, TDD non è molto utile nello sviluppo del gioco.
Perché MVC e TDD non sono più impiegati nell'architettura di gioco?

Vengo dalla programmazione industriale in cui i grandi progetti con grandi budget devono funzionare in modo impeccabile, in quanto ciò potrebbe provocare scenari catastrofici se il codice non fosse accuratamente testato dentro e fuori.

Inoltre, seguire le regole di Scrum incoraggia a rispettare le date di scadenza del tuo lavoro mentre ogni singola azione in Scrum è scaduta! Quindi, sono d'accordo quando nella domanda sopra collegata dicono di smettere di provare a costruire un sistema e iniziare a scrivere il gioco. È proprio quello che dice Scrum, cerca di non costruire il sistema perfetto, prima: fallo funzionare alla fine dello Sprint. Quindi, refactoring il codice mentre si lavora nel secondo Sprint, se necessario!

Capisco che se non tutti i dipartimenti responsabili dello sviluppo del gioco usano Scrum, Scrum diventa inutile. Ma consideriamo per un momento che tutti i dipartimenti usano Scrum ... Penso che TDD sarebbe utile scrivere codice privo di bug, anche se non si desidera scrivere il sistema / gioco "perfetto".

Quindi la mia domanda è la seguente:

Il TDD è comunque possibile nello sviluppo di giochi?

— Will Marcouiller
fonte

Cosa aggiungerà la discussione di questa domanda oltre alla domanda che hai collegato?

Presento il framework Scrum per la gestione dei progetti nello sviluppo del software Agile e discuto su ciò che Scrum vuole da uno sviluppatore durante uno Sprint, rendendo quindi TDD praticabile come opzione. Voglio ottenere il punto di vista degli altri sull'argomento dal punto di vista Scrum, non solo sotto l'aspetto TDD o MVC. Voglio capire come il TDD non sia praticabile quando discusso da questo lato della medaglia, oltre a considerare il TDD stesso come un approccio autonomo.

— Will Marcouiller, il

@Will TDD == Top Down Design o Test Driven Design? Stavo pensando Top Down e stavo per dare una risposta di gestibilità a lungo termine, ma poi ho visto l'altra risposta interpretare TDD in un modo che non ero ...

— James,

@James: Test Driven Development.

— caos,

@James: mi dispiace per la confusione! Non sapevo dell'altro significato dell'acronimo, poiché quello che avevo in mente era Agile Software Development con Scrum.

— Will Marcouiller, il

11

È certamente fattibile, anche se molti programmatori di giochi non hanno ancora accettato l'idea, o hanno una buona conoscenza di come testare sistemi complicati. Ammetto me stesso che lo uso raramente, ad eccezione dei sistemi non correlati al gioco che sono facili da testare.

Aspettati di usare molti oggetti finti. A causa di quanto siano legati molti sistemi, è difficile testarne i singoli componenti.

Inoltre molte cose non possono essere testate a fondo. Come testare un sistema di particelle, per esempio? Come si verifica che il sistema di animazione funzioni correttamente? Molte cose sono di natura visiva e non sono ovvie (almeno per me) su come eseguire test adeguati.

Vi sono, tuttavia, molte cose che non sono necessariamente unit test nel senso tradizionale della parola, ma che esistono come "test" per caratteristiche specifiche. Cose come i livelli di test per la navigazione AI sono piuttosto comuni, ma non sono necessariamente le cose più facili da automatizzare.

Ci sono alcuni aspetti dei giochi che possono (e probabilmente dovrebbero) avere test unitari scritti per loro. È necessario testare qualsiasi tipo di sistema generico di "lettura dei file". Forse hanno alcuni test per l'inizializzazione di cose hardware (superfici 3d, ecc). Forse hai alcuni server finti e prova il tuo codice di interazione client / server. Cose del genere.

— tetrade
fonte

9

Queste sono ottime proposte per la presenza di test automatizzati, ma non per lo sviluppo guidato dai test.

1

Opinione interessante, Tetrad! Grazie per il tuo granello di sale. Chiedete come testare l'animazione visiva? Difficile dire come per i sistemi 3D, dal momento che non ho mai scritto un singolo gioco, forse dopo aver sviluppato alcuni giochi minuscoli! Inoltre, in 2D, ho visto spesso oggetti rappresentati da matrice e parser di matrice per rendere l'immagine sullo schermo. Quindi, assicurandomi che dopo aver premuto un tasto direzionale, le informazioni giuste trovate nel posto giusto nella matrice risultante possano essere un inizio, immagino. Semplicemente non so ancora abbastanza sui componenti visivi di un gioco, e sicuramente lo farò quest'anno! =)

— Will Marcouiller il

Sono tornato dopo un po 'di programmazione per dire che ho risposto a una domanda questa settimana (la mia prima su GD! =)) Che richiedeva la conoscenza dei concetti di OOP. L'OP ha voluto spostare un serpente su Keys.Down, Keys.Left, ecc Questo per dire che il gioco sa dove l'utente vuole il serpente di andare, e il serpente deve andare dove il gioco dice di, anche se questo è solo il serpente che sa muoversi nelle diverse direzioni, quindi anche della sua posizione nel gioco. Detto questo, IMHO, rende la Snakeclasse testabile! (Continua ...)

— Will Marcouiller

Non solo è testabile, ma ora è un buon candidato per TDD. Supponiamo che il serpente sia inizializzato in posizione Vector2.Zero, con una velocità di 10.0fentrambi gli assi X e Y in questo gioco 2D. La prima domanda è: è posizionata nella sua presunta posizione iniziale e come testarla? Quindi, pensi che la Positionproprietà deve essere esposta pubblicamente. Secondo: come farlo muovere? Metodi di movimento dovrebbe essere buono, quindi si scrive un test per ogni metodo di direzione MoveDown, MoveLefte così via. Ora vai a scrivere la tua dichiarazione del metodo e vedi se il test si lamenta. Quindi, riverifica la posizione del serpente

— Will Marcouiller,

dopo una MoveDownchiamata di metodo! Dal momento che sai che la Positionproprietà è stata accuratamente testata, questo è un membro su cui puoi contare! Puoi indovinare la continuazione qui! ;-) Vale a dire che i componenti visivi non possono assolutamente essere testati, ma il serpente dovrebbe apparire come un serpente, tutto a seconda del tipo di serpente che vuoi nel gioco. L'artista che disegna il serpente dovrebbe dimostrare abbastanza soddisfazione per il suo disegno del serpente, che non deve essere testato tramite TDD, ovviamente! Ma la sua posizione rispetto ad altri oggetti può, e anche la classe che rappresenta questo serpente. Infatti, TDD

— Will Marcouiller

11

Non penso che TDD, in quanto tale, sia appropriato come base per lo sviluppo del gioco. Test unitari automatizzati come parte della metodologia, certo, ma troppe preoccupazioni chiave dello sviluppo del gioco sono soggettive e non testabili a macchina perché i test possano essere il motore dello sviluppo. Come hai intenzione di scrivere un test con script per capire se una meccanica di gioco è divertente? Che un livello sia visivamente attraente? Anche che un livello impieghi un giocatore tipico in circa 15 minuti per completare? TDD si adatta a situazioni in cui la maturità di un progetto può essere misurata quantitativamente in termini di conformità a una specifica e che non è solo lo sviluppo del gioco.

— caos
fonte

3

Cosa intendi quando dici che lo sviluppo del gioco non è conforme alle specifiche? Il mio punto è che devi sapere che tipo di gioco scrivi quando vuoi scriverne uno. Pertanto, le specifiche, i requisiti devono essere scritti come caratteristiche o simili; prendiamo un esempio di Product Backlog in Scrum. Conosci le storie utente che dovrai sviluppare nel tuo gioco in modo da scrivere il gioco previsto! Quindi, per un altro esempio, forse dovrai rilevare le collisioni in un gioco di combattimento, queste sono cose testabili! Se il gioco è divertente è più della storia o della programmazione, IMHO.

— Will Marcouiller, il

@Will Marcouiller: non intendo dire che non abbiamo specifiche o non possiamo misurarne la conformità, ma che meno di ciò che è importante nel progetto può essere significativamente specificato rispetto ad altri tipi di sviluppo. Puoi scrivere "il gioco dovrebbe essere divertente" nelle tue specifiche, ma non è una specifica con un significato tecnico. Puoi e dovresti testare ciò che è testabile, ma il punto del TDD è che il test non è solo una parte del processo, è l'intera base del processo, una mentalità fondamentale, e non vedo che si muova bene con un campo soggettivo.

— caos,

2

@Will Marcouiller, sono altamente, altamente, in disaccordo sul fatto che il divertimento del gioco dipenda dalla storia. Tutto il divertimento nel gioco dipende dal gameplay, la storia è solo un bonus.

— Attaccando

1

@Will: No, sta dicendo che il divertimento che un utente deriva da un gioco non può essere determinato tramite test automatizzati e che i giochi hanno grandi quantità di cose che possono essere testate solo inviando il gioco nelle mani del consumatore.

— DeadMG

1

@DeadMG: Questo è più vero di quanto chiunque vorrebbe, ma il mio punto (non necessariamente AttackingHobo's) riguarda il fatto che il processo di sviluppo stesso deve incorporare test, da designer e produttori e sviluppatori e tester, che non possono essere quantificati in un'unità test, che ha a che fare con la qualità dell'esperienza, della sensazione, dello stile e dell'effetto estetico che il gioco crea. Dire alle persone che stanno facendo TDD quando questa è una parte così importante dello sviluppo è fondamentalmente solo mentire a loro.

— caos,

6

È un po 'difficile capire esattamente cosa stai chiedendo dal momento che il titolo riguarda esclusivamente TDD, ma sembra che tu stia facendo di Scrum parte integrante della domanda - e come ho capito, uno non richiede l'altro.

Se credo a questa domanda GD, TDD non è molto utile nello sviluppo del gioco.

È corretto. Non credo di averne mai sentito parlare in pratica nell'industria dei giochi. (Ma poi non ne ho mai sentito parlare usato al di fuori del settore dei giochi - solo dagli individui.)

Vengo dalla programmazione industriale in cui i grandi progetti con grandi budget devono funzionare in modo impeccabile, in quanto ciò potrebbe provocare scenari catastrofici se il codice non fosse accuratamente testato dentro e fuori.

I giochi non devono funzionare in modo impeccabile. Quindi c'è molta meno enfasi sulla correttezza del codice. TDD non garantisce la correttezza del codice, ma alcune persone ritengono che riduca l'erroneità. Devo ancora vedere la prova di questo.

Inoltre, seguire le regole di Scrum incoraggia a rispettare le date di scadenza del tuo lavoro mentre ogni singola azione in Scrum è scaduta!

Non ho mai visto una metodologia che non incoraggiasse a rispettare le scadenze o ad avere azioni che non avevano un limite temporale. Il problema è che, indipendentemente dalla metodologia utilizzata, stimare la complessità del software è piuttosto difficile. Non è impossibile, ma stimarlo accuratamente non ha molto a che fare con il processo. Se il mio compito è quello di aggiungere un nuovo pannello GUI, o correggere un bug con l'animazione, o aggiungere una nuova statistica ai personaggi, l'uso di Scrum non accelera affatto e l'uso di TDD sta andando rallentare l'attività (al possibile beneficio di ridurre ulteriori attività di manutenzione in un secondo momento). Certamente non semplificheranno la stima della durata dell'attività.

Penso che TDD sarebbe utile per scrivere codice privo di bug, anche se non si desidera scrivere il sistema / gioco "perfetto".

Se TDD ha dimostrato di scrivere codice migliore rispetto ad altri metodi, allora sì.

C'è prova di questo? Il fatto che l'industria potrebbe usarlo non è una prova. L'industria è ben nota per la produzione di codice scadente che viene consegnato in ritardo. L'assenza di esempi di importanti progetti TDD che sono falliti o eseguiti in ritardo potrebbe essere solo perché si tratta di un nuovo approccio e poche persone hanno effettivamente completato un tale progetto. (E quelli che sono in ritardo ... potrebbero essere ancora in esecuzione.)

Il TDD è comunque possibile nello sviluppo di giochi?

Valida? Ovviamente. Beneficial? Questo è ancora da dimostrare.

— Kylotan
fonte

1

Sfortunatamente, TDD e Scrum sono ancora fraintesi. E questo vale per i progetti esistenti che non aiuteranno né ad accelerare le correzioni di bug, né altro. Scrum è un framework per sviluppare sistemi complessi, come sembra un gioco. Scrum incoraggia la correzione di errori da uno Sprint a un altro in modo che non si accumulino mai. TDD ti mette dalla parte dell'utente. Per utente, intendo programmatori di colleghi che useranno il tuo codice. Ti costringe a pensare come dovrebbe essere usato per rendere il tuo codice facile da usare per gli altri. Quindi, porta a un design migliore, per esperienza. Detto questo, hai avuto interessanti visioni sull'argomento.

— Will Marcouiller il

1

Forzare i bug a non accumularsi provoca solo lo slittamento delle funzionalità: non è possibile produrre magicamente più tempo. La mia comprensione è che Scrum non ha comunque alcun metodo specifico specifico per i bug. Quanto a TDD che ti costringe a pensare a come altre persone useranno il tuo codice, non è l'unico modo per farlo. Pertanto non è necessariamente migliore, e certamente non necessariamente l'uso più efficace del tempo.

— Kylotan,

1

Cordiali saluti, Noel Llopis usa TDD per i suoi giochi indie, e la sua vecchia compagnia High Moon Studios lo ha usato ampiamente. Non ho ricevuto una citazione, scusa.

— dieci

Hai dei buoni punti interessanti da leggere! Grazie per il tuo contributo Tuttavia, vorrei aggiungere che TDD è un altro approccio proprio come XP (programmazione estrema). E sì, Scrum non fornisce alcun metodo specifico specifico per i bug, e piuttosto investe sull'auto-organizzazione del Team (degli sviluppatori). Scrum non ti dice come fare le cose, dice solo cosa si dovrebbe fare. È l'impegno del team di esaminare ciò che deve essere fatto. Scrum punta solo su squadre interfunzionali auto-organizzate. È il team che decide come sviluppare e testare le funzionalità, ecc.

— Will Marcouiller

(continua ...) Ho risposto alla mia prima domanda questa settimana sulle lezioni qui su GD. L'OP voleva sapere come far muovere il suo sprite su tasti direzionali direzionali. Trovandomi a mio agio con i concetti di OOP, ho capito che forse avrei dovuto usare le classi per sviluppare il mio primo gioco usando XNA. Detto questo, la mia Spacecraftclasse diventa una classe completamente testabile con metodi e proprietà. Questo è il tipo di cose che assolutamente, IMHO, possono essere testate completamente usando TDD. Diciamo che hai bisogno di un veicolo spaziale, quindi scrivi i test per quello che ti serve per realizzare un test alla volta.

— Will Marcouiller

4

scusate il mio povero inglese e scusate il mio punto di vista parziale: non sono un game designer ma un programmatore.

Penso che ci siano dei malintesi in questa discussione. parlerò di TDD in forma più generale, il cosiddetto BDD. Lo sviluppo guidato dal comportamento non è un modo per testare il progetto (i test sono qualcosa di simile agli effetti collaterali). BDD è un modo di progettare , un modo di fare refactoring e progettazione di software durante tutta la produzione (vedi alcuni motti come KISS, "mantieni la qualità in", "test in anticipo, test spesso") e non in una sola fase. BDD è l'opposto di alcuni processi software classici come il processo a cascata o qualche altra metodologia iterativa per creare software.

Un altro punto è che i test automatici riguardano quelle funzionalità che potrebbero essere testate automaticamente da una macchina computazionale. non esiste un test per il divertimento nei giochi e non esiste un test per l'usabilità di un'interfaccia utente grafica. divertimento o usabilità sono materiali per altri lavori e non per lo sviluppo di software come designer di interazioni, mondo e livello d. allo stesso modo in cui le parti artistiche (modellazione, texturing, ecc.) sono per artisti che usano i computer come strumento per la creatività - ovviamente quei lavori potrebbero essere eseguiti dalla stessa persona che scrive codice, ma non è questo il punto. la fisica potrebbe essere testata, gli algoritmi di ottimizzazione potrebbero essere testati, i comportamenti di singoli oggetti potrebbero essere testati (con beffe, tronconi e manichino come menzionato prima)

l'ultimo pensiero è che, imho, è che non solo il design del gioco, ma l'intero codice di scrittura è un'arte.

— nkint
fonte

4

Ecco un case study di qualcuno che pensa che TDD e gamedev si mescolino abbastanza bene:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

Certo, questo è un piccolo progetto in Pygame, ma dà l'idea di quali parti possono essere testate con un gioco grafico e quali no. Sono stato sorpreso da quanto si potesse fare con TDD in questo scenario.

— Brandon
fonte

1

Senza un confronto con un gruppo di controllo che ha fatto lo stesso progetto (clonare un gioco arcade banale esistente in un linguaggio di altissimo livello), non dice nulla sull'efficacia o meno del TDD. Dice solo che ha usato TDD.

3

No, Test Driven Development non è adatto allo sviluppo di giochi. Sicuramente puoi scrivere test per alcune parti che vuoi testare, ma il processo di sviluppo del gioco è completamente diverso dallo sviluppo guidato dai test che richiede di avere specifiche esatte prima di iniziare i progressi.

I giochi raramente hanno specifiche esatte all'avvio. E se lo fanno, cambiano sempre e si evolvono durante il processo di sviluppo.

Il design del gioco è un'arte, non puoi avere test specifici per sapere quando l'arte è buona o completa.

— AttackingHobo
fonte

Non pensi che il fattore divertente debba essere considerato quando si analizza il gioco stesso, l'analisi funzionale o simili? Puoi impostare una serie di funzionalità che renderanno il gioco divertente da giocare, e queste funzionalità sono quindi testabili! Sto solo cercando di avanzare opinioni diverse per approfondire l'argomento e gli argomenti che ti vengono in mente. Grazie per il tuo contributo! =)

— Will Marcouiller il

3

Un sacco di sviluppo si riduce a modificare piccole cose e vedere quanto sono divertenti da giocare. Non puoi testare queste cose a meno che non siano incastonate al 100%. E testare un sistema dopo che è stato fatto non è TDD, è test, ma non sviluppo che è guidato da test.

— Attaccando

2

Se pensi che la maggior parte dei progetti del mondo reale abbia specifiche esatte all'avvio, probabilmente non hai lavorato su molti progetti del mondo reale.

— BlueRaja - Danny Pflughoeft il