Ist testgetriebene Entwicklung in der Spieleentwicklung realisierbar?


23

Da ich Scrum-zertifiziert bin, tendiere ich dazu, bei der Entwicklung eines Systems auf agile Methoden zu setzen, und verwende sogar einige Canvas-Elemente aus dem Scrum-Framework, um meine tägliche Arbeit zu verwalten.

Außerdem frage ich mich, ob TDD eine Option in der Spieleentwicklung ist, wenn es machbar ist.

Wenn ich an diese GD-Frage glaube, ist TDD für die Spieleentwicklung nicht besonders nützlich.
Warum wird MVC & TDD nicht mehr in der Spielearchitektur eingesetzt?

Ich komme aus der industriellen Programmierung, wo große Projekte mit großem Budget einwandfrei funktionieren müssen, da dies zu katastrophalen Szenarien führen kann, wenn der Code nicht gründlich von innen und außen getestet wird.

Wenn Sie die Scrum-Regeln einhalten, können Sie die Fälligkeitstermine Ihrer Arbeit einhalten, während jede einzelne Aktion in Scrum zeitlich begrenzt ist! Also stimme ich zu, wenn sie in der oben verlinkten Frage sagen, dass sie aufhören sollen, ein System aufzubauen, und das Spiel schreiben sollen. Es ist genau das, was Scrum sagt, versuchen Sie nicht, das perfekte System zu bauen, sondern sorgen Sie dafür, dass es bis zum Ende des Sprints funktioniert. Dann überarbeiten Sie den Code, während Sie im zweiten Sprint arbeiten, falls erforderlich!

Ich verstehe, dass Scrum unbrauchbar wird, wenn nicht alle Abteilungen, die für die Spieleentwicklung verantwortlich sind, Scrum verwenden. Aber nehmen wir für einen Moment an, dass alle Abteilungen Scrum verwenden ... Ich denke, dass TDD gut wäre, um fehlerfreien Code zu schreiben, obwohl Sie nicht das "perfekte" System / Spiel schreiben möchten.

Meine Frage lautet also wie folgt:

Ist TDD in der Spieleentwicklung überhaupt brauchbar?


Was wird die Diskussion aus dieser Frage über die von Ihnen verknüpfte Frage hinaus hinzufügen?

Ich präsentiere das Scrum-Framework des Projektmanagements in der agilen Softwareentwicklung und diskutiere, was Scrum während eines Sprints von einem Entwickler erwartet, um TDD als Option nutzbar zu machen. Ich möchte den Standpunkt der anderen zu diesem Thema aus der Sicht von Scrum einnehmen, nicht nur unter dem Aspekt TDD oder MVC. Ich möchte verstehen, warum TDD nicht tragfähig ist, wenn man von dieser Seite der Medaille aus argumentiert, außer TDD selbst als eigenständigen Ansatz zu betrachten.
Will Marcouiller

@Will TDD == Top Down Design oder Test Driven Design? Ich dachte nach oben nach unten und wollte auf lange Sicht eine Antwort zur Verwaltbarkeit geben, sah dann aber, dass die andere Antwort TDD so interpretierte, wie ich es nicht war ...
James

@ James: Test Driven Development.
Chaos

@ James: Sorry für die Verwirrung! Ich wusste nichts über die andere Bedeutung des Akronyms, da ich an Agile Software Development with Scrum dachte.
Will Marcouiller

Antworten:


11

Es ist auf jeden Fall rentabel, obwohl viele Spieleprogrammierer sich noch nicht wirklich mit der Idee befasst haben oder ein gutes Verständnis dafür haben, wie man komplizierte Systeme testet. Ich gebe selbst zu, dass ich es selten benutze, außer bei Systemen, die nicht mit dem Spiel zusammenhängen und einfach zu testen sind.

Erwarten Sie, viele Scheinobjekte zu verwenden. Da viele Systeme miteinander verbunden sind, ist es schwierig, einzelne Komponenten davon zu testen.

Außerdem können viele Dinge nicht gründlich getestet werden. Wie testet man beispielsweise ein Partikelsystem? Wie testen Sie, ob Ihr Animationssystem ordnungsgemäß funktioniert? Viele Dinge sind visueller Natur und (zumindest für mich) nicht offensichtlich, wie man richtig testet.

Es gibt jedoch viele Dinge, die nicht unbedingt Unit-Tests im herkömmlichen Sinne des Wortes sind, sondern als "Tests" für bestimmte Funktionen existieren. Dinge wie Testniveaus für die AI-Navigation sind ziemlich häufig, aber nicht unbedingt die am einfachsten zu automatisierenden Dinge.

Es gibt bestimmte Aspekte von Spielen, für die Unit-Tests geschrieben werden können (und sollten). Jede Art von generischem "Dateilesesystem" sollte getestet werden. Vielleicht haben einige Tests für die Initialisierung von Hardware-Dingen (3D-Oberflächen, etc.). Vielleicht haben Sie einige Mock-Server und testen Sie Ihren Client / Server-Interaktionscode. Sachen wie diese.


9
Dies sind großartige Vorschläge für das Vorhandensein automatisierter Tests, aber überhaupt nicht für die testgetriebene Entwicklung.

1
Interessante Meinung, Tetrad! Danke für dein Salzkorn. Sie fragen, wie Sie die visuelle Animation testen sollen? Schwer zu sagen für 3D-Systeme, da ich noch kein einziges Spiel geschrieben habe, vielleicht nachdem einige ein paar winzige Spiele entwickelt haben! Außerdem habe ich in 2D oft Objekte gesehen, die durch Matrix dargestellt wurden, und Matrix-Parser, um das Bild auf dem Bildschirm zu rendern. Wenn Sie also sicherstellen, dass nach einigem Drücken der Richtungstaste die richtigen Informationen an der richtigen Stelle in der resultierenden Matrix gefunden werden, könnte dies ein Anfang sein. Ich weiß nur noch nicht genug über visuelle Komponenten eines Spiels, und das werde ich auch in diesem Jahr tun! =)
Will Marcouiller

Ich bin nach einigem Codieren zurück, um zu sagen, dass ich diese Woche eine Frage beantwortet habe (meine erste bei GD! =)), Die Kenntnisse über OOP-Konzepte erforderte. Die OP wollte eine Schlange bewegen auf Keys.Down, Keys.Leftusw. Das zu sagen , dass das Spiel weiß , wo der Benutzer die Schlange gehen will, und die Schlange hat zu gehen , wo das Spiel es sagt, aber , dass nur die Schlange ist , die wissen , wie man in die verschiedenen Richtungen zu bewegen, daher auch von seiner Position im Spiel. Nachdem dies gesagt wurde, macht IMHO die SnakeKlasse zu einer prüfbaren! (Fortsetzung
folgt

Es ist nicht nur testbar, sondern auch ein guter Kandidat für TDD. Nehmen wir an, die Schlange wird an der Position Vector2.Zeromit einer Geschwindigkeit 10.0fauf der X- und Y-Achse in diesem 2D-Spiel initialisiert . Die erste Frage ist: Befindet es sich an seiner vermeintlichen Ausgangsposition und wie kann man es testen? Dann denken Sie, dass das PositionEigentum öffentlich ausgestellt werden soll. Zweitens: Wie kann man es bewegen? Bewegung Methoden sollten gut sein, so dass Sie einen Test für jede Richtung Methode schreiben MoveDown, MoveLeftund so weiter. Schreiben Sie jetzt Ihre Methodendeklaration und prüfen Sie, ob sich der Test beschwert. Dann überprüfen Sie die Position der Schlange
Will Marcouiller

nach einem MoveDownMethodenaufruf! Da Sie wissen, dass die PositionImmobilie gründlich getestet wurde, können Sie sich auf dieses Mitglied verlassen! Sie können die Fortsetzung hier erraten! ;-) Das heißt, dass visuelle Komponenten definitiv nicht getestet werden können, aber die Schlange sollte wie eine Schlange aussehen, je nachdem, welche Art von Schlange Sie im Spiel haben möchten. Der Künstler, der die Schlange zeichnet, sollte genug Zufriedenheit mit seiner Zeichnung der Schlange nachweisen, die natürlich nicht durch TDD getestet werden darf! Aber seine Position relativ zu anderen Objekten kann es, und die Klasse, die diese Schlange repräsentiert, auch. In der Tat, TDD
Will Marcouiller

11

Ich denke nicht, dass TDD als solches als Grundlage für die Spieleentwicklung geeignet ist. Sicher, automatisierte Komponententests als Teil der Methodik, aber zu viele der Hauptanliegen der Spieleentwicklung sind subjektiv und können nicht maschinell getestet werden, um der Treiber der Entwicklung zu sein. Wie werden Sie einen Skripttest schreiben, um festzustellen, ob eine Spielmechanik Spaß macht? Dass ein Level optisch ansprechend ist? Selbst dass ein Level für einen typischen Spieler ungefähr 15 Minuten dauert? TDD eignet sich für Situationen, in denen die Reife eines Projekts quantitativ anhand der Einhaltung einer Spezifikation gemessen werden kann und dies keine Spieleentwicklung ist.


3
Was meinen Sie, wenn Sie sagen, dass die Spieleentwicklung nicht den Spezifikationen entspricht? Mein Punkt ist, dass Sie wissen müssen, welche Art von Spiel Sie schreiben, wenn Sie eines schreiben möchten. Als solche müssen Spezifikationen, Anforderungen als Merkmale oder dergleichen geschrieben werden; Nehmen wir ein Beispiel für Product Backlog in Scrum. Sie kennen die User Stories, die Sie in Ihrem Spiel entwickeln müssen, damit Sie das erwartete Spiel schreiben können! Dann, zum Beispiel, müssen Sie vielleicht Kollisionen in einem Kampfspiel erkennen, das sind prüfbare Dinge! Ob das Spiel Spaß macht, ist mehr von der Geschichte oder als das Programmieren, IMHO.
Will Marcouiller

@ Will Marcouiller: Ich möchte nicht implizieren, dass wir keine Spezifikationen haben oder nicht messen können, ob sie eingehalten werden, aber dass weniger von dem, was an dem Projekt wichtig ist , sinnvoll spezifiziert werden kann als bei anderen Arten der Entwicklung. Sie können "Das Spiel soll Spaß machen" in Ihre Spezifikation schreiben, aber das ist keine Spezifikation mit technischer Bedeutung. Sie können und sollten testen, was prüfbar ist, aber der Punkt von TDD ist, dass das Testen nicht nur Teil des Prozesses ist, sondern die gesamte Grundlage des Prozesses, eine grundlegende Denkweise, und ich sehe, dass es nicht gut mit einem Hoch übereinstimmt subjektives Feld.
Chaos

2
@Will Marcouiller, ich bin absolut anderer Meinung, dass der Spaß am Spiel auf die Geschichte zurückzuführen ist. Der ganze Spaß im Spiel hängt vom Gameplay ab, die Story ist nur ein Bonus.
AttackingHobo

1
@Will: Nein, er sagt, dass die Freude, die ein Benutzer an einem Spiel hat, nicht durch einen automatischen Test ermittelt werden kann und dass Spiele eine große Menge an Dingen enthalten, die nur getestet werden können, wenn das Spiel in die Hände des Verbrauchers gegeben wird.
DeadMG

1
@DeadMG: Das stimmt mehr als jeder andere, aber mein Punkt (nicht unbedingt der von AttackingHobo) ist die Tatsache, dass der Entwicklungsprozess selbst Tests von Designern und Produzenten sowie Entwicklern und Testern beinhalten muss, die nicht in einer Einheit quantifiziert werden können Test, das hat mit der Qualität der Erfahrung und des Gefühls und des Stils und der ästhetischen Wirkung zu tun, die das Spiel erzeugt. Menschen zu sagen, dass sie TDD machen, wenn dies ein so wichtiger Teil der Entwicklung ist, bedeutet im Grunde nur, sie anzulügen.
Chaos

6

Es ist ein bisschen schwierig, genau herauszufinden, was Sie fragen, da es sich bei dem Titel nur um TDD handelt, aber Sie scheinen Scrum auch zu einem integralen Bestandteil der Frage zu machen - und so wie ich es verstehe, erfordert eines das andere nicht.

Wenn ich an diese GD-Frage glaube, ist TDD für die Spieleentwicklung nicht besonders nützlich.

Das ist richtig. Ich glaube nicht, dass ich jemals davon gehört habe, wie es in der Spielebranche in der Praxis eingesetzt wird. (Aber ich habe auch noch nie davon gehört, dass es außerhalb der Spielebranche verwendet wird - nur von Einzelpersonen.)

Ich komme aus der industriellen Programmierung, wo große Projekte mit großem Budget einwandfrei funktionieren müssen, da dies zu katastrophalen Szenarien führen kann, wenn der Code nicht gründlich von innen und außen getestet wird.

Spiele müssen nicht einwandfrei funktionieren. Daher wird die Code-Korrektheit viel weniger betont. TDD garantiert keine Code-Korrektheit, aber einige Leute sind der Meinung, dass dies die Fehlerhaftigkeit verringert. Ich muss noch Beweise dafür finden.

Wenn Sie die Scrum-Regeln einhalten, können Sie die Fälligkeitstermine Ihrer Arbeit einhalten, während jede einzelne Aktion in Scrum zeitlich begrenzt ist!

Ich habe noch nie eine Methode gesehen, die nicht zur Einhaltung von Fälligkeitsterminen oder zu Aktionen ohne Zeitrahmen ermutigt hat. Das Problem ist, dass das Abschätzen der Softwarekomplexität unabhängig von der verwendeten Methodik ziemlich schwierig ist. Es ist nicht unmöglich, aber genau abzuschätzen, hat nicht viel mit dem Prozess zu tun. Wenn es meine Aufgabe ist, ein neues GUI-Bedienfeld hinzuzufügen, einen Fehler in der Animation zu beheben oder Zeichen eine neue Statistik hinzuzufügen, wird die Verwendung von Scrum das überhaupt nicht beschleunigen, und die Verwendung von TDD wird es auch tun die Aufgabe zu verlangsamen (zum möglichen Vorteil, später weitere Wartungsaufgaben zu reduzieren). Sie werden es sicherlich nicht einfacher machen, die Aufgabendauer abzuschätzen.

Ich denke, dass TDD gut wäre, um fehlerfreien Code zu schreiben, obwohl Sie nicht das "perfekte" System / Spiel schreiben möchten.

Wenn TDD nachweislich besseren Code schreibt als andere Methoden, dann ja.

Gibt es Beweise dafür? Die Tatsache, dass die Industrie es nutzen könnte, ist kein Beweis. Die Industrie ist dafür bekannt, schlechten Code zu produzieren, der verspätet geliefert wird. Das Fehlen von Beispielen für große TDD-Projekte, die gescheitert sind oder sich verspäten, kann nur daran liegen, dass es sich um einen neuen Ansatz handelt und nur wenige Leute ein solches Projekt tatsächlich abgeschlossen haben. (Und diejenigen, die spät dran sind ... laufen möglicherweise noch.)

Ist TDD in der Spieleentwicklung überhaupt brauchbar?

Lebensfähig? Na sicher. Vorteilhaft? Das muss noch bewiesen werden.


1
Leider werden TDD und Scrum immer noch missverstanden. Dies gilt auch für bestehende Projekte, die weder zur Beschleunigung von Fehlerkorrekturen noch zu anderen Zwecken beitragen. Scrum ist ein Framework zur Entwicklung komplexer Systeme, wie es ein Spiel zu sein scheint. Scrum ermutigt dazu, Fehler von einem Sprint zum nächsten zu beheben, damit sie sich nie ansammeln. TDD stellt Sie auf die Seite des Benutzers. Mit Benutzer meine ich Programmierkollegen, die Ihren Code verwenden. Es zwingt Sie zu überlegen, wie Sie Ihren Code für andere Benutzer benutzerfreundlich gestalten sollten. Dies führt zu einem besseren Design pro Erfahrung. Das alles sagte, Sie haben interessante Ansichten zum Thema.
Will Marcouiller

1
Wenn Sie Fehler dazu zwingen, sich nicht anzusammeln, rutschen die Funktionen einfach aus - Sie können nicht auf magische Weise mehr Zeit produzieren. Ich verstehe, dass Scrum sowieso keine bestimmte Methode für Fehler hat. TDD zwingt Sie, darüber nachzudenken, wie andere Benutzer Ihren Code verwenden. Dies ist jedoch nicht der einzige Weg, dies zu tun. Daher ist es nicht unbedingt besser und sicherlich nicht unbedingt die effektivste Nutzung der Zeit.
Kylotan

1
Zu Ihrer Information, Noel Llopis verwendet TDD für seine Indie-Spiele, und seine alte Firma High Moon Studios hat es ausgiebig genutzt. Ich habe kein Zitat, sorry.
Am

Sie haben einige gute Punkte interessant zu lesen! Vielen Dank für Ihren Beitrag. Dennoch möchte ich hinzufügen, dass TDD genau wie XP (extreme Programmierung) ein weiterer Ansatz ist. Und ja, Scrum bietet keine spezielle Methode für Fehler an und investiert eher in die Selbstorganisation des Teams (der Entwickler). Scrum sagt Ihnen nicht, wie Sie etwas tun sollen, es sagt nur, was zu tun ist. Es ist die Verpflichtung des Teams, alles zu durchlaufen, was getan werden muss. Scrum setzt nur auf selbstorganisierte funktionsübergreifende Teams. Es ist das Team, das entscheidet, wie Features entwickelt und getestet werden sollen, usw.
Will Marcouiller

(weiter ...) Ich habe diese Woche meine erste Frage zum Unterricht hier auf GD beantwortet. Das OP wollte wissen, wie man sein Sprite durch Drücken von Richtungstasten zum Bewegen bringt. Da ich mit OOP-Konzepten vertraut war, fand ich heraus, dass ich vielleicht Klassen verwenden sollte, um mein erstes Spiel mit XNA zu entwickeln. Das heißt, meine SpacecraftKlasse wird eine vollständig testbare Klasse mit Methoden und Eigenschaften. Dies ist die Art von Sachen, die meiner Meinung nach mit TDD vollständig getestet werden können. Nehmen wir an, Sie brauchen ein Raumschiff und schreiben dann die Tests für das, was Sie benötigen, um jeweils einen Test durchzuführen.
Will Marcouiller

4

Entschuldigung für mein schlechtes Englisch und Entschuldigung für meinen voreingenommenen Standpunkt: Ich bin kein Spieledesigner, sondern ein Programmierer.

Ich denke, in dieser Diskussion gibt es einige Missverständnisse. Ich werde über TDD in allgemeinerer Form sprechen, die so genannte BDD. Verhaltensorientierte Entwicklung ist keine Möglichkeit, ein Projekt zu testen (die Tests sind so etwas wie Nebenwirkungen). BDD ist eine Methode zum Entwerfen , eine Methode zum Umgestalten und zum Entwerfen von Software während der gesamten Produktion (siehe einige Mottos als KISS, "Qualität behalten in", "früh testen, oft testen") und nicht in einer einzelnen Phase. BDD ist das Gegenteil eines klassischen Softwareprozesses wie eines Wasserfallprozesses oder einer anderen iterativen Methode zur Erstellung von Software.

Ein weiterer Punkt ist, dass automatische Tests für die Funktionen vorgesehen sind, die von einer Rechenmaschine automatisch getestet werden könnten. Es gibt keinen Test für Spielspaß und es gibt keinen Test für die Benutzerfreundlichkeit einer grafischen Benutzeroberfläche. spaß oder benutzerfreundlichkeit sind materialien für andere aufgaben und nicht für die softwareentwicklung wie interaktionsdesigner, world und level d. Genauso wie künstlerische Teile (Modellieren, Texturieren usw.) für Künstler sind, die Computer als Werkzeug für Kreativität verwenden - offensichtlich könnten diese Arbeiten von derselben Person ausgeführt werden, die Code schreibt, aber das ist nicht der Punkt. Physik konnte getestet werden, Optimierungsalgorithmen konnten getestet werden, Verhalten einzelner Objekte konnte getestet werden (mit Mocks, Stubs und Dummy, wie zuvor erwähnt)

Der letzte Gedanke ist, imho, dass nicht nur das Game-Design, sondern der gesamte Code eine Kunst ist.


4

Hier ist eine Fallstudie von jemandem, der der Meinung ist, dass TDD und Gamedev gut zusammenpassen:

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

Zugegeben, dies ist ein kleines Projekt in Pygame, aber es gibt die Idee, welche Teile mit einem Grafikspiel getestet werden können und welche nicht. Ich war überrascht, wie viel mit TDD in diesem Szenario getan werden konnte.


1
Ohne einen Vergleich mit einer Kontrollgruppe, die dasselbe Projekt durchgeführt hat (Klonen eines vorhandenen einfachen Arcade-Spiels in einer sehr hohen Sprache), sagt dies nichts darüber aus, ob TDD effektiv ist oder nicht. Es heißt nur, dass er TDD verwendet hat.

3

Nein, Test Driven Development ist nicht für die Spieleentwicklung geeignet. Natürlich können Sie Tests für einige Teile schreiben, die Sie testen möchten, aber der Spieleentwicklungsprozess unterscheidet sich grundlegend von der testgetriebenen Entwicklung, für die genaue Spezifikationen erforderlich sind, bevor der Fortschritt gestartet werden kann.

Spiele haben selten genaue Spezifikationen, wenn sie gestartet werden. Und wenn doch, verändern und entwickeln sie sich während des Entwicklungsprozesses.

Game Design ist eine Kunst, man kann keine spezifischen Tests machen, um zu wissen, ob Kunst gut oder vollständig ist.


Denken Sie nicht, dass der Spaßfaktor bei der Analyse des Spiels selbst, der Funktionsanalyse oder dergleichen berücksichtigt werden sollte? Sie können eine Reihe von Funktionen einrichten, mit denen das Spiel Spaß macht, und diese Funktionen sind dann testbar! Ich versuche nur, unterschiedliche Meinungen vorzubringen, um das Thema und die von Ihnen vorgebrachten Argumente zu vertiefen. Vielen Dank für Ihren Beitrag! =)
Will Marcouiller

3
Viel Entwicklung hängt davon ab, kleine Dinge zu optimieren und zu sehen, wie viel Spaß es macht, sie zu spielen. Sie können diese Dinge nur testen, wenn sie zu 100% in Stein gemeißelt sind. Das Testen eines Systems nach dessen Abschluss ist kein TDD-Test, sondern ein Test, der sich auf die Entwicklung stützt.
AttackingHobo

2
Wenn Sie der Meinung sind, dass die meisten realen Projekte zu Beginn genaue Spezifikationen haben, haben Sie wahrscheinlich nicht an vielen realen Projekten gearbeitet.
BlueRaja - Danny Pflughoeft
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.