Sentry ist eine Plattform zur Erfassung und Analyse technischer Fehler. In der Spieleentwicklung sammelst du damit Informationen über Abstürze und andere Fehlerereignisse. Statt lediglich die Meldung zu erhalten, dass dein Spiel abgestürzt ist, kannst du zusätzliche Daten zum Fehlerzeitpunkt untersuchen.
Was ist Sentry?
Sentry dient der Überwachung von Software während ihrer Ausführung. Damit das System Informationen aus deinem Spiel erfassen kann, bindest du in der Regel ein passendes SDK ein. SDK steht für Software Development Kit. Dabei handelt es sich um Softwarekomponenten und Werkzeuge, mit denen du Funktionen eines anderen Systems in dein eigenes Projekt integrierst.
Welche Daten Sentry erfasst, hängt von der verwendeten Plattform, dem SDK und deiner Konfiguration ab. Dazu können Fehlermeldungen, Informationen über das verwendete Gerät, die Spielversion und Stack Traces gehören. Bei Konsolen nennt Sentry beispielsweise Modell, Build-Nummer, Region und Gerätezustand als möglichen Kontext.
Was ist ein Fehlerereignis?
Sentry arbeitet mit Events, also Ereignissen. Ein solches Ereignis entsteht beispielsweise, wenn dein Spiel einen erfassten Fehler meldet oder abstürzt. Das Ereignis enthält die verfügbaren technischen Informationen zu diesem Vorfall.
Mehrere Ereignisse können mit demselben zugrunde liegenden Problem zusammenhängen. Für die Fehlersuche ist das wichtig: Wenn derselbe Fehler bei verschiedenen Spielern auftritt, musst du nicht jeden Absturz als vollkommen unabhängiges Problem betrachten.
Was ist ein Crash?
Ein Crash ist die unerwartete Beendigung eines laufenden Programms. Dein Spiel kann beispielsweise auf ungültige Daten zugreifen oder in einen Zustand geraten, aus dem es nicht ordnungsgemäß weiterarbeiten kann.
Nicht jeder von Sentry erfasste Fehler führt allerdings zu einem Crash. Je nach Integration lassen sich auch nicht fatale Fehler erfassen. Dabei tritt ein technisches Problem auf, während das Spiel weiterläuft.
Sentry in der Spieleentwicklung
Sentry bietet Integrationen für unterschiedliche Entwicklungsumgebungen. Dazu zählen unter anderem Unity, Unreal Engine und native Anwendungen. Native Anwendungen verwenden Programmcode, der für das jeweilige Betriebssystem beziehungsweise die jeweilige Plattform ausgeführt wird.
Auch Konsolenspiele lassen sich einbeziehen. Sentry unterstützt Crash Reporting für Xbox, PlayStation und Nintendo Switch beziehungsweise Switch 2. Die konkrete Einrichtung unterscheidet sich je nach Plattform. Für bestimmte Konsolenfunktionen gelten außerdem Zugangs- und Verifizierungsbedingungen der jeweiligen Plattformbetreiber.
Damit ist Sentry kein Bestandteil einer bestimmten Spiele-Engine. Es handelt sich um ein separates System, das du mit deinem Entwicklungsprojekt verbindest.
Vom Crash zum Stack Trace
Angenommen, dein Spiel stürzt ab, sobald ein Spieler eine bestimmte Tür öffnet. Die Aussage „Das Spiel ist beim Öffnen der Tür abgestürzt“ beschreibt zunächst nur das sichtbare Problem.
Ein Stack Trace kann zeigen, welche Funktionen zum Zeitpunkt des Fehlers aufgerufen wurden. Dadurch lässt sich beispielsweise erkennen, dass die Türfunktion eine Inventarfunktion aufgerufen hat und der Fehler anschließend bei der Verarbeitung eines Gegenstands auftrat.
Der Stack Trace liefert damit einen Ausgangspunkt für das Debugging. Er beweist jedoch nicht automatisch, welche Programmzeile die eigentliche Ursache enthält. Der sichtbare Absturz kann die Folge eines Fehlers sein, der bereits vorher entstanden ist.
Warum Debug-Symbole wichtig sind
Bei kompilierten Spielen besteht ein Stack Trace zunächst nicht zwangsläufig aus verständlichen Funktions- und Dateinamen. Deshalb spielen Debug-Symbole eine wichtige Rolle.
Debug-Symbole enthalten Informationen, mit denen sich Bestandteile des ausgeführten Programms wieder ihrem ursprünglichen Programmcode zuordnen lassen. Dadurch kann aus einer schwer verständlichen Speicheradresse beispielsweise ein Funktionsname mit Bezug zu einer Quelldatei entstehen.
Sentry bietet dafür Funktionen zur Verarbeitung entsprechender Symboldateien. Welche Dateien erforderlich sind, hängt von der Plattform und dem verwendeten Entwicklungswerkzeug ab.
Was bedeutet Build-Kontext?
Ein Build ist eine aus deinem Entwicklungsprojekt erzeugte, ausführbare Version des Spiels. Während der Entwicklung können viele unterschiedliche Builds entstehen.
Die Zuordnung eines Fehlers zu einem Build ist deshalb wichtig. Ein Fehler aus Build 121 muss in Build 125 nicht mehr vorhanden sein. Umgekehrt kann ein Problem erstmals nach einer bestimmten Änderung auftreten.
Erkennst du, dass ein Crash ausschließlich in einer bestimmten Spielversion vorkommt, kannst du untersuchen, welche Änderungen gegenüber der vorherigen Version vorgenommen wurden.
Tags helfen bei der Einordnung
Sentry kann Ereignisse mit Tags versehen. Ein Tag ist eine zusätzliche Kennzeichnung, nach der sich Fehlerdaten ordnen oder filtern lassen.
Ein Tag könnte beispielsweise die Spielversion, eine Region oder einen bestimmten Zustand kennzeichnen. Dadurch kannst du untersuchen, ob ein Fehler nur unter bestimmten Bedingungen auftritt.
Auch hier gilt: Eine Übereinstimmung zeigt zunächst einen Zusammenhang. Sie beweist noch keine Ursache. Wenn ein Crash beispielsweise besonders häufig auf einem bestimmten Gerät erscheint, musst du anschließend untersuchen, warum das Problem dort auftritt.
Geräteinformationen liefern zusätzlichen Kontext
Bei der Fehlersuche kann die technische Umgebung eine Rolle spielen. Ein Problem tritt möglicherweise auf einem bestimmten Gerät oder einer bestimmten Plattform auf, während andere Systeme nicht betroffen sind.
Sentry kann abhängig von Plattform und Integration entsprechende Geräte- und Systeminformationen zusammen mit einem Fehlerereignis erfassen. Dadurch lassen sich Fehlerberichte nach technischen Gemeinsamkeiten untersuchen.
Diese Informationen ersetzen keine Reproduktion des Fehlers. Sie können aber dabei helfen, die Bedingungen einzugrenzen, unter denen du versuchen solltest, das Problem nachzustellen.
Entwicklungsgeräte und veröffentlichte Spiele
Fehler treten nicht nur während der internen Entwicklung auf. Manche Probleme zeigen sich erst außerhalb deiner eigenen Testumgebung.
Bei Konsolen unterscheidet Sentry deshalb unter anderem zwischen Entwicklungsgeräten und Geräten von Spielern. Die technische Erfassung unterscheidet sich je nach Plattform. Bei Nintendo Switch und Switch 2 besteht beispielsweise eine Integration für Crash-Daten aus Entwicklungs- und Endkundengeräten. Für PlayStation und Xbox gelten wiederum eigene Verfahren.
Damit kannst du Fehler untersuchen, die nicht auf deinem eigenen Entwicklungsrechner aufgetreten sind. Welche Daten tatsächlich zur Verfügung stehen, hängt weiterhin von Plattform, Freigaben und Konfiguration ab.
Sentry ersetzt das Debugging nicht
Sentry kann dir Informationen über einen Fehler bereitstellen. Die eigentliche Ursachenanalyse bleibt jedoch Teil des Debuggings.
Ein Stack Trace sagt dir nicht zwangsläufig, warum ein Wert falsch war. Geräteinformationen erklären nicht automatisch, warum ein Problem nur auf einer bestimmten Hardware auftritt. Auch die Häufigkeit eines Fehlers sagt zunächst nichts über seine technische Ursache aus.
Du nutzt die gesammelten Informationen deshalb als Ausgangspunkt: Du untersuchst das Ereignis, versuchst den Fehler zu reproduzieren, überprüfst mögliche Ursachen, korrigierst den Programmcode oder die betroffene Konfiguration und testest anschließend erneut.
Welche Grenzen hat die Fehlererfassung?
Ein Fehleranalyse-System kennt nur die Informationen, die es erfassen und übermitteln kann. Ist ein SDK falsch eingerichtet, fehlen benötigte Symboldateien oder wird ein bestimmter Programmzustand nicht protokolliert, kann ein Fehlerbericht unvollständig bleiben.
Hinzu kommt die Frage, welche Daten dein Spiel überhaupt erfassen soll. Bei Telemetrie und Fehlerberichten musst du berücksichtigen, welche Informationen technisch notwendig sind und welche Datenschutzanforderungen für dein Projekt gelten.
Sentry ist deshalb weder eine automatische Fehlerkorrektur noch ein Ersatz für Tests, Versionsverwaltung oder nachvollziehbare Entwicklungsabläufe. Es ergänzt diese Prozesse um zentral erfasste technische Fehlerdaten.
Sentry als Teil des Debugging-Prozesses
In einem möglichen Arbeitsablauf tritt zunächst ein Fehler in einem bestimmten Build auf. Sentry erfasst das Ereignis und die verfügbaren technischen Informationen. Du untersuchst anschließend Stack Trace, Build-Zuordnung und weiteren Kontext. Daraus entwickelst du eine Hypothese über die Ursache.
Danach beginnt die eigentliche Fehlersuche in deinem Projekt. Du reproduzierst das Problem, überprüfst die beteiligten Funktionen und vergleichst bei Bedarf verschiedene Entwicklungsstände. Nach der Korrektur erzeugst du einen neuen Build und kontrollierst, ob der Fehler weiterhin auftritt.
Sentry übernimmt in diesem Ablauf vor allem die Erfassung und Aufbereitung von Informationen über aufgetretene Fehler. Ob diese Informationen zur eindeutigen Ursache führen, hängt vom jeweiligen Problem und den verfügbaren Daten ab.
Weitere Informationen zu unterstützten Plattformen, SDKs und Funktionen findest du auf der offiziellen Website von Sentry.
Weitere Artikel auf Games und Lyrik:
