Get best of the week

Testen der Amazon Lumberyard Game Engine. Ansätze und Tools

Amazonas Spiele. Klingt ungewöhnlich? Wie teste ich das Produkt für Entwickler und Gamer? Unter dem Cut-Test der Amazon Lumberyard-Game-Engine werden sowohl manuelle Tests als auch Automatisierung sowie die für das Projekt verwendeten Tools beschrieben.



Lumberyard ist eine plattformübergreifende Spiele-Engine, mit der Sie Spiele für die meisten modernen Plattformen kostenlos erstellen können: PC, Mac, iOS / Android, alle Konsolen, einschließlich Virtual-Reality-Brillen. Es ist auch ziemlich tief in Amazon Web Services und Twitch's Game Broadcast Service integriert.

Unter dem Schnitt - Video und Transkript des Berichts von Artem Nesiolovsky von der Heisenbug- Konferenz .




Über den Redner: Absolvent des Moskauer Instituts für Ingenieurphysik, Fakultät für Kybernetik, mehr als 8 Jahre in Entwicklung und Test. Er arbeitete sowohl an Desktop-Projekten wie der GeForce Experience, dem Online-MMORPG Lineage II und im mobilen Spiel Cut the Rope als auch am Webprojekt Yandex.Images. Derzeit ist er Automatisierungsingenieur bei Amazon im Rahmen des Amazon Lumberyard-Projekts.

Pfostenstruktur


  • Game Engine: Funktionen sowie Unterschiede zwischen dem Testen der Engine und dem Testen von Spielen.
  • Manuelles Testen: Wie wir versucht haben, die Abdeckung der Merkmale des Projekts mit Funktionstests herauszufinden.
  • Automatisierung: Fehler und Unebenheiten, die wir gefüllt und anschließend behandelt haben.
  • Werkzeuge, mit denen wir unseren Motor automatisieren.
  • Interessante Fehler aus unserem Projekt, die Sie wahrscheinlich kennengelernt haben, als Sie selbst Spiele gespielt haben.


Weitere Erzählung im Namen des Sprechers.



Warum macht Amazon überhaupt Spiele? Im Jahr 2014 stellt Amazon wie viele Technologie-Giganten fest, dass Spiele zur zweitbeliebtesten Form der Unterhaltung für die Menschheit werden. Das erste ist seltsamerweise das Fernsehen oder vielmehr alles, was mit Video-Streaming zu tun hat (YouTube, Netflix und alles andere). Spieleentwickler beginnen auch, AWS-Dienste für ihre Online-Spiele aktiver zu nutzen.

Amazon beschließt, ein Ökosystem auf drei Säulen aufzubauen: Öffnen Sie sein Spielestudio, um Spiele zu erstellen, die die Leute dann auf Twitch streamen und ansehen. Diese Spiele zeigen auch, welche interessanten Spielideen mit AWS Cloud umgesetzt werden können.

Wie hat alles angefangen?


Im Jahr 2004 veröffentlichte die deutsche Firma Crytek ein Spiel namens "FarCry". Nach einiger Zeit beginnt Crytek mit der Lizenzierung seiner Engine, auf der das Spiel basiert, so dass Drittanbieter die fertige Engine verwenden und mit der Erstellung eines Spiels und Gameplays beginnen können, ohne große Investitionen in Technologie. Als Amazon anfing, Spiele zu spielen, eröffnete es sofort mehrere Studios und begann, mehrere Spiele zu entwickeln.

Damit nicht jedes Studio ein Fahrrad erfindet - seine eigene Rendering-Engine, sein Animationssystem, seine Physik usw. - lizenziert Amazon CryEngine Version 3 und startet die Entwicklung mehrerer Spiele gleichzeitig. Die Grand Tour wurde bereits auf Xbox und PlayStation veröffentlicht. Zwei weitere befinden sich in der Entwicklung: das MMORPG "New World" und der Online-Shooter "Crucible". Nachdem die Entwicklung dieser Spiele begonnen hat, stellt Amazon die Engine, auf der diese Spiele entwickelt werden, kostenlos zur Verfügung. Da es stark in die Cloud-Dienste von Amazon integriert ist, können Sie mehr Benutzer für die Verwendung von AWS gewinnen.



Eine Spiel-Engine ist eine Reihe von APIs, eine Spiel-Engine zum Erstellen eines zukünftigen Spiels. Damit Entwickler keine eigenen Spielesysteme schreiben müssen, können Sie einfach eine Reihe von APIs verwenden, d. H. Engine, und fangen Sie an, Ihre eigene Spielelogik zu schreiben, fügen Sie dort Inhalte hinzu und engagieren Sie sich für Kreativität, anstatt Technologie von Grund auf neu zu entwickeln. Einige Engines haben auch einen Editor. Dies ist ein Desktop-Programm, mit dem Sie Levels erstellen, dh Ihr Level öffnen und dort Inhalte und Spielelogik hinzufügen können.

Anstatt lange zu reden, ist es manchmal einfacher, ein Video zu zeigen:

Link zu Video 8: 33-9: 53

Hier ist unser Editor und seine Oberfläche. Darin wird ein Spiel gestartet, das wir zusammen mit der Engine bereitstellen. "Starter Game" gibt es, damit sich Leute anmelden, spielen, etwas ändern und herausfinden können, wie es funktioniert.

Im Allgemeinen können sich 3D-Spiele als eine Reihe dreidimensionaler Objekte vorstellen, die sich in einer dreidimensionalen Welt bewegen und irgendwie miteinander interagieren. In diesem Video können Sie sehen:

  • statische Geometrie mit Texturen: Erde, Steine, Gras, Bäume;
  • dynamische Geometrie - der Charakter ist animiert, reagiert auf die Aktionen des Spielers;
  • Benutzeroberfläche: Aufgabenansichten in der oberen linken Ecke.

Der Spieler kann sich mit feindlichen Charakteren treffen, die Spielelogik wird angezeigt, es wird möglich sein zu schießen - Roboter schießen als Reaktion. Über die Physik: Der Charakter beginnt mit dem Schießen auf Fässer, bewegt sich von Kollisionen mit Schüssen und von der Interaktion mit dem Charakter. Im Editor können Sie den Spielemodus jederzeit verlassen und in den Bearbeitungsmodus zurückkehren, in dem Sie die Eigenschaften von Objekten sofort ändern und verschieben können. Dies wird sofort im Spiel angezeigt. Stellen Sie sich eine ungefähre Anzahl von Stellen vor, an denen etwas schief gehen, zusammenbrechen und nicht mehr richtig funktionieren könnte?

Wie teste ich den Motor?


Das Testen des Motors basiert auf drei Hauptpunkten. Das erste ist das Testen des Editors und der Tools: die korrekte Operation, die Tools sollten geöffnet werden, nichts zum Absturz bringen, alles sollte korrekt angezeigt werden, Benutzerskripte sollten fehlerfrei ausgeführt werden, der Prozess des Erstellens eines Spiels ohne begleitende Fehler. Nur Spieleentwickler verwenden den Editor. Die zweite ist das Testen der Engine selbst oder der Engine-API. Die Spiel-Engine ist wiederum der Teil des Codes, der auch auf den Computern der Spieler funktioniert. Dieser Teil des Projekts wird durch die vorherige Erstellung von Levels und Spielen getestet. Anschließend können die erstellten Levels bei jedem neuen Build der Engine getestet werden, um sicherzustellen, dass alle auf dem einen oder anderen Level verwendeten Spielelemente ordnungsgemäß funktionieren.Die dritte Komponente ist das Testen der Infrastruktur und der Kompatibilität: Die Engine kann mit verschiedenen Parametern konfiguriert und erstellt werden, das Spiel kann auf verschiedenen Geräten bereitgestellt werden und es wird fast überall gleich aussehen und funktionieren.
Features des Projekts

Das erste Feature - wir unterstützen die meisten vorhandenen Gaming-Plattformen. Trotz der Tatsache, dass der Editor selbst nur auf dem PC arbeitet, ist die Laufzeit, d.h. Das Spiel kann auf Mac, Smartphones, Konsolen und sogar Virtual-Reality-Brillen aufgebaut werden.

Die zweite Funktion - unsere Benutzer - sind zwei Arten von Personen mit völlig unterschiedlichen Anforderungen. Einerseits sind dies Entwickler, Programmierer, Künstler und Designer, die an der Erstellung des Spiels arbeiten werden. Auf der anderen Seite sind dies Spieler, auf deren Maschinen das Spiel dann funktioniert. Die Anforderungen für diese beiden Gruppen sind völlig unterschiedlich.

Die dritte Funktion - in solchen Programmen, mit denen Sie etwas Neues erstellen können, wird im Voraus eine möglichst breite Palette möglicher Produkte dieser Anwendung impliziert. Auf unserer Engine können Sie absolut jedes Spiel erstellen, angefangen bei etwas Einfachem wie Tetris bis hin zu einem komplexen Online-Projekt, das von Tausenden von Menschen gleichzeitig gespielt wird.

Alle drei Funktionen wirken sich stark auf die Anzahl der benutzerdefinierten Skripts aus, von denen jedes getestet werden muss.



Schauen Sie sich diesen Screenshot an und stellen Sie sich vor, wie viele Testfälle Sie nur für diesen Teil der Funktionalität schreiben könnten. Insgesamt haben wir mehr als 11.000 Testfälle im Projekt und diese Datenbank wächst jedes Jahr um etwa 3-4.000 Testfälle.

Link zum Video 13: 20-13: 54

Wir finden die meisten Fehler bei der Interaktion mehrerer Komponenten miteinander. In diesem Video wird Schnee im Normalzustand wie gewünscht auf dem Würfel angezeigt. Sobald der Charakter jedoch mit ihm zu interagieren beginnt, verschwindet der Schnee. Die meisten Fehler, die wir finden, befinden sich an solchen Stellen, an denen sich mehrere Komponenten verbinden.

Link zum Video 14: 08-14: 41

Fehler treten jedoch nicht immer auf, wenn nur zwei Bedingungen vorliegen. Es kommt häufig vor, dass Fehler auftreten, wenn mehrere Komponenten gleichzeitig konvergieren. In diesem Fall betrachten wir einen Fehler, bei dem der Charakter in einer normalen Situation einfach auf dem Boden steht. Es lohnt sich, einen weiteren Freiheitsgrad hinzuzufügen - um den Charakter über den Boden zu heben: Wenn er fällt, beginnt die Animation zu spielen und die Kamera nähert sich / bewegt sich weg - die Textur beginnt zu verschwinden. Hier interagieren drei Komponenten gleichzeitig: Höhe, Charakteranimation und Kameradistanz. Es ist unmöglich, alle diese Optionen im Voraus zu durchdenken, und oft finden wir solche Fehler nur bei Ad-hoc-Tests.

Link zum Video 15: 02-15: 49

Es gibt noch ein weiteres Merkmal: Wir haben viele nicht deterministische Systeme. Dies sind Systeme, bei denen bei gleicher Eingabe das Endergebnis abweichen kann. Ein einfaches Beispiel ist, dass das System Zufallsvariablen enthält. In unserem Fall sind dies physikalische Systeme, in denen es viele Berechnungen mit Gleitkommazahlen gibt. Gleitkommaoperationen auf verschiedenen Prozessoren oder Compilern können etwas unterschiedlich ausgeführt werden. Aus diesem Grund unterscheidet sich die resultierende Funktionalität immer geringfügig. Infolgedessen sind solche Systeme ziemlich schwierig zu automatisieren, da es schwierig ist, der Maschine zu erklären, in welchem ​​Fall dies ein Fehler ist und in welchem ​​Fall dies akzeptable Unterschiede sind.

Link zum Video 16: 03-17: 14

Es gibt einige nicht triviale Interaktionen in der Engine und im Editor selbst. Benutzer interagieren häufig im dreidimensionalen Raum mit Maus und Tastatur. Dieses Video enthält eine Funktion namens Simuliertes Objekt. Dinge, die auf den Charakter gekleidet sind, müssen sich gemäß den Gesetzen der Physik bewegen, wenn der Charakter bewegt wird, auf dem diese Gegenstände getragen werden. Zum Beispiel Kleidung oder eine Aktentasche. Als solches Element im Video - die Hand des Charakters. Wenn sich der Charakter bewegt, beginnt auch die Hand zu reagieren. Um diese Funktionalität zu testen, müssen Sie häufig nicht triviale Aktionen ausführen: Wechseln Sie etwas in der Benutzeroberfläche, verschieben Sie Objekte im dreidimensionalen Raum, ziehen Sie sie per Drag & Drop, sehen Sie sich auch die unten stehenden Animationsdiagramme an und erledigen Sie alles in Echtzeit. Diese Funktion wirkt sich auf die Komplexität der Automatisierung aus.

Wie bestimme ich die Abdeckung?


Irgendwann stellten wir fest, dass wir viele Testfälle geschrieben hatten, aber es war schwierig festzustellen, welche Abdeckung wir hatten. Wir fanden die kritischsten Fehler nicht während unseres vollständigen Regressionstests, sondern während des Ad-hoc-Tests, der am Ende des Veröffentlichungszyklus durchgeführt wurde. Wir begannen zu überlegen: Wir haben eine Engine mit viel Funktionalität, wir haben ein Repository mit 12.000 Fällen - wie kann man verstehen, an welchen Stellen genügend Abdeckung vorhanden ist und an welchen es sich lohnt, Testfälle hinzuzufügen?

Wir wandten uns der Testtheorie zu und begannen zu lesen, wie Menschen die Testabdeckung definieren. Eine Möglichkeit besteht darin, durch Quellcode zu bestimmen. In unserem Fall ist das schwierig. Wir haben mehrere Millionen Codezeilen und es war unmöglich, diese Prüfung in kurzer Zeit durchzuführen. Die zweite Methode besteht darin, die Abdeckung durch eine Bewertung der Anforderungen zu bewerten. In agilen Prozessen werden Anforderungen häufig nur im Kopf von Personen und nicht in der Dokumentation gespeichert, sodass die Anforderungen für eine Abdeckungsbewertung auch nicht realistisch waren. Infolgedessen haben wir uns dem einzig möglichen Weg zugewandt - der Definition der Abdeckung durch das Schreiben eines Modells.



Wir haben ein Modell namens ACC gewählt - Attribut, Komponente, Fähigkeit. ACC ist eines der einfachsten Modelle, das bei Amazon für Modellierungssoftware weit verbreitet ist. Das Modell basiert auf drei Hauptsäulen. Erstens sind dies Komponenten, Substantive sind die Hauptarbeitsteile des Systems. Für uns ist dies Ansichtsfenster, Textur, Spielessenz. Das Folgende sind Fähigkeiten - Verben - was diese Komponenten können. Sie können beispielsweise auf dem Bildschirm angezeigt werden, etwas berechnen, etwas verschieben usw. Und der dritte Teil sind Attribute - Adjektive oder Adverbien, die sich sowohl auf die Komponenten als auch auf ihre Fähigkeiten beziehen. Attribute beschreiben die Parameter von Funktionen: schnell, sicher, skalierbar, sicher usw. All dies kann auf drei Fragen reduziert werden: Wer? Was macht? und wie?

Wir werden dieses Modell anhand eines kleinen Beispiels analysieren. Unten finden Sie eine Demo eines kleinen Teils der Funktionalität:

Link zu Video 19: 59-21: 02

Das Ansichtsfenster ist der Teil des Editors, in dem die Ebene sichtbar ist. Das Video zeigte, dass es möglich ist, die Kamera zu drehen, sich im Level zu bewegen und einen Charakter aus dem lokalen Dirigenten von Spielobjekten hinzuzufügen. Sie können einen Charakter verschieben oder eine neue Spielentität erstellen, indem Sie mit der rechten Maustaste klicken. Sie können alle aktuellen Entitäten auf der Ebene auswählen und alle zusammen verschieben. Sie können auch ein weiteres geometrisches Element hinzufügen und (wie in allen dreidimensionalen Editoren) nicht nur seine Position im Raum ändern, sondern auch seinen Winkel ändern und seine Größe ändern. Ein Fenster namens "Ansichtsfenster" verfügt über verschiedene Rendering-Modi. Beispielsweise werden die Schatten deaktiviert oder einige Grafikeffekte der Nachbearbeitung werden deaktiviert. Sie können in den Spielemodus wechseln, um die gerade vorgenommenen Änderungen sofort zu testen.



Schauen wir uns das ACC-Modell selbst an. Wir haben schnell erkannt, dass diese Modelle mit Mindmaps sehr praktisch sind, und sie dann entweder in Tablets oder direkt in die Struktur in TestRail oder in ein anderes Repository für Testfälle übersetzt. Die Hauptkomponente selbst ist im Diagramm in der Mitte sichtbar - Ansichtsfenster - und weiter oben über dem roten Zweig befindet sich die Ansichtsfensterfunktion, mit der Sie sich in der Ebene bewegen können: Sie können die Kamera drehen, Sie können mit den Tasten „W“, „A“, „S“, „D“ fliegen.

Seine zweite Möglichkeit (orangefarbener Zweig) besteht darin, Spielentitäten entweder über Viewport oder per Drag & Drop aus dem Spiel-Explorer zu erstellen.

Und die Entitäten des dritten Spiels können manipuliert werden: Sie können unterschieden, ihre Position geändert, gedreht usw. werden. Der grüne Zweig links ist die Ansichtsfenster-Konfiguration beim Wechseln des Rendering-Modus. Im blauen Zweig wird ein Attribut hervorgehoben, das angibt, dass Viewport auch bestimmte Leistungsparameter erfüllen soll. Wenn es langsamer wird, wird es für Entwickler schwierig sein, irgendetwas zu tun.

Die gesamte Baumstruktur wird dann an TestRail übertragen. Als wir die Testfälle von unserem vorherigen System in die neue Struktur übertragen haben, wurde sofort klar, wo die Testfälle fehlten - an einigen Stellen erschienen leere Ordner.



Link zum Video 23: 01-24: 10

Diese Strukturen wachsen ziemlich schnell. Das Ansichtsfenster bezieht sich tatsächlich auf den Editor, der nur ein Teil der Engine ist. Zwei Hauptteile: der Editor selbst und die Spiel-Engine selbst. Rechts im Bild oben sehen Sie mehrere Komponenten, die nicht mit dem Baum zusammenhängen. Bei einem Rendering- oder Skriptsystem sind Animationen beispielsweise getrennt, da sie sich unmittelbar auf den Editor und die Engine beziehen. Das heißt, das Rendering-System funktioniert zur Laufzeit auf den Endgeräten, aber im Editor selbst können einige Parameter geändert werden: Tages- und Nachtzeit, Bearbeitungsmaterialien, Partikelsystem.

Ergebnisse und Schlussfolgerungen


Die ACC-Modellierung half dabei, Bereiche hervorzuheben, in denen Testpatienten betroffen waren. Durch das Füllen der Lücken in der Berichterstattung wurde die Anzahl der nach unserem vollständigen Regressionsdurchlauf gefundenen Fehler um etwa 70% reduziert. Einfach zu bauende ACC-Modelle haben sich auch als gute Dokumentationsquelle erwiesen. Die neuen Leute, die zu dem Projekt kamen, studierten sie und konnten sich schnell ein Bild vom Motor machen. Die Erstellung / Aktualisierung von ACC-Modellen ist eng in unseren Prozess der Entwicklung neuer Funktionen eingebunden.



Wir haben begonnen, die Engine durch Automatisierung der Benutzeroberfläche zu automatisieren. Die Editor-Oberfläche ist in der QT-Bibliothek geschrieben. Dies ist eine Bibliothek zum Schreiben einer plattformübergreifenden Benutzeroberfläche für Desktop-Anwendungen, die sowohl auf Mac als auch auf Windows funktionieren kann. Wir haben ein Tool namens Squish von Froglogic verwendet, das auf einem ähnlichen System mit WebDriver funktioniert und an die Desktop-Umgebung angepasst ist. In diesem Tool wird ein Ansatz verwendet, der dem von Page Object (aus der Welt von WebDriver) ähnelt und anders heißt - Composite Elements Architecture. Selektoren werden an den Hauptkomponenten (wie einem „Fenster“ oder einer „Schaltfläche“) vorgenommen und Funktionen, die mit diesen Elementen ausgeführt werden können, werden registriert. Zum Beispiel "Rechtsklick", "Linksklick", "Speichern", "Schließen", "Beenden". Dann werden diese Elemente zu einer einzigen Struktur zusammengefasst.Sie können in Ihrem Skript darauf zugreifen, sie verwenden, einen Screenshot machen und vergleichen.

Probleme und Lösungen


Das erste Problem ist die Stabilität. Wir haben Tests geschrieben, die die Geschäftslogik über die Benutzeroberfläche testen - was ist das Problem? Wenn sich die Geschäftslogik nicht ändert, sich aber die Benutzeroberfläche ändert - die Tests fallen, müssen Sie neue Screenshots hochladen.

Das nächste Problem ist der Mangel an Funktionalität. Viele Anwenderfälle sind nicht nur ein Knopfdruck, sondern eine Interaktion mit der dreidimensionalen Welt. Diese Bibliothek erlaubte dies nicht, neue Lösungen wurden benötigt.

Das dritte Problem ist die Geschwindigkeit. Für alle UI-Tests müssen Sie die gesamte Engine vollständig rendern. Es braucht Zeit, die Maschinen für diese Tests müssen leistungsfähig genug sein.



Die Lösung kam in Form einer Shiboken-Bibliothek. Diese Bibliothek enthält Ordner aus C ++ - Code in Python, mit denen vom Editor oder der Engine bereitgestellte Funktionen direkt aufgerufen werden können, ohne den UI-Editor zu rendern. Ein Analogon aus der Welt des Web - Headless Automation (ähnlich wie PhantomJS) - Sie können eine Webanwendung automatisieren, ohne einen Browser zu starten. In diesem Fall ein ähnliches System, nur für eine in C ++ geschriebene Desktop-Anwendung.

Nachdem wir begonnen hatten, in dieses Framework zu investieren, stellten wir fest, dass es nicht nur zur Automatisierung von Tests, sondern auch zur Automatisierung von Prozessen innerhalb der Engine verwendet werden kann. Zum Beispiel muss ein Designer 100 Lichtquellen hintereinander platzieren (zum Beispiel macht er eine Straße und Sie müssen Lichter platzieren). Anstatt alle diese Lichtquellen manuell darzustellen, schreiben Sie einfach ein Skript, das eine Spieleinheit erstellt, dort eine Punktlichtquelle hinzufügt und vorschreibt, dass Sie alle 10 Meter das zuvor erstellte Punktlicht kopieren müssen. Ein Bonus für unsere Benutzer in Form eines Tools zur Automatisierung von Routineaufgaben.



Der zweite Teil der Lösung des Problems. Wir haben schnell erkannt, dass wir zur Automatisierung verschiedener Teile unserer Engine - zum Beispiel Grafiken und Netzwerkteile - völlig unterschiedliche Frameworks benötigen. Es ist unmöglich, ein einziges, monströses Framework zu erstellen, das dabei hilft, alles auf einmal zu automatisieren. Aus diesem Grund haben wir begonnen, ein Framework namens Lumberyard Test Tools (kurz LyTestTools) zu entwickeln. Es basiert auf Pytest (in Python sind ziemlich viele Dinge in der Engine geschrieben). Wir haben uns für die sogenannte Plug-and-Play-Architektur entschieden - die zentrale Gruppe der Automatisierungsingenieure schreibt den Hauptteil des Frameworks, mit dem die Engine heruntergeladen, konfiguriert, auf verschiedenen Plattformen bereitgestellt, Tests ausgeführt und Protokolle gesammelt, Berichte in unsere Datenbank oder S3 hochgeladen und gezeichnet werden können Grafiken in Quicksight. Plug-and-Play wird durch Test Helper's erreicht,Dies wird von Teams auf dem Gebiet geschrieben, die Funktionen entwickeln.

Das heißt, das Grafikentwicklungsteam testet mit Screenshots und das Netzwerkinteraktionsteam überprüft die weitergeleiteten Pakete. Gleichzeitig werden sie alle mit unserem gemeinsamen Framework verbunden sein (da beide Teams Module einer einzelnen Engine entwickeln und testen), sodass sie alle die gleichen Schnittstellen zum Ausführen von Tests und zum Generieren von Berichten haben, sodass alles mehr oder weniger standardmäßig und korrekt mit unserem CI funktioniert / Cd.

Interaktion mit Lumberyard


Wie kann eine Desktop-Anwendung interagiert / automatisiert werden? Die erste Art der Interaktion zwischen dem Framework und der Engine - direkt von Python aus wird der Prozess mithilfe der Unterprozessfunktion gestartet, wenn die Anwendung das Starten über die Befehlszeile impliziert. Sie können die Eingabe / Ausgabe von der Standardeingabe / -ausgabe lesen und somit Aussagen treffen. Beim nächsten Typ - dieser Interaktion durch die Analyse von Protokollen - können Sie die von der Anwendung hinterlassenen Protokolle lesen und analysieren. Der dritte ist über das Netzwerk. In den Spielestarts gibt es ein Modul namens Remote Console. Wenn ein bestimmter Port auf dem Gerät geöffnet ist, kann unser Framework Pakete / bestimmte Befehle senden. Machen Sie zum Beispiel einen Screenshot oder öffnen Sie eine bestimmte Ebene. Ein anderes Verfahren ist die Interaktion durch Vergleichen visueller Informationen, d.h. Screenshots.Ebenfalls zuvor erwähnt wurde die Methode zum Aufrufen der Anwendungsfunktionalität direkt über die Produkt-API (in unserem Fall ist dies ein Aufruf über Python-Bindungen an die C ++ - Editor / Engine-Funktionalität).

Kommen wir zu Beispielen für die Verwendung unseres Frameworks zur Automatisierung der Engine.

Schauen Sie sich diesen Screenshot an.



Das Detail auf dieser Seite ist ziemlich hoch - eine große Menge an Vegetation. In modernen Spielen können Levels bis zu mehreren zehn und hundert Spielkilometern dauern. Natürlich wird jedes dieser Spielbüsche nicht manuell abgelegt, sonst würden die Entwickler einfach verrückt werden. Für sie hat unser Motor Spezialwerkzeuge.

Eines davon heißt Vegetation Tool. Kleine Demo:

Link zum Video 32: 18-34: 06

Wir sehen den Standardstart des Levels. Es gibt Terrane und man kann sehr schnell Abhilfe schaffen: Im Hintergrund Berge machen, im Mittelteil auch einen kleinen Hügel hervorheben. Sie können den Boden selbst grün mit einer Grasstruktur streichen. Der Prozess des Hinzufügens von Vegetation, in diesem Fall Bäumen, wird weiter demonstriert. Geometrie - Bäume, wird dem Werkzeug hinzugefügt - eine Teilmenge davon wird hervorgehoben, und mit diesen Bäumen kann jede erforderliche Zeichnung gezeichnet werden. Dies ist ein ziemlich einfaches Beispiel. Dieses Tool verfügt über viele anpassbare Parameter. Sie können beispielsweise nicht einen Baum, sondern mehrere gleichzeitig auswählen und einen Parameter für sie festlegen, in einem bestimmten Abstand voneinander stehen oder zufällige Parameter für die Größe oder Drehung dieser Bäume festlegen. Sie können einen Spielcharakter hinzufügen und sofort im Level ausführen, testen,Was hast du gerade in deinem eigenen Spielgarten angebaut?

Lassen Sie uns nun anhand einiger Tests als Beispiel sehen, wie wir diese Funktion mit unserem Framework automatisiert haben.

Link zum Video 34: 20-34: 58

Es gibt einen Standardterran, auf dem viel Gras wächst. Diese Art des Renderns ist sehr prozessorintensiv. Wenn es viele solcher Elemente gibt, können Sie einen Belastungstest durchführen. Hier wurde ein Spieleskript hinzugefügt, das beim Starten des Spielmodus einfach einen Flug durch dieses Level macht. Die Aufgabe besteht darin, diese Funktionalität zu testen und sicherzustellen, dass der Game Launcher stabil ist und nicht abstürzt.



Dies ist ein Beispiel dafür, wie das Team, das die Funktion zum Wachsen der Vegetation entwickelt hat, Test Helper geschrieben hat, mit dem Sie mit diesen Funktionen arbeiten können. Dies ist ein Beispiel für die Verwendung unseres Frameworks. Die Launcher-Klasse ist grün hervorgehoben. Wenn der Test gestartet wird, wird der Launcher bereitgestellt, startet mit Timeout-Parametern und wir versichern, dass der Launcher nach einer Weile nicht abstürzt. Dann schalten wir es aus.



Der obige Parametrierungscode zeigt, dass wir denselben Code auf verschiedenen Plattformen wiederverwenden können. Darüber hinaus können wir denselben Code auf verschiedenen Ebenen oder in verschiedenen Projekten wiederverwenden. Beispielsweise werden Plattformen rot hervorgehoben: In einem Fall handelt es sich um Windows, in einem anderen Fall um Mac. Das Projekt ist gelb hervorgehoben. Die Namensstufe wird hellgelb hervorgehoben.

Link zum Video 36: 07-36: 47

Nun zum Test - in diesem Fall führen Sie ihn über die Befehlszeile aus. Es öffnet sich ein Programm namens Asset Processor, einer der Hauptteile der Engine. Dieses Programm verarbeitet Quellressourcen (z. B. von Künstlern erstellte Modelle und Texturen) in Formate, die für die Engine verständlich sind, und schreibt alles in die Datenbank (SQLite), damit die Engine während des Spiels schnell navigieren und die erforderlichen Daten laden kann. Als nächstes startet der Launcher, der Spielemodus startet, die Kamera fliegt einige Sekunden über dem Level und der Test endet. Wir sehen, dass ein Test erfolgreich war und zwei Tests übersprungen wurden. Dies geschah, weil während der Aufzeichnung des Videos der Test unter Windows verfolgt wurde und in der Parametrisierung zwei weitere Plattformen vorhanden waren, die während dieses Starts jeweils übersprungen wurden.



Es gibt eine schwierigere Option. Wir starten den Launcher nicht nur mit dem fertigen Level, sondern das Skript interagiert direkt mit dem Editor. Blau gibt den Namen eines separaten Skripts an, das mit dem Editor zusammenarbeitet und verschiedene Befehle über die API abruft.



Oben ist die Teststufe. In diesem Fall wird mit einer zuvor vorbereiteten Textur (Maske) ein Lächeln auf das Standardgelände gezeichnet. Es muss überprüft werden, ob bei Verwendung der Maske nur entlang einer zuvor ausgewählten Kontur gemalt wird und nicht darüber hinausgeht.



Das Team, das mit der Spielwelt arbeitet, hat seine Erweiterung für die Arbeit mit Terrane geschrieben, die dann in unser Framework eingefügt wird. Es wird ein neuer Pinsel erstellt, der auf die „Kopfsteinpflaster“ -Maske zeichnet, der Pinsel wird auf Rot gesetzt und die ausgewählte Ebene wird übermalt.



In Fortsetzung wird ein neuer Pinsel erstellt, für den eine andere Intensität eingestellt wird. Die Maske wird nicht mehr verwendet und im Zyklus wird bereits in einem anderen Teil der Ebene ein neues Element gezeichnet.

Mal sehen, wie dieses Skript funktioniert.

Link zu Video 38: 42-39: 35

Zunächst wird der Asset-Prozessor gestartet, der den Status der Asset-Datenbank überprüft und gegebenenfalls die neu hinzugefügten Elemente verarbeitet. Als nächstes startet der Editor. Das Level wird mit einem Lächeln geöffnet und ein Skript wird gestartet, das mit dem Editor ausgeführt wird. Er malt die Ebene über die Maske, erstellt dann einen blauen Kreis und macht Screenshots. Anschließend werden die Screenshots mit den Referenz-Screenshots verglichen, und wenn alles in Ordnung ist, wird der Test abgeschlossen.

Der Test macht solche Screenshots zum Vergleich mit Standards. Hier sieht man, dass das Bild deutlich entlang der Grenze verlief.

Grafik


Wir verwenden unser Framework auch zum Testen von Grafiken.

Link zum Video 40: 04-40: 56

Grafik - einer der schwierigsten Teile der Engine, der den größten Teil des Codes einnimmt. Sie können und sollten alles überprüfen - angefangen bei einfachen Dingen wie Geometrie und Texturen bis hin zu komplexeren Funktionen - dynamischen Schatten, Beleuchtung und Nachbearbeitungseffekten. Auf dem Video in der rechten Ecke sehen Sie das Spiegelbild in der Pfütze - alles funktioniert in Echtzeit auf unserem Motor. Wenn die Kamera nach innen fliegt, können Sie erweiterte Rendering-Elemente sehen, z. B. Blendung, transparente Elemente wie Glas sowie die Anzeige von Elementen wie Metalloberflächen. Wie wird diese Funktionalität mit Screenshots getestet?



Das ist unser Charakter, Rin. Damit testen wir oft Künstlerpipelines. Künstler erstellen etwas in ihrem Editor (zum Beispiel eine Figur) und zeichnen dann Texturen darauf. Asset Processor verarbeitet die Originaldaten für die Bereitstellung auf verschiedenen Plattformen, und die Grafik-Engine übernimmt die Anzeige.



Sicherlich sind Sie oft auf einen Fehler gestoßen, wenn "Texturen nicht geladen wurden". Tatsächlich gibt es viele Probleme, wenn beim Anzeigen von Texturen etwas passiert ist.



Aber alle sind gut darin, Screenshots zu vergleichen. Im ersten Screenshot sehen Sie einen Fehler - einige Materialien sind nicht gut geladen. In diesen Screenshots flog das gleiche Level, in dem sich das Motorrad und die Kamera befanden, in das Café, das zuvor im Video gezeigt wurde. Warum sieht hier alles so langweilig aus? Weil Screenshots nicht in der allerletzten Phase des Renderns aufgenommen werden, wenn die Grafik-Engine alle ihre Effekte darlegt, sondern in Stufen. Zunächst werden nur einfache Geometrien und Texturen gerendert: Schatten werden entfernt, komplexe Beleuchtungselemente werden entfernt. Wenn Sie alles in der allerletzten Phase testen und sich Diff Image ansehen, ist es schwierig zu sagen, was genau kaputt gegangen ist.



Wenn Sie dies schrittweise tun, können Sie ungefähr verstehen, in welchem ​​Teil der Grafik-Engine etwas schief gelaufen ist. Hier ist der Algorithmus, mit dem wir die Screenshots vergleichen.



Durch Vergleichen von Screenshots können Sie Grafiken, Anzeigeelemente, Texturen, Materialien und Shader testen.

Ich werde ein Beispiel für einen Fehler aus der alten Version unserer Engine geben, als wir dieses Framework nicht hatten.

Link zum Video 43: 10-43: 44

Es bezieht sich auf das Vegetationssystem. Nach dem Hinzufügen von Bäumen beginnt der grafische Teil, Schatten darunter zu zeichnen. Es ist notwendig, "Strg + Z" ("Abbrechen") zu drücken, die Bäume verschwinden und die Schatten bleiben. Wenn Sie zu Beginn, wenn der Baum steht und nachdem Sie auf "Abbrechen" geklickt haben, einen Screenshot machen, ist ein solcher Fehler im automatischen Modus nach dem Vergleich mit den Referenz-Screenshots von Vorher und Nachher leicht zu erkennen.

Durch den Vergleich von Screenshots wird auch die Asset-Pipeline sehr gut getestet. Wenn die Künstler etwas in 3D-Editoren (Maya, 3dsMax) erstellt haben, müssen Sie überprüfen, ob alles im Spiel auf die gleiche Weise angezeigt wird und nichts verloren gegangen ist: Das Huhn hat Federn, alle Tiere haben Fell, die Menschen haben die richtige Hautstruktur und andere Dinge.

Link zum Video 44: 16-44: 52

Auf der rechten Seite des Programms befindet sich der Asset Processor, der die Anzeige von allem, was der Künstler gemalt hat, im Spiel überwacht. Er wird uns sagen, dass mit diesen Vermögenswerten alles in Ordnung ist - sie sollten funktionieren. Auf dem Video können Sie sehen, dass einige Bäume schwarz wurden. Einige werden normal angezeigt und einige grüne Texturen sind einfach verschwunden. In dieser Form können Sie natürlich keine Engine oder Assets freigeben.

Nicht alles kann gefangen werden


Link zum Video 45: 03-45: 17

Fehler treten erst auf, wenn mehrere Elemente miteinander interagieren. Zwei Rin-Modelle werden normalerweise angezeigt, wenn sie voneinander entfernt sind. Wenn Sie sie jedoch näher bringen, treten Probleme mit der Geometrie auf. Leider sind solche Fehler selbst vor der Automatisierung schwer zu erkennen. Oft sind sie nur zu bemerken, wenn Tester im Erkundungstestmodus etwas unternehmen oder wenn der Motor bereits in die Hände der Kunden fällt.



Durch Vergleichen von Screenshots können Sie die Benutzeroberfläche des Editors selbst testen.

Spielkomponenten




Außerdem können Screenshots einige einfache Spielkomponenten testen. Ein Beispiel ist eine einfache Ebene, auf der sich eine Tür und ein Skript befinden, die beim Drücken der Leertaste das Öffnen und Schließen der Tür starten.

Sie können am Anfang und am Ende einen Screenshot machen. Wenn alles übereinstimmt, funktioniert das Skript, das die Position des Elements ändert, ordnungsgemäß.

KETTE


Wir haben schnell festgestellt, dass Screenshots derselben Funktionalität auf verschiedenen Plattformen sehr unterschiedlich sind. In einigen Fällen kann es je nach Grafikkartentyp zu Unterschieden auf derselben Plattform kommen. Wie gehe ich damit um, um keine 100500 Screenshots zu speichern? Es gibt ein Tool, Windows Advanced Rasterization Platform, ein Software-Renderer, mit dem Sie alle Grafiken erstellen können, ohne auf den Treiber und die Grafikkarte zurückgreifen zu müssen. Mit diesem Tool können Sie die meisten funktionalen Grafiktests ohne Abhängigkeit von Treibern und Hardware durchführen.

Performance


Last but not least muss die Game Engine produktiv sein! GPUs können mit verschiedenen grafischen Profilern wie PIX getestet werden. RAM kann in Visual Studio selbst getestet werden. Weitere Informationen zum Testen der Prozessorleistung mithilfe des RADTelemetry-Tools.

Wissen Sie, was Input Lag ist?

Link zum Video 47: 29-48: 21

Eingangsverzögerung - Dies ist die Verzögerung zwischen dem Drücken der Controller- / Tastaturtaste durch den Spieler und dem Moment, in dem das Spiel auf das Drücken reagiert. Input Lag tritt aufgrund der Datenübertragung über das Netzwerk auf, wenn Pakete für eine lange Zeit gesendet werden oder der Server für eine lange Zeit reagiert, sowie in Engines und ohne Verwendung von Netzwerken. Wenn jemand den Code durcheinander bringt, der für die Animation verantwortlich ist, kann die Eingangsverzögerung so hoch werden, dass der Charakter zu spät reagiert. In einfacher Näherung lässt sich dies ganz einfach testen: Eine virtuelle Tastatur wird geöffnet und ein Video aufgenommen, in dem der Moment des Drückens der Leertaste und der Moment des Starts der Animation aufgezeichnet werden.

Wir schauen uns an, wie viele Bilder pro Sekunde der Motor abgibt. Sie können berechnen, wie viel jeder Frame in Millisekunden (1000 / FPS) benötigt hat. Wenn Sie das Video Frame für Frame abspielen, können Sie berechnen, wie viele Frames seit dem Klicken vergangen sind, bevor sich der Charakter zu bewegen beginnt. Wenn Sie wissen, wie viele Millisekunden jedes Bild belegt, können Sie berechnen, dass beispielsweise 200 Millisekunden zwischen dem Drücken eines Leerzeichens und dem Beginn der Animation vergangen sind. Bei einer normalen menschlichen Reaktion von 100 Millisekunden ist dies zu langsam und Spieler werden sofort sagen, dass eine solche Verzögerung wertlos ist. Diese Testmethode hat ihre Probleme. Erstens wird es Fehler geben. Beispielsweise hat die virtuelle Tastatur eine Verzögerung. Zweitens machen Künstler in Spielen oft Animationen, damit der Charakter nicht sofort beginnt, die Hauptbewegung zu machen. Es gibt die sogenannte Vorfreude: vor der Hauptaktion,Zum Beispiel beugt sich der Charakter beim Springen zuerst ein wenig und beginnt erst dann zu springen. Dies kann einige Frames dauern. Wie haben wir das bekämpft? Wir haben begonnen, diesen Teil mit einem genaueren Ansatz zu testen.

Es gibt ein Programm namens RADTelemetry.

Link zum Video 49: 44-50: 47

Sie können den Prozessor profilieren. Hier sind vertikale Rahmen angeordnet: Nr. 629, 630 - Sie können sehen, wie viel Zeit jeder Rahmen benötigt hat. Horizontal werden entweder Prozessorkerne oder Anwendungsausführungsthreads entlassen, wenn die Anwendung über mehrere Threads verfügt. Wenn Sie auf einen der Threads klicken, wird links der Name aller Funktionen angezeigt, die sich beim Start in diesem Thread befanden, wie lange die Ausführung von der Gesamtsumme gedauert hat und wie oft sie ausgeführt wurden. Mit dieser Anwendung können Sie genau nachvollziehen, wie viel Zeit seit dem Registrieren des Tastenanschlags durch das Spiel vergangen ist, bevor die Funktion "Animation abspielen" gestartet wurde. Dieses Programm kann seine Protokolle in Textdateien ablegen und mit ihnen nützliche Leistungsdiagramme verschiedener Builds in der Zeitverteilung zeichnen.

Und wo ist AWS hier?


Abschließend noch ein paar Worte zu AWS. Einerseits verwenden wir es, um unsere Tests zu fahren. Wir führen Tests auf EC2 und auf Geräten aus der Gerätefarm durch. Die Ergebnisse werden in S3 zur Datenbank hinzugefügt, und in Quicksight werden Diagramme angezeigt. Teststatistiken können in CloudWatch angezeigt werden. Da die Engine stark in AWS-Services integriert ist, testen wir diese Integrationen auch - sowohl manuell als auch automatisch. CloudCanvas ist beispielsweise ein Dienst, mit dem Sie Funktionen für Netzwerkspiele ohne Programmierung erstellen können. Auf dem Server können Sie also einfach Chips wie Bestenlisten, Punktetabellen und Erfolge konfigurieren. Für Dinge wie die Monetarisierung von Spielen können Sie nicht nach Ihrem Serverprogrammierer suchen, sondern sofort mit der Verwendung von CloudCanvas beginnen. Amazon GameLift ist im Wesentlichen ein skalierbares System für Spieleserver.Integration mit Twitch - wenn Benutzer die Sendung von zwei Spielern sehen, die untereinander antreten. Eine Twitch-Umfrage wird erstellt. "Welchen Spieler unterstützen Sie?" - Die Leute beginnen im Chat abzustimmen, das Spiel liest die Antworten und einer der Spieler (wie bei den Hunger Games) kann einen zusätzlichen Bonus verlieren oder ihn verhindern.

Zusammenfassung


Das erste, was wir festgestellt haben, ist, dass es in so großen Projekten keine einzige Silberkugel gibt, mit der Sie alles automatisieren können. In unserem Fall hat das Plug-and-Play-Framework gut funktioniert. Wir haben einen gemeinsamen Rahmen geschrieben und den übrigen Teams ermöglicht, ihre Lösungen bequem einzubetten. Anhand von Beispielen für Screenshots und Vegetationsvergleiche zeigte das System, wie diese Frameworks funktionieren. Ich hoffe, dass einige Anwendungen und industrielle Lösungen (wie Microsoft Software Renderer oder RADTelemetry), die in diesem Artikel bereitgestellt werden, für praktizierende Ingenieure nützlich sind, die in Spielen oder CAD-Systemen arbeiten.

Abschließend Links zu allen Tools, die im Bericht gezeigt wurden:



Ich hoffe, dass ich feststellen konnte, wie sich das Testen von Engines vom Testen von Spielen unterscheidet. In letzter Zeit ist der Prozess weit vorangekommen - das Testen von Game-Engines ist überhaupt nicht einfach, aber sehr interessant.

Wenn Sie sich für das Thema Testen von Spielen interessieren, empfehlen wir Ihnen, sich andere Berichte anzusehen:

More articles:


All Articles