In letzter Zeit habe ich mich viel mit agilen Methoden beschäftigt. Einige Papiere, die ich auf Martin Fowlers Website gelesen habe, sahen für mich, gelinde gesagt, ziemlich fehlerfrei aus, und ich habe mich gefragt, welche agilen Methoden sich am besten für die Spieleentwicklung eignen, insbesondere für Projekte mit kleinem Budget, kleinen und unerfahrenen Teams (fett gedruckt, weil es wirklich wichtig ist).
Konzepte wie Refactoring sehen so aus, als könnten sie durchaus mit einem kleinen und unerfahrenen Team kombiniert werden. Die Idee des "Umarmens des Wandels" passt auch zu unerfahrenen Teams, deren Ideen sich ständig drehen und wenden. Aber Dinge wie TDD sind eher problematisch.
Es ist schwierig und suboptimal, eine Klasse zu testen, die z. B. mit Direct3D interagiert. Das macht nicht viel Sinn.
Ich wäre Ihnen sehr dankbar, wenn Sie eine Reihe von Praktiken auflisten könnten, die für die Spieleentwicklung sinnvoll sind. Solche, die bei der Organisation der künstlerischen Produktion helfen, sind ein Plus. Zitate aus der Praxis sind ein weiteres Plus.
Vielen Dank im Voraus.
bearbeiten --
Außerdem besteht mein Team aus drei Personen: einem Programmierer, einem Grafikdesigner und einem Programmierer/Grafikdesigner-Mix. Wir machen no Wir haben einen Kunden, also müssen wir alle Entscheidungen allein treffen.
Ich habe in einem Artikel von Fowler gelesen, dass Agilität in gewisser Weise von der Interaktion zwischen Entwickler und Kunde abhängt, aber er erwähnte auch, dass Kunden, die nicht bereit sind, sich an Agilität zu halten, trotzdem gut mit agiler Entwicklung bedient werden können (der Artikel hieß Neue Methodik ). Was bedeutet das für meinen Fall?
Schlussfolgerungen --
Ich denke, dass Fragen auf StackOverflow auch anderen helfen können, daher werde ich versuchen, meine Gedanken zu diesem Thema hier zusammenzufassen.
-
Durch die Verwendung von Mock-Objekten können auch schwer zu testende Elemente wie Grafikschnittstellen und ihre Beziehung zu Client-Klassen verwaltet werden.
Anstatt z. B. jeden Client der Schnittstelle unter vielen Bedingungen (z. B. Umschaltung zwischen Vollbild- und Fenstermodus, was sich auf fast alles im Spiel auswirkt) wirklich zu testen, könnten sie gegen eine Attrappe getestet werden, die sich anscheinend genauso verhält wie die Originalklasse, und zusätzlich die Treue dieser Attrappe zum Originalobjekt testen.
Auf diese Weise wird der langsame Teil (das tatsächliche Öffnen des Fensters und so weiter) nur einmal durchgeführt, um zu prüfen, ob das Mock der Implementierung entspricht, und alles andere läuft reibungslos über das Mock. [Dank an Cameron ]
-
A BDD-Mentalität hilft dabei, das paranoide Streben nach gründlichem Testen von Einheiten zu erleichtern, indem Tests durch die Spezifikation des tatsächlichen Verhaltens "ersetzt" werden, nicht durch gequetschte Einheiten, die in vielen Fällen besser ungetestet bleiben (oder nur indirekt getestet werden, wenn Sie es so ausdrücken wollen), um eine zu große Eins-zu-eins-Parität zwischen Test und Einheit (Klasse, Methode, Variable usw.) zu vermeiden, die die Anfälligkeit von Tests (jetzt "Spezifikation") erhöht. [Dank an Kludge ]
