Wie statische Code-Analyse in der GameDev-Branche hilft

( 4. Dezember 2020)

Die Spielebranche entwickelt sich ständig weiter und entwickelt sich schneller als eine Kugel. Mit dem Wachstum der Branche steigt auch die Komplexität der Entwicklung: Die Codebasis wird größer und die Anzahl der Fehler nimmt ebenfalls zu. Daher müssen moderne Spielprojekte der Codequalität besondere Aufmerksamkeit widmen. Heute werden wir eine der Möglichkeiten behandeln, Ihren Code anständiger zu gestalten, nämlich die statische Analyse sowie die praktische Unterstützung von PVS-Studio bei der Entwicklung von Spielprojekten in verschiedenen Größen.

„Das Wichtigste, was ich als Programmierer in den letzten Jahren getan habe, ist aggressive statische Code-Analyse zu verfolgen. Noch wertvoller als die Hunderte schwerwiegender Fehler, die ich damit verhindert habe, ist die veränderte Denkweise in Bezug auf die Art und Weise, wie ich die Zuverlässigkeit und Codequalität von Software betrachte. ”- John Carmack

Wir arbeiten seit vielen Jahren mit großen Spieleentwicklern zusammen und haben in dieser Zeit viele interessante und nützliche Dinge für die Spielebranche getan. Angesichts der -Liste unserer Kunden aus der Spielebranche ist dies keine große Überraschung. Wir unterstützen unsere Kunden aktiv: PVS-Studio in ihren eigenen Entwicklungsprozess zu integrieren, vom Analysator festgestellte Fehler zu beheben und sogar spezielle benutzerdefinierte Funktionen zu erstellen.

Darüber hinaus führen wir viele unabhängige Entwicklungen durch Der Analysator in GameDev-Richtung sowie die Werbung für PVS-Studio informieren die Leute über interessante Fehler, die in verschiedenen Videospielen gefunden wurden.

Sicher, wir haben einige interessante Geschichten zu erzählen. Dieser Artikel behandelt mehrere solcher Fälle.

PVS-Studio und Unity

Wir bewerben unser Produkt unter anderem, indem wir Artikel über die Überprüfung offener Projekte schreiben. Jeder profitiert von diesen Artikeln: Ein Leser hat die Möglichkeit, einige ungewöhnliche Fehler in einem vertrauten Projekt zu überprüfen und etwas Neues zu lernen. Für das PVS-Studio-Team haben wir die Möglichkeit, die Arbeit an echtem Code zu zeigen, damit Projektentwickler sich über Fehler informieren und diese im Voraus beheben können.

Unsere erste große Bekanntschaft mit Unity fand statt 2016, als die Entwickler dieser Spiele-Engine den Quellcode mehrerer Komponenten, Bibliotheken und Demos in ihrem offiziellen Repository öffneten. Kein Wunder, dass wir an einem so verlockenden Fall nicht vorbeikommen konnten und einen Artikel über das Überprüfen des veröffentlichten Codes schreiben wollten.

Dann fanden wir heraus, dass der Unity3D-Code (zu dieser Zeit wurde die Engine so genannt) war von sehr hoher Qualität. Trotzdem konnten wir viele schwerwiegende Fehler darin finden. Es gab genug davon, um einen Artikel zu schreiben.

Zwei Jahre später passierte etwas anderes: Unity-Entwickler öffneten den Code der Engine und der Herausgeber selbst. Und genau wie beim letzten Mal konnten wir das nicht zur Kenntnis nehmen und überprüften den Quellcode der Engine. Und es war nicht umsonst – wir haben auch eine Reihe von faszinierenden Fehlern gefunden.

Gleichzeitig gehen unsere Absichten weit über das reine Schreiben hinaus Artikel. Wir arbeiten weiterhin an PVS-Studio und GameDev ist einer der wichtigsten Bereiche für unsere Entwicklung. Daher möchten wir, dass Unity-Spieleentwickler die bestmögliche Analyse ihrer Projekte erhalten.

Einer der Schritte zur Verbesserung der Qualität der Analyse von Unity-Projekten bestand darin, Anmerkungen zu Methoden zu schreiben, die in der Unity Scripting-API definiert sind

Methodenanmerkungen sind ein spezieller Mechanismus, der in PVS-Studio verwendet wird. Es ermöglicht einem Benutzer, dem Analysegerät alle erforderlichen Informationen zu einer bestimmten Methode bereitzustellen. Es wird von den Analysatorentwicklern selbst (d. H. Von uns) in speziellem Code geschrieben.

Diese Informationen können von völlig unterschiedlicher Art sein. Beispiel: Wie kann sich die Methode auf die an sie übergebenen Parameter auswirken, ob sie Speicher zuweisen kann und ob sie einen Wert zurückgibt, der behandelt werden muss. Durch Annotation kann der Analysator die Logik von Methoden besser verstehen und neue und komplexere Fehler erkennen.

Wir haben bereits eine große Anzahl verschiedener Annotationen geschrieben (z. B. für Methoden aus dem System) Namespace), und wir haben ihnen gerne Methodenanmerkungen aus der Unity Scripting-API hinzugefügt.

Wir haben begonnen, die Liste der Anmerkungen um eine Bewertung zu erweitern. Wie viele Methoden gibt es insgesamt? Welche sollten zuerst kommentiert werden? Insgesamt gab es viele Methoden, daher haben wir uns entschlossen, zunächst die am häufigsten verwendeten zu kommentieren.

So suchten wir nach gängigen Methoden: Zuerst haben wir einen Pool von Projekten von GitHub zusammengestellt, die Unity-Funktionen verwenden, und dann haben wir ein selbst geschriebenes Dienstprogramm (basierend auf Roslyn) verwendet, um Aufrufe an zu berechnen Die Methoden, an denen wir interessiert waren. Als Ergebnis erhielten wir eine Liste von Klassen, deren Methoden am häufigsten verwendet wurden:

  • UnityEngine.Vector3
  • UnityEngine.Mathf
  • UnityEngine.Debug
  • UnityEngine.GameObject
  • UnityEngine.Material
  • UnityEditor.EditorGUILayout
  • UnityEngine.Component
  • UnityEngine.Object
  • UnityEngine.GUILayout
  • UnityEngine.Quaternion

Als nächstes blieb es um die Methoden dieser Klassen zu kommentieren. Wir haben ein Testprojekt erstellt und in die Dokumentation gegraben, um so viele Informationen wie möglich über diese Methoden zu erhalten. Wir haben beispielsweise versucht, null als verschiedene Argumente zu übergeben, um zu sehen, wie sich das Programm verhalten würde.

Bei solchen Überprüfungen haben wir von Zeit zu Zeit einige interessante undokumentierte Informationen entdeckt. Wir haben sogar ein paar bemerkenswerte Fehler im Motor gefunden. Wenn Sie beispielsweise den folgenden Code ausführen:

MeshRenderer renderer = cube.GetComponent();
Material m = renderer.material;
List<int> outNames = null;
m.GetTexturePropertyNameIDs(outNames);

stürzt der Unity-Editor selbst ab (zumindest in Version 2019.3.10f1). Natürlich ist es unwahrscheinlich, dass jemand einen solchen Code schreibt. Dennoch ist die Tatsache, dass der Unity-Editor durch Ausführen eines solchen Skripts zum Absturz gebracht werden kann, merkwürdig.

Wir haben also die Anmerkungen geschrieben. Nach dem Ausführen der Analyse haben wir sofort neue Auslöser gefunden. Beispielsweise hat der Analysator einen seltsamen Aufruf der GetComponent -Methode festgestellt:

void OnEnable()
{
GameObject uiManager = GameObject.Find("UIRoot"); if (uiManager)
{
uiManager.GetComponent();
}
}

Analyzer-Warnung: V3010 Der Rückgabewert der Funktion GetComponent muss verwendet werden. – ZUSÄTZLICH IN AKTUELLEM UIEditorWindow.cs 22

Die Methode GetComponent impliziert die Rückgabe eines bestimmten Werts, auch wenn dieser fällig ist zu seinem Namen. Es ist logisch anzunehmen, dass dieser Wert auf irgendeine Weise verwendet werden sollte. Dank der neuen Anmerkung weiß der Analysator nun, dass ein solcher „unbeaufsichtigter“ Aufruf dieser Methode auf einen logischen Fehler hinweisen kann, und warnt davor.

Dies ist nicht die einzige Warnung, die in unserem Satz enthalten ist Testen Sie Projekte, nachdem Sie neue Anmerkungen hinzugefügt haben. Ich werde den Rest nicht zitieren, um diesen Artikel nicht zu groß zu machen. Die Hauptsache ist, dass Sie jetzt mit der Entwicklung von Unity-Projekten mit PVS-Studio viel sichereren und saubereren Code ohne Fehler schreiben können.

Wenn Sie mehr über unsere Arbeit mit Anmerkungen für Unity-Methoden lesen möchten, Hier ist der Artikel: Wie der PVS-Studio-Analysator begann, noch mehr Fehler in Unity-Projekten zu finden .

Unreal Engine 4

Als 2014 die Entwickler von Unreal Engine 4 öffnete den Quellcode der Engine, wir konnten einfach nicht an diesem Projekt vorbei und schrieben auch einen Artikel darüber. Die Engine-Entwickler mochten den Artikel und haben die gefundenen Fehler behoben. Dies war jedoch nicht genug für uns und wir beschlossen, die Lizenz für unseren Analysator an Epic Games zu verkaufen.

Epic Games war daran interessiert, seine Engine mit PVS-Studio zu verbessern, daher einigten wir uns auf Folgendes : Wir korrigieren den Unreal Engine-Code selbst, damit der Analysator keine Warnungen ausgibt, und Jungs von Epic Games kaufen unsere Lizenz und belohnen uns zusätzlich für die geleistete Arbeit.

Warum alle Warnungen sein mussten Fest? Tatsache ist, dass man den maximalen Nutzen aus der statischen Analyse ziehen kann, indem man Fehler richtig korrigiert, wenn sie auftreten. Wenn Sie Ihr Projekt zum ersten Mal überprüfen, erhalten Sie normalerweise mehrere hundert (und manchmal Tausende) Warnungen. Unter all diesen Analysatorauslösungen können Warnungen für neu geschriebenen Code leicht verloren gehen.

Auf den ersten Blick kann dieses Problem ganz einfach gelöst werden: Sie müssen sich nur hinsetzen und den gesamten Bericht durchgehen Fehler allmählich korrigieren. Obwohl diese Methode intuitiver ist, kann sie einige Zeit dauern. Es ist viel bequemer und schneller, Unterdrückungsdateien zu verwenden.

Unterdrückungsdateien sind eine Spezialfunktion von PVS-Studio , mit der Sie sie ausblenden können Warnungen des Analysators in einer speziellen Datei. Versteckte Warnungen werden jedoch nicht in nachfolgenden Protokollen angezeigt: Sie können sie separat anzeigen.

Nachdem Sie nach der ersten Überprüfung viele Auslöser erhalten haben, können Sie alle erkannten Warnungen mit wenigen Klicks zur Unterdrückungsdatei hinzufügen Nach der nächsten Überprüfung erhalten Sie ein sauberes Protokoll ohne einen einzigen Eintrag.

Nachdem die alten Warnungen nicht mehr im Protokoll enthalten sind, können Sie eine neue Warnung sofort erkennen, wenn sie angezeigt wird. Hier ist die Reihenfolge der Aktionen: Schreiben Sie den Code -> überprüfen Sie ihn mit dem Analysegerät -> erkennen Sie eine neue Warnung -> beheben Sie den Fehler. So können Sie den Analysator optimal nutzen.

Vergessen Sie gleichzeitig nicht die Warnungen in der Unterdrückungsdatei: Sie können nach wie vor Warnungen vor schwerwiegenden Fehlern und Schwachstellen enthalten. Daher sollte man zu diesen Warnungen zurückkehren und ihre Anzahl regelmäßig reduzieren.

Kein Zweifel, dieses Szenario ist praktisch, aber Entwickler von Epic Games wollten, dass ihr Code sofort repariert wird, also haben sie das bestanden Aufgabe für uns.

Und wir machten uns an die Arbeit. Nach Überprüfung des Projektcodes fanden wir 1821 Warnungen von Level_1 und Level_2. Das Parsen einer so großen Menge von Warnungen erfordert ernsthafte Arbeit. Um diesen gesamten Prozess zu vereinfachen, haben wir eine kontinuierliche Code-Analyse auf unserem CI-Server eingerichtet.

Es sah so aus: Jede Nacht auf unserem Server die aktuelle Die Version von Unreal Engine 4 wurde erstellt, und unmittelbar nach dem Build wurde die Analyse automatisch gestartet. Wenn unsere Jungs am Morgen zur Arbeit kamen, hatten sie immer einen neuen Bericht vom Analysegerät, der ihnen half, den Fortschritt der Beseitigung von Warnungen zu verfolgen. Darüber hinaus konnten wir mit diesem System die Build-Stabilität jederzeit überprüfen, indem wir sie manuell auf dem Server ausführten.

Der gesamte Prozess dauerte 17 Arbeitstage. Der Zeitplan für die Behebung von Fehlern war wie folgt:

Tatsächlich spiegelt dieser Zeitplan unsere Arbeit nicht vollständig wider. Nachdem wir alle Warnungen behoben hatten, warteten wir weitere zwei Tage, bis sie unsere neuesten Pull-Anfragen angenommen hatten. Während dieser ganzen Zeit wurde die neueste Version von Unreal Engine automatisch überprüft, was wiederum mit neuem Code aktualisiert wurde. Also, was denkst du ist passiert? Während dieser zwei Tage hat PVS-Studio vier weitere Fehler im Code gefunden! Eine davon war entscheidend und könnte möglicherweise zu undefiniertem Verhalten führen.

Natürlich haben wir auch diese Fehler behoben. Zu diesem Zeitpunkt hatten die Entwickler von Unreal Engine nur noch eines: die automatische Analyse an ihrem eigenen Ort einzurichten, genau wie wir es getan haben. Von diesem Moment an sahen sie jeden Tag Warnungen, die für den Code ausgegeben wurden, den sie gerade geschrieben hatten. Auf diese Weise konnten sie Fehler im Code beheben, sobald sie erschienen – in den frühesten Entwicklungsstadien .

Weitere Informationen zur Arbeit mit dem Unreal Engine-Code finden Sie im offizieller Unreal Engine-Blog oder auf unserer Website .

Analyse von verschiedene Spiele

Habe ich erwähnt, dass wir verschiedene offene Projekte prüfen und Artikel darüber schreiben? Wir haben jetzt viele ähnliche Artikel über Spielprojekte! Wir haben über Spiele wie VVVVVV , Space Engineers , Befehl & Conque r, osu! und sogar (ein sehr früher Artikel) Doom 3 . Wir haben auch die Top 10 der interessantesten Softwarefehler aus der Videospielbranche zusammengestellt.

Also haben wir wahrscheinlich die meisten überprüft bekannte Open Source Engines. Neben Unity und Unreal Engine 4 werden Projekte wie Godot , Bullet , Amazon Lumberyard , Cry Engine V und viele andere sind unter unsere Sicht gekommen.

Das Beste daran ist, dass viele der von uns beschriebenen Fehler später von den Projektentwicklern selbst behoben wurden. Es ist schön zu spüren, dass das von Ihnen entwickelte Tool der Welt echte, sichtbare und greifbare Vorteile bringt.

Sie können eine Liste aller unserer Artikel zur Entwicklung von Videospielen auf die eine oder andere Weise auf einer Website anzeigen spezielle Seite unseres Blogs.

Fazit

An diesem Punkt endet mein Artikel. Ich wünsche Ihnen sauberen und korrekt funktionierenden Code ohne Fehler und Fehler!

Sie interessieren sich für das Thema statische Analyse? Möchten Sie Ihr Projekt auf Fehler überprüfen? Versuchen Sie PVS-Studio .

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.