Mikael Kalms hat im englischen EA Forum einen Artikel veröffentlicht, der uns einen Einblick in die Software Entwicklung ermöglicht. Der Artikel weckt ein Verständnis für die Herausforderungen eines Spiele-Entwicklers und zeigt auf, warum Patches immer größer und in der Entwicklung komplexer werden. Eine detaillierte Erklärung für die Verzögerungen des letzten Patch und ein eventuelles Omen für die zukünftigen Updates.
Der Artikel ist so interessant, dass man sich dazu entschlossen hat ihn nicht nur vorzustellen, sondern auch denjenigen zugänglich zu machen, die nicht auf Anhieb einen englischen Text mit Fachbegriffen verstehen können.
Man hat hier diesen Artikel nicht Wort für Wort übersetzt, aber versucht den Inhalt verständlich zu vermitteln.
Viel Spaß....
Ein Artikel über Software Entwicklung, Dateiformate, Konstruktionsprozesse und Verpackungstechnik.
Unter Beachtung des "Project Management Triangle"
Die Entwicklung eines Videospiels setzt sich grob aus zwei Faktoren zusammen. Einerseits der Software (Game-Engine) und andererseits dem Datensatz auf welchen die Software zugreift um ein Ergebnis darzustellen. Idealerweise sind diese beiden Teile perfekt aufeinander abgestimmt, um so zusammen ein Produkt/Videospiel zu erschaffen.
Die Entwicklung der Software unterscheidet sich eigentlich nicht von der Entwicklung anderer Programme. Hierfür kommen Programmiersprachen, Werkzeuge und Techniken zum Einsatz dessen Grundlagen schon um 1960 entwickelt wurden. So wird ein Quellcode erstellt, welcher nach der Konvertierung eine einzige ausführbare Datei erzeugt.
Den Inhalt für die Software zu erstellen ist meist nicht weniger kompliziert. Auch hier werden größtenteils Standardwerkzeuge (Maya, Photoshop, SoundForge, Cubase usw.) benutzt, darüber hinaus kommt es vor, dass die Entwickler eigene Werkzeuge entwickeln müssen um die gewünschten Inhalte zu erzeugen.
Software und auch der Inhalt (Sounds, Grafiken etc.) wird selten dem Anwender im Rohformat zur Verfügung gestellt. Dann wäre das Endprodukt nicht nur sehr umfangreich in der Datenmenge, sondern die langwierige Konvertierung, in ein für die Engine nutzbares Format, müsste beim Verbraucher stattfinden. Lange Wartezeiten bei der Nutzung wären unausweichlich.
Deshalb nutzen die Entwickler speziell erstellte Programme, um diese Konvertierungen im Vorfeld zu erledigen. Wir wollen diese Arbeitsschritte mal als "Vorkochen" bezeichnen. Dieses Vorkochen beim Hersteller sorgt dafür, dass wir als Kunde dann einfach ein (hoffentlich) köstliches Fertiggericht in die Mikrowelle schieben können um es schnell und unkompliziert konsumieren zu können. Doch wie bei dem Fertiggericht gibt es einige Unzulänglichkeiten gegenüber dem frisch zubereiteten Menü...
Vorkochen hat nun mal Vor- und Nachteile
Im Rohformat ist ein wesentlicher Vorteil, dass die Quelldaten jederzeit geändert werden können und die Änderungen direkt nach dem Start der Software greifen. Auch ist direkt ersichtlich welche Dateien für die Vorgänge im Spiel verantwortlich sind. Ein Nachteil sind die zu erwartenden langen Ladezeiten, sowie eine stark fragmentierte Speichernutzung. Das Verifizieren dieser Daten ist wiederum nur möglich indem der gesamte Funktionsumfang der Software geprüft wird. Beim Vorkochen können Mechanismen eingebaut werden die diese Vorgänge übernehmen. Es kann die Ladezeit optimiert werden und es ist nicht mit einer großen Fragmentation des Speichers zu rechnen.
Nach dem Vorkochen ist es allerdings schwierig Einzelheiten zu ändern. Bei Änderungen läuft es darauf hinaus das die kompletten Quelldaten neu gekocht werden müssen. Auch ist es nicht mehr so leicht, die Dateien den Vorgängen im Spiel zuzuordnen.
Die Frostbite Engine und ihr Ursprung
Die Frostbite Engine wurde als erstes für BFBC1 angewendet, welches bekanntermaßen ein Konsolentitel war. Aus diesem Grund war das Vorkochen der Daten umso wichtiger, damit lange Ladezeiten und Speicherfragmentationen verhindert werden konnten. Konsolenbedingte limitierte Ressourcen des Speichers und der allgemeinen Perfomance sowie die Begrenzung durch das DVD Format machten hier die Vorarbeiten unabdingbar.
Diese Grundlagen boten bei der Entwicklung von BFBC2 für den PC einige Vorteile. Viele Zeitaufwändige Aufgaben waren somit schon gelöst und es war auch unproblematisch die verschiedenen Dateien einem Archiv sowie diese dann wieder verschiedenen Level zuzuordnen.
Der Wunsch das Spiel automatisch updaten zu können stand fest, aber einen solchen "Auto- Patcher" zu entwickeln, der mit allen aktuellen Betriebssystemen funktioniert und auch mit limitierten Benutzerkonten sowie Techniken wie der Benutzerkontensteuerung (UAC) kompatibel ist, bedeutet natürlich einen sehr hohen Zeitaufwand. Hier konnten dann aber glücklicherweise die Erfahrungen, welche mit dem Auto Patcher von Battlefield Heroes gesammelt wurden, genutzt werden. Mit einigen Modifikationen konnte auch so dieser Wunsch erfüllt und umgesetzt werden.
So hatten die Entwickler es jedenfalls angenommen...
Komplexe Systeme - Oberflächlich gesehen einfach, im Detail manchmal komplexer als angenommen und Trickreicher als erwartet
Manchmal verstecken sich Probleme und warten darauf gefunden zu werden. So auch in diesem Fall. Erst als mit der Arbeit an Updates begonnen wurde zeigte sich ein Problem mit bösem Lächeln den Entwicklern. Es stellte sich heraus das während des erneuten Vorkochens der Rohdaten die Ergebnisse nicht zu 100% identisch sind. Zwar ist das Ergebnis bzw. die Funktionalität identisch, aber die Daten sind binär gesehen nicht die selbem.
Man könnte sich fragen warum so etwas nicht früher auffällt, doch Tatsache ist, daß dieser Prozess des Vorkochens des gesamten Materials auf einem High End Entwickler PC mehr als 48 Stunden Zeit in Anspruch nimmt. So etwas wird natürlich nicht mehrfach wiederholt ohne einen Grund... Übrigens der BFBC2 Datensatz im Rohformat beträgt mehr als 80GB verteilt auf ca. 40.000 Dateien! Nach dem Kochvorgang werden daraus gute 100.000 Dateien.
Das bedeutet, die Veränderungen bei der Erstellung eines Patch sind im Rohformat eindeutig zu erkennen und nachzuvollziehen. Nach dem Vorkochen aber nicht mehr...
Beispiel:
Version A ist bekannt und Ausgangsversion – Version B ist verändert durch den Patch, aber eben auch verändert durch den erneuten Kochvorgang. Wie soll man die realen (Patch) Änderungen von den Surrealen (unwichtige Änderungen durch den Kochvorgang) herausfinden? Man kann sich vorstellen, dass eine Überprüfung/Filterung per Hand unmöglich ist bei 100.000 Dateien.
Was also tun? Einen perfekten Filter zu erstellen, der die benannten Unterschiede erkennt, ist keine Lösung. Auch den Kochprozess so zu optimieren, dass die Ergebnisse immer die selben sind und die Unterschiede auf der binären Ebene somit zu umgehen auch. Alle drei Optionen sind vom Zeitaufwand einfach absolut unrealistisch...
So wurde der goldene Mittelweg gesucht, ein Filter der intelligent nach Vorgaben bekannte Änderungen sucht, aber im Zweifelsfall eine Änderung eher als Real einstuft. Wäre der Ärger nicht schon genug, kommen auch noch Probleme mit dem Shader Datenbestand dazu. Und am Ende macht dann auch noch der Auto Patcher selber Probleme und benötigt Aufmerksamkeit. Der Patcher kann zwar problemlos Teile von Dateien ersetzen. Aber direkt auf die speziellen BFBC2 Archive zuzugreifen und innerhalb dieser Dateien bzw. Teile dieser zu verändern ist, aufgrund der Herkunft des Patchers, nicht möglich. Somit können die Neuerungen nur in neuen separaten Archiven in das Spiel eingepflegt werden.
Das Szenario welches die derzeitige Situation beeinflusst
Wegen dieser Umstände wird jeder Patch größer als der vorausgehende, das sich das Spiel in seiner Gesamtheit immer weiter von dem entfernt, was als Original von der DVD stammt. Jede Änderung, die eine Modifikation der Shader Grunddaten benötigt, lassen den neuen Patch ballonartig anschwellen. Somit ist mittlerweile ein cleveres Vorgehen bei der Auswahl bzw. Änderung der Daten unumgänglich.
Hiermit sind nun die grundlegenden Probleme bei der Entwicklung der aktuellen Updates etwas transparenter und somit sind nun auch die Hintergründe für die Verzögerungen des letzten Patches verständlich. In einem Team, in der die Aufgabenverteilung bei der Entwicklung ein Schlüssel zum Erfolg ist, gibt es nur wenige Leute mit genügend Fachwissen über alle benötigten Bereiche. Um ein funktionstüchtiges Update Paket auf den Weg zum Kunden zu bringen, müssen die beteiligten neben dem Fachwissen über die weit entfernten Winkel der Game Engine, die angewendeten "Kochwerkzeuge" und auch noch dem voran gegangenen "Patching" Prozess mitbringen, um Fehler zu finden und auch lösen zu können...
Der aktuelle Patch (R8) hatte nach seiner ersten Fertigstellung eine Größe von 7GB was natürlich aus verschiedenen Gründen nicht akzeptabel war. Der hohe Aufwand und die damit einhergehenden Verzögerungen haben deutlich gezeigt, dass die Entwickler nach neuen Ansätzen suchen müssen, um ihr Ziel/Wunsch, das Spiel auch zukünftig unterstützen zu wollen, zu erreichen.
Das sind die Dämonen, die dem Autor des originalen Artikels in der Nacht den Schlaf rauben.
So ich hoffe das der eine und andere diesen Artikel auch recht interessant fand.
Euer INSI
[vote]
zuletzt editiert von Insider1976 am 07.07.2010 19:00 Uhr
Seite: « 
Battlefield 2
