Ist das Testen von Software anders, wenn es um die Entwicklung von Spielen geht?

Ich habe dieses Papier über die Unterschiede zwischen Softwareentwicklung im Allgemeinen und Spieleentwicklung gelesen, und die Autoren haben einige gute Punkte in Bezug auf Softwaretests hervorgehoben und zum Beispiel darauf hingewiesen

... Spieleentwickler zögern, automatisierte Tests zu verwenden, da diese Tests angesichts sich verändernder kreativer Wünsche von Spieledesignern schnell veraltet sind.

Diese Lektüre hat mich zum Nachdenken gebracht, welche anderen Aspekte beim Testen von Software sollten wir als anders oder besonders betrachten, wenn wir uns mit einem Spiel befassen / es testen? Hat jemand Erfahrung damit oder hat jemand etwas anderes davon gehört?

Moderne Spiele sind eine Menge kreativer Kunstinhalte, die mit einer internen oder proprietären Spiel-Engine entwickelt wurden. Die Engine selbst ist größtenteils einheitstestbar (Rendering, Geometrie, Physik, AI-Module usw.). In ähnlicher Weise können einfache Tests auch an einzelne Teile des entwickelten Inhalts angehängt werden. Dies bedeutet, dass Unit- und White-Box-Tests in der Tat machbar und erfolgreich sind.

Für "Produkt als Ganzes" ist ein Spiel eine Simulation. Es könnte generativ komplexer sein als ein einfaches Geschäftsprogramm. Denken Sie an endlose, einzigartige, prozedural erzeugte Welten im Vergleich zu einem Unternehmensressourcenplaner mit zählbaren, gut geplanten Verhaltensweisen. Einfach ausgedrückt, die Anzahl der möglichen einzigartigen Möglichkeiten, etwas im Zusammenhang mit Spielen zu tun, kann mathematisch sehr, sehr, sehr groß sein. In der Tat wird es als Verkaufsargument für Spiele angesehen.

Hinzu kommt, dass die Endausgabe rein audiovisuell ist und es keinen deterministischen Standard für die absolute Korrektheit dieser Ausgabe gibt. GPU-Chips müssen wirklich keine präzisen Berechnungen durchführen, nur viele Berechnungen, auch wenn einige nicht präzise sind.

Und schließlich ist das Hauptziel Unterhaltung . Spieler sind mit Pannen einverstanden, wenn sie über 60 FPS laufen, fantastisch aussehen und endlose Stunden unterhaltsamen Inhalts haben.

Dies versetzt die traditionellen Ideen für automatisierte Black-Box-Tests einfach in die Region "nicht so greifbar und es lohnt sich", wenn sie auf Spiele angewendet werden.

In jüngster Zeit gab es jedoch Versuche, NNs für das Spielen von Spielen zu trainieren , was effektiv eine Form des explorativen, selbstlernenden Affentests ist.

Es ist viele Jahre her, seit ich Gamedev gemacht habe, aber zusätzlich zu der netten Antwort gibt es einige Dinge, die ich hinzufügen und detaillieren möchte.

Zunächst wurde bereits erwähnt, dass die Ausgabe nur visuell und akustisch gegen strenge "FPS-kritische" Einschränkungen und Rechen- / Speicherbudgets ist. Ideen zur Korrektheit verschwimmen, wenn die Fragen eher lauten: "Sieht es gut aus? Läuft es reibungslos ohne Stottern? Klingt es großartig?" Während Entwickler optimieren und optimieren und sich annähern, während Designer / Entwickler-Kollaborationen dazu führen, dass die Dinge bei jeder schnellen Iteration etwas anders aussehen und klingen.

Eine andere ist, dass die Tester großartig sein können! Ich habe in keiner anderen Domäne eine engagiertere Gruppe von Testern gefunden, da sie dies wünschenum die Software zu testen. Sie haben Spaß. Sie sind süchtig und schlafen neben dem Computer, während sie jeden Winkel Ihres Spiels erkunden. Es wird ziemlich einfach, selbst die dunkelsten Störungen zu entdecken, wenn die Leute tatsächlich unterhalten werden, jede Ecke der Software gründlich zu testen, während sie praktisch süchtig danach sind. In meiner derzeitigen Branche ist es etwas schwieriger, mit den Testern zu arbeiten, da viele von ihnen Profis sind, die ihren Lebensunterhalt mit der Software verknüpfen. Daher verlassen sie sich auf eine Handvoll Funktionen, um ihre Arbeit zu erledigen, und sind nicht unbedingt an Erschöpfung interessiert Jeder Winkel und jede Ecke die ganze Zeit. Wenn wir uns nicht so stark auf menschliche Tester verlassen können, brauchen wir natürlich mehr automatisierte Tests.

Ein weiterer Grund ist, dass die Codebasis für ein Spiel normalerweise nicht über Jahre hinweg gepflegt, modifiziert und erweitert wird. Es ist nicht so, dass die Entwickler von Super Mario, die es ursprünglich in der 6502-Assembly entwickelt haben, lange nach dem Versand des Spiels etwas beibehalten mussten, das dem ursprünglichen Code ähnelt. Doom 3 verwendet wahrscheinlich keine Codezeilen (oder schließen) aus Doom 1. Wenn es ein fortlaufendes Franchise gibt, sind die neueren Spiele eher "Fortsetzungen" als "Upgrades". Die meisten Spiele werden nur ausgeliefert und veröffentlichen möglicherweise einige Patches, DLCs, und dann ist der Code fertig. Das ist ein großer Kontrast zu meiner VFX-Branche, in der ich an der Pflege von Code aus Amiga-Tagen gearbeitet habe, der seit Jahrzehnten portiert und gepflegt wurde. Spiele normalerweise nicht

Einer der Gründe für diese kurzlebige Natur der Spielcodebasen ist, dass sie so stark an die Hardware gebunden sind. In Kombination mit ihren neuesten und FPS-kritischen Anforderungen können sie oft nicht so entwickelt werden, dass Hardwaredetails abstrahiert werden, auch nicht in der Nähe. Sie sind oft sehr speziell für die Zielgenerierung von Hardware geschrieben, und es dauert normalerweise nicht lange, bis die PS3 durch eine PS4 ersetzt wird, die dann veraltet und durch eine PS5 ersetzt wird, und so weiter, und das alles sehr schnell. Die Hardwarefunktionen spielen beim Design und der Entwicklung des Spiels eine so entscheidende Rolle, dass es sich im Allgemeinen nicht lohnt, den gleichen Code für PSX wie für PS4 beizubehalten, z. B. die meisten Spiele-Franchise-Unternehmen, die über Generationen hinweg bestehen, schreiben immer noch ihre Engines der nächsten Generation weitgehend von Grund auf für die neueste Hardware.

Mit einer kurzlebigen Codebasis geht eine begrenzte Wartungszeit einher (dh eine begrenzte Zeit, in der der Code geändert werden muss). Mit einer begrenzten Zeit für die Änderung des Codes, die sich nicht über Jahre erstreckt und deren Umfang mit jedem Upgrade größer und größer wird, und der Tatsache, dass Spiele nicht annähernd geschäftskritisch sind, gibt es keine solche Kritische Notwendigkeit, die umfassendsten Unit- und Integrationstests durchzuführen. Dies hat keinen Vorteil darin, die Integrität zukünftiger Änderungen sicherzustellen, wenn zukünftige Änderungen nicht vorgenommen werden, und der Aspekt des Unit-Testens und Refactorings von Legacy-Codebasen ist natürlich irrelevant, wenn es überhaupt kein "Legacy" gibt.

Ein weiteres kleines Problem, das nicht immer relevant ist, ist, dass ein Spiel möglicherweise nur auf einen sehr engen Bereich von Hardware ohne Desktop-Ports abzielt. In diesen Fällen wird eine große Quelle unvorhersehbarer Störungen in diesen Kontexten beseitigt, nämlich Benutzer, die die Software mit radikal unterschiedlicher Hardware und Treiber ausführen.

Das heißt, Integrationstests auf der höchsten / gröbsten Ebene sind in der Regel sofort nützlicher. Beispielsweise können viele Spiele eine Möglichkeit verwenden, um aufzuzeichnen, wie sich der Spielstatus im Laufe der Zeit für "Wiederholungen" ändert. Solche Wiedergabefunktionen können sicherstellen, dass das Spiel deterministisch ist, und können auch als eigenständiges Testwerkzeug verwendet werden, um eine zuvor von einer anderen Person aufgezeichnete Spielsitzung wiederzugeben.

Ich habe auch Gamedevs getroffen, die in kleinen Studios gearbeitet haben und Dinge wie das Schreiben von Bots für ihr Spiel gemacht haben und die Bots ihr Spiel mit maximaler Geschwindigkeit spielen ließen und diese Simulation ausgeführt haben. Ursprünglich stieß sie nach ein oder zwei Tagen auf einen obskuren Absturz und reparierte ihn dann führte die Simulation erneut aus und wiederholte sie, bis es auch nach wochenlangem Ausführen keine Show-Stop-Abstürze mehr gab. Es gibt also interessante pragmatische Ansätze wie die, die ich von Gamedevs zum Testen ihrer Software gesehen habe, aber oft auf eine Weise, die der gröbsten Stufe von Integrationstests ähnelt und die Dinge sehr genau simuliert, wie die Spieler tatsächlich mit dem Spiel interagieren.

Schließlich ähneln diese großen AAA-Game-Engines einer ganz anderen Art von Biest: Langlebiger, erfolgreichere Abstraktion der Hardware ein wenig besser, mit größeren Codebasen und längeren Wartungsspannen, während ihre Level-Editoren anfangen, vollständigen Entwicklungsumgebungen zu ähneln. Ich kann mir vorstellen, dass diese großen Motoren wahrscheinlich ein gründlicheres Testverfahren erfordern würden, insbesondere wenn die Zeit, in der ihr Code gewartet wird, erheblich länger wird. Trotzdem schreiben viele Spielestudios keine großen AAA-Game-Engines: Sie lizenzieren sie entweder oder entwickeln eine kleine proprietäre Engine, deren Umfang erheblich kleiner ist und die jahrelang nicht gewartet wird.