Automatisiertes Testen von Spielen [geschlossen]

Gibt es Methoden zum automatisierten Testen von Spielen?

Spezifische Erfahrungen mit relevanten Informationen über das Projekt wie Plattform und Spieltyp werden geschätzt, wenn dies zur Klärung beiträgt.

Ein-Personen-unabhängiges Spiel. Es war ein Multiplayer-Panzerspiel mit zerstörbarem Gelände, und das zerstörbare Gelände und der Kollisionscode erwiesen sich als etwas unzuverlässig.

Es endete damit, dass ich einige einfache blöde KIs zusammenstellte (mit "blöd" meine ich "absolut idiotisch" - sie wählten zufällig "auf einen feindlichen Panzer zufahren", "von einem feindlichen Panzer wegfahren" und "in eine zufällige Richtung fahren" ", während zufällig die Hauptwaffe abgefeuert wird) und das Spiel mit maximaler Framerate gespielt wird, während Tastendrücke aufgezeichnet werden. Ich habe ungefähr 10-15x Echtzeit. Der Code war stark behauptet, und wenn etwas schief ging, wurde das gesamte Tastendruckprotokoll zusammen mit einem Fehlerbericht und dem anfänglichen zufälligen Startwert auf die Festplatte geschrieben. Ich könnte dann das Tastendruckprotokoll wiederholen, um den Status genau zu duplizieren, oder einfach über den Fehlerbericht debuggen.

Ich ließ es buchstäblich Monate lang ununterbrochen laufen. Am Anfang würde es selten eine Stunde dauern, ohne zusammenzubrechen - ich musste eine Woche dort sitzen und es babysitten und mehrere dunkle Käfer pro Tag töten. Irgendwann war es so weit, dass es zwischen zwei Ausfällen eine Woche lang lief, was ungefähr 1500 Spielerstunden pro Absturz entspricht.

Es war von unschätzbarem Wert und ich kann es nur empfehlen.

Für ein MMO, an dem ich gearbeitet habe (100 Entwickler, PC-orientiert), haben wir versucht, eine Vielzahl automatisierter Tests mit unterschiedlichem Erfolg hinzuzufügen. Folgendes hat funktioniert:

• Grundlegende Tests während unseres automatisierten Erstellungsprozesses waren ein enormer Gewinn. Dies beinhaltete Aufgaben wie das Erstellen eines Charakters, das Übertragen von Maps, das Ausführen einiger skriptfähiger UI-Tests und das Suchen nach dem erwarteten Verhalten. Dies hat eine große Anzahl von Fehlern aufgefangen, bevor sie tatsächlich den Rest der Firma erreichten.
• Auf der Seite der Serverinfrastruktur haben wir eine Reihe verschiedener automatisierter Tests entwickelt, die typische MMO-Servertransaktionen simulieren. Wir könnten diese dann unter verschiedenen Umständen abspielen, um die Leistung zu vergleichen oder die Sicherheit zu gewährleisten. Im Laufe der Zeit wurden diese Tests immer genauer, bis sie sich in eine Wiedergabe von live aufgezeichneten Daten verwandelten
• Wir haben einen "Fake-Player" geschrieben, der zufällig um die Welt streift, springt, Dinge tötet und im Chat zufällige Dinge sagt. Dies führte zu einer Vielzahl von physikalischen und infrastrukturellen Problemen.

Was hat nicht funktioniert:

• Wir haben versucht, dem automatischen Builder einige sehr spezifische kampforientierte automatisierte Tests hinzuzufügen, aber das hat im Grunde nie funktioniert. Es würde ungefähr 3 Tage nach der Implementierung funktionieren, bis ein Designer oder Künstler etwas änderte und der Test fehlschlug und die fehlgeschlagenen Build-Alarme auslöste. In 90% der Fälle war dies kein wirkliches Problem. Diese Tests waren zu zerbrechlich, und das Testen eines bestimmten Gameplays auf einer bestimmten Karte mit bestimmten Fähigkeiten ist möglicherweise nicht mehr möglich
• Wir haben versucht, einen automatisierten Leistungstest zu implementieren, bei dem die Clientleistung (durchschnittliche FPS usw.) mit der aufgezeichneten Leistung von vor einer Woche verglichen wird. Dies war auch ziemlich fragil, da die Demos, die wir dafür verwendeten, häufig verrotteten und es schwierig war festzustellen, ob eine Verlangsamung durch einen tatsächlichen Leistungsverlust oder einen Nebeneffekt des Testprozesses verursacht wurde.

Die Arbeit an einem 4x-Strategiespiel mit 3D-Kampf (denke, Homeworld trifft Masters Of Orion), das leider nie das Licht der Welt erblickte, da die Firma keine finanziellen Mittel mehr hatte.

Ich habe immer dafür gesorgt, dass Sie das Spiel ohne menschliche Spieler spielen können, damit wir das Spiel über Nacht laufen lassen können.

Wir konnten den 3D-Kampf ausschalten (vereinfacht zu einem zufälligen Ergebnis) und die KI-Strategie-Engine selbst spielen lassen. Dies fand zahlreiche Fehler und Probleme. Es werden nicht nur Stopper-Bugs angezeigt, sondern auch Strategie-Bugs, bei denen die (z. B.) KI-Strategien blockieren und Tausende von Runden damit verbringen würden, nicht "das Richtige" zu tun. Diese Art von Fehlern war schwer zu erkennen, nur "das Spiel spielen".

Bei einem Ego-Shooter, an dem ich gearbeitet habe (Descent 3 - Linux / Mac / Windows, ~ 30 Mitarbeiter im Team im Jahr 1999), erwies sich die Demo-Aufnahme- / Wiedergabe-Funktion als äußerst nützlich. Ich habe eine Option entwickelt, mit der Sie die Demo so schnell abspielen können, wie das Spiel Frames rendern kann, und auf diese Weise können Sie die Leistung überprüfen, nachdem sich einige Dinge geändert haben.

Es wurde auch ein Großteil des Codes außerhalb des Rendering-Systems ausgeführt, so dass es eine nette Überprüfung der geistigen Gesundheit war. Nachdem ich einige Änderungen vorgenommen hatte, konnte ich einfach die Demo-Wiedergabe von 10 Minuten Gameplay starten. Oft wurde ein Fehler in einem Bereich entdeckt, an dem ich nicht gedacht hätte, mich selbst zu überprüfen.

Wir hatten einen OpenWorld-Shooter (x360, PS3, PC), der einen schnellen Smoketest auf dem Build-Server verwendete - er lud das Spiel, trat durch das Front-End, rannte [den Avatar] vor, erstellte einen Screenshot und beendete das Spiel. Wenn cctray den Clean-Exit feststellte, war der Build ein Erfolg.

Wir haben es für ungefähr das letzte Jahr des Projekts und mit einer Teamgröße von ~ 100 Entwicklern durchgeführt.

Es war effektiv, um Showstop-Bugs zu erkennen, aber es war einfach, einen Build zu erstellen, der den Smoketest bestand, aber die meisten "echten" Levels nicht bestand, oder im Mehrspielermodus nicht funktionierte oder die KI überholte, so dass es nicht perfekt war. Es hat sich auf jeden Fall gelohnt.

Ich habe gehört, seit ich weg bin, dass sie angefangen haben, eine größere Anzahl von Smoketests durchzuführen, die auf mehrere PCs verteilt wurden. Offenbar ist die Wartung der Smoketests ein Problem, und es gibt ein kleines Team, das sich nur um die Wartung der Build-Server und der Software kümmert. Ich kann also nicht sagen, ob dies ein Erfolg war oder nicht.

Meine Erfahrungen mit automatisierten Tests während der Entwicklung von Crysis 2 finden Sie hier: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Zusammenfassung:

• Durch automatisierte Tests wurde die Stabilität der zu liefernden Daten verbessert und die Produktivität sowohl für Inhaltsersteller als auch für Ingenieure erhöht
• Automatisiertes Testen ist ein effektives Tool zur Verbesserung der Codequalität und zur Verringerung der Wahrscheinlichkeit, dass Überstunden anfallen
• Die Spieleindustrie als Ganzes ist im Allgemeinen sehr reaktionär, automatisierte Tests stoßen auf mehrere irrationale Argumente
• Nennen Sie es nicht Testen, nennen Sie es etwas anderes, fast alles andere (siehe Verhaltensorientierte Entwicklung).
• Seien Sie flexibel, gute Tests zu schreiben ist schwierig und erfordert Fähigkeiten, die in der Spielebranche nicht weit verbreitet sind

Die Spieleentwicklung ist einer der Fälle, in denen Unit-Tests für mich einen Sinn ergeben, weil die Wechselwirkungen zwischen diskreten Systemen so häufig sind. Design-by-Contract ist natürlich ein Teil davon und sollte ab dem ersten Tag der Entwicklung geplant werden, aber ich verstehe nicht, warum es später nicht implementiert werden konnte, vorausgesetzt, dass das Nötigste dazu vorhanden ist.

Der schwierige Teil ist natürlich das Testen der Integration. Viele Spiele können durch einfaches Demo-Looping oder ähnliches getestet werden, aber dieses Zeug ist konzeptionell relativ einfach zu debuggen. Ich würde mich mehr dafür interessieren, meine Zeit damit zu verbringen, Fehler aufzudecken, die auftreten, wenn ein Spieler etwas tut. Wenn man bedenkt, dass ein Fehler, den der Spieler niemals sieht, offensichtlich weniger wichtig ist als ein Fehler, den der Spieler tut.

Das ist natürlich ziemlich schwierig. Taktiken, die in anderen Anwendungen funktionieren (Fuzzing, Expected-Pass / Expected-Fail usw.), funktionieren hier nicht so gut. In skriptfähigen Systemen scheint es der richtige Weg zu sein, einen Testsatz von Skripten zu erstellen, um einen Player zu simulieren (siehe JZigs Antwort). Das Testen von Dingen, die einem Spieler direkt begegnen, scheint mir jedoch der beste Ort zu sein, um Ihre Zeit auf menschliche und automatisierte Testzwecke zu konzentrieren.