Ein Build ist eine ausführbare oder anderweitig testbare Fassung deines Spiels, die aus einem bestimmten Entwicklungsstand erzeugt wird. Der Build-Prozess verbindet Programmcode, Grafiken, Audio, Leveldaten und weitere benötigte Bestandteile zu einer Version, die sich auf der vorgesehenen Plattform ausführen lässt.
Was ist ein Build?
Während du ein Spiel entwickelst, besteht das Projekt aus vielen unterschiedlichen Dateien. Dazu gehören beispielsweise Programmcode, Texturen, 3D-Modelle, Animationen, Audiodateien, Level, Konfigurationen und Einstellungen.
Diese Projektdateien entsprechen nicht automatisch der Fassung, die später auf einem PC oder einer Konsole gestartet wird. Zunächst müssen die benötigten Bestandteile verarbeitet und für die jeweilige Zielplattform zusammengestellt werden. Das geschieht beim Build-Prozess.
Das Ergebnis dieses Prozesses wird als Build bezeichnet. Je nach Projekt und Entwicklungsumgebung kann es sich beispielsweise um eine ausführbare PC-Version, eine Konsolenfassung oder eine andere testbare Version des Spiels handeln.
Was passiert beim Build-Prozess?
Welche Schritte erforderlich sind, hängt von der verwendeten Engine, der Zielplattform und dem Projekt ab. Programmcode kann kompiliert, Assets können verarbeitet und benötigte Dateien in eine für die Ausführung geeignete Struktur gebracht werden.
Kompilieren bedeutet vereinfacht, dass Quellcode in eine Form übersetzt wird, die der Computer beziehungsweise die jeweilige Laufzeitumgebung ausführen kann. Nicht jeder Bestandteil eines Spiels durchläuft dabei denselben Vorgang. Eine Textur muss beispielsweise anders verarbeitet werden als Programmcode.
Am Ende steht eine konkrete Fassung des Spiels. Dadurch lässt sich testen, ob die einzelnen Bestandteile auch außerhalb der unmittelbaren Entwicklungsarbeit wie vorgesehen zusammenspielen.
Projektstand und Build sind nicht dasselbe
Ein Projekt verändert sich während der Entwicklung ständig. Ein Build bildet dagegen einen bestimmten Entwicklungsstand zu einem bestimmten Zeitpunkt ab.
Du kannst nach der Erstellung einer Version bereits weiter am Projekt arbeiten. Die neuen Änderungen befinden sich dann im aktuellen Projektstand, aber noch nicht automatisch in dem zuvor erzeugten Build. Erst eine neue Probeversion berücksichtigt sie.
Interne und veröffentlichte Builds
Nicht jede Version gelangt zu den Spielern. Während der Entwicklung entstehen regelmäßig interne Fassungen für Programmierer, Designer, Qualitätssicherung und andere Teammitglieder.
Solche Builds dienen beispielsweise dazu, neue Funktionen zu testen, Fehler zu reproduzieren oder zu prüfen, ob verschiedene Änderungen gemeinsam funktionieren. Manche Versionen existieren nur kurze Zeit und werden nach dem nächsten Entwicklungsstand durch eine neue Versionen ersetzt.
Auch externe Tester können speziell vorbereitete Versionen erhalten. Für eine Veröffentlichung gelten dagegen zusätzliche Anforderungen. Welche Prüfungen notwendig sind, hängt unter anderem von Plattform und Vertriebsweg ab.
Was ist ein Development Build?
Entwicklungsumgebungen können besondere Versionen für die Fehlersuche erzeugen. Solche Development Builds enthalten häufig zusätzliche Informationen oder Funktionen, die beim Testen und Debugging helfen.
Eine Veröffentlichungsversion kann dagegen stärker auf Leistung, Dateigröße und die Anforderungen der Zielplattform ausgerichtet sein. Deshalb kann sich ein Fehler manchmal in einem internen Entwicklungs-Build anders verhalten als in einer für Spieler erstellten Fassung.
Warum sind Build-Nummern wichtig?
Bei zahlreichen erzeugten Versionen muss eindeutig erkennbar bleiben, welche Fassung getestet wurde. Dafür können die Versionen mit Nummern oder anderen eindeutigen Kennzeichnungen versehen werden.
Angenommen, Build 120 funktioniert problemlos. In Build 121 stürzt das Spiel dagegen beim Öffnen einer Tür ab. Die Nummern ermöglichen zunächst eine klare Aussage darüber, welche Version funktioniert und welche den Fehler zeigt.
Nun kannst du untersuchen, welche Änderungen zwischen den zugrunde liegenden Entwicklungsständen liegen. Die Nummer selbst erklärt den Fehler nicht. Sie schafft jedoch einen eindeutigen Bezugspunkt für die weitere Untersuchung.
Builds und Versionsverwaltung
Besonders hilfreich ist die Verbindung mit einer Versionsverwaltung. Sie dokumentiert, welche Änderungen am Projekt vorgenommen wurden.
Ist bekannt, aus welchem Projektstand Build 120 und Build 121 entstanden sind, lässt sich die Änderungsgeschichte zwischen beiden Fassungen untersuchen. Dadurch kannst du den Bereich eingrenzen, in dem der neue Fehler entstanden sein könnte.
Bei Perforce P4 können zusammengehörende Änderungen in Changelists organisiert werden. Taucht ein Fehler erstmals nach bestimmten Changelists auf, liefern diese mögliche Ansatzpunkte für die Untersuchung.
Ein neuer Build beweist noch keine erfolgreiche Fehlerkorrektur
Änderst du den Programmcode und erzeugst anschließend eine neue Probeversion, bedeutet das noch nicht automatisch, dass der ursprüngliche Fehler behoben ist. Die neue Fassung muss getestet werden.
Dabei prüfst du zunächst die Situation, in der der Fehler zuvor auftrat. Anschließend sind weitere Tests sinnvoll, denn eine Korrektur kann unbeabsichtigt andere Bereiche beeinflussen. Solche neu entstandenen Probleme werden als Regressionen bezeichnet.
Was passiert, wenn ein Build fehlschlägt?
Nicht jeder Prozess endet mit einer startbaren Version. Fehler im Programmcode, fehlende Dateien, falsche Einstellungen oder andere technische Probleme können verhindern, dass die Version erfolgreich erzeugt wird.
Eine fehlgeschlagenerVersion ist dabei etwas anderes als ein Crash. Beim fehlgeschlagenen Probebau entsteht die vorgesehene Version nicht korrekt. Bei einem Crash konnte das Spiel dagegen zunächst gestartet werden und beendet sich während der Ausführung unerwartet.
Builds für unterschiedliche Plattformen
Ein Spiel kann für mehrere Plattformen erscheinen, doch dieselbe erzeugte Datei läuft nicht automatisch überall. PC, PlayStation, Xbox, Nintendo-Systeme und mobile Plattformen besitzen unterschiedliche technische Voraussetzungen.
Deshalb entstehen für die jeweiligen Zielplattformen eigene Versionen. Dabei können sich nicht nur Dateiformate und technische Einstellungen unterscheiden. Auch Steuerung, Grafikoptionen, Plattformfunktionen und Leistungsanforderungen können Anpassungen benötigen.
Builds, Logs und Stack Traces
Tritt ein Fehler in einer bestimmten Fassung auf, reichen Nummer und Versionsgeschichte nicht immer aus. Weitere technische Informationen helfen bei der Suche.
Log-Dateien können Ereignisse während der Ausführung dokumentieren. Ein Stack Trace zeigt bei geeigneten Fehlern die Folge der aufgerufenen Funktionen. Zusammen mit der Kennung lässt sich dadurch festhalten, in welcher Version ein Problem auftrat und was unmittelbar davor geschah.
Fehler aus veröffentlichten Builds untersuchen
Bei internen Tests sitzt das Entwicklungsteam häufig direkt vor dem betroffenen Rechner. Nach der Veröffentlichung treten Fehler dagegen auf den Systemen der Spieler auf. Informationen über die betroffene Version gewinnen deshalb zusätzliche Bedeutung.
Fehlererfassungsplattformen wie Sentry können technische Ereignisse aus Anwendungen sammeln und einer veröffentlichten Version zuordnen. Dadurch lässt sich beispielsweise erkennen, ob ein Problem nur in einem bestimmten Release auftritt.
Solche Systeme ersetzen das Debugging nicht. Sie liefern Informationen, mit denen sich ein Fehler reproduzieren und anschließend im Entwicklungsprojekt untersuchen lässt.
Vom Fehler zum nächsten Build
Ein typischer Ablauf kann mit einem fehlerhaften Build beginnen. Logs und Stack Traces liefern Hinweise, die Versionsverwaltung führt zu relevanten Änderungen und beim Debugging untersuchst du die mögliche Ursache.
Nach der Korrektur entsteht eine neue Version. Dieser durchläuft erneut die notwendigen Tests. Funktioniert die ursprüngliche Situation wieder und zeigen die weiteren Prüfungen keine neuen Probleme, kann die Korrektur in den nächsten Entwicklungsstand einfließen.
Der Versionsbau ist damit nicht nur das Ergebnis eines technischen Prozesses. Er bildet einen klar definierten Entwicklungsstand, der getestet, verglichen und bei Fehlern untersucht werden kann.
Weitere Artikel auf Games und Lyrik
Wenn du dich neben der technischen Spieleentwicklung auch für klassische Adventures interessierst, findest du auf Games und Lyrik weitere Beiträge. In Runaway 3: A Twist of Fate begleitest du Brian und Gina durch ein Point-and-Click-Adventure mit Rätseln, ungewöhnlichen Situationen und einer Geschichte voller Wendungen.
Wie Fehler in verschiedenen Builds erfasst und analysiert werden können, erfährst du außerdem auf der offiziellen Website von Sentry.
