Vulkan und die Technik hinter Doom Eternal - Interview mit Lead Engine Programmer Billy Khan

Unseren Technik-Artikel zu Ancient Gods Part One, dem jüngst erschienenen, ersten umfangreichen Addons für Doom Eternal, haben Sie eventuell schon gelesen. Um es kurz zu machen: Wir sind begeistert. Das Addon führt die Geschichte des Doom Slayers fort, ebenso wie das gefeierte, extrem schnelle und flüssige Gameplay des Hauptspiels. Ancient Gods Part One ist dabei um einiges kniffeliger als Doom Eternal und erfordert noch schnellere Reflexe, dank der ultra-geschmeidigen Performance und des ausgefeilten Gameplays ist Ancient Gods aber niemals unfair und belohnt Hartnäckigkeit und Lernwille des Spielers.

Zum Launch des Addons hatten wir indes außerdem Gelegenheit, mit Billy Khan, dem Leitenden Engine Programmierer von id Software zu sprechen. Natürlich haben wir uns die Chance nicht entgehen lassen, um Billy zu den technischen Aspekten von Doom Eternal, der Vulkan-Schnittstelle und anderen technischen Details auszuquetschen - man bekommt schließlich nicht häufig die Chance, einen solch tiefen Blick hinter die Kulissen der Technik und Spieleentwicklung im Generellen zu werfen. Wie Sie wohl bald sehen werden, war Billy Khan sehr auskunftsfreudig und erklärt viele interessante Umstände von Doom Eternal, der id-Tech-Engine und id Software im Allgemeinen.

PCGH: In diesem Interview wird es hauptsächlich über die technischen Aspekte der Engine und Doom im Allgemeinen gehen. Meine erste Frage ist deswegen: Warum habt ihr die Vulkan-API gegenüber OpenGL oder DirectX 12 vorgezogen? Ich meine, es ist ziemlich offensichtlich: Vulkan hat einige Vorteile. Vielleicht kannst du es aber besser mit deinen eigenen Worten erklären und erörtern, wie die Vulkan-API es euch erlaubt, die grafischen Features von Doom (2016) und Doom Eternal speziell zu verbessern.

Billy Khan: Wir lieben Vulkan. Wenn ihr unsere Firmengeschichte kennt und unsere technischen Errungenschaften, dann wisst ihr ja bereits, dass wir in unserem Hause seit Ewigkeiten Open GL verwenden. Seit vielen, vielen Jahren, für viele Jahrzehnte, wenn ihr so wollt. In unserer Geschichte haben wir bisher immer offene API's bevorzugt und wir wollen sehr eng mit den Hardware-Herstellern zusammenarbeiten. Mit unseren Partnern wie Intel, AMD oder Nvidia und noch vielen anderen darunter etwa Google, Microsoft oder Sony erlaubt uns Open GL eine bessere Zusammenarbeit. Dank der offenen API, können wir frei miteinander arbeiten, ohne dabei stets an jeweilige Restriktionen denken zu müssen.

Und die Vulkan-API wird ja nicht nur für Videospiele genutzt, sondern findet auch in vielen professionellen Bereichen Anwendung wie etwa innerhalb der CAD-Branche oder in der medizinischen Industrie Verwendung. Generell ist der Einsatz von Vulkan also für viele verschiedene Projekte nützlich. Und weil wir gerne an Dingen arbeiten, die nicht nur in Spielen, sondern überall sinnvoll sind, sind unsere Techniken hoffentlich auch für andere Unternehmungen in der Zukunft nützlich und sinnvoll oder können eventuell für diese adaptiert werden. Deswegen haben wir damals mit Open GL gearbeitet und generell wollen wir eine offene Plattform haben, auf der wir mit anderen problemlos zusammenarbeiten können. Ein spezifischer Vorteil, über welchen die OpenGL-API damals und auch heute verfügte, waren Erweiterungen.

PCGH: Die Open-GL-API kann sich also genau wie Vulkan zusammen mit den wachsenden Fähigkeiten der Hardware entwickeln, richtig?

Billy Khan: Ja genau, diese APIs sind sehr ausbaufähig. Und durch Kollaboration mit den Partnern und Gleichgesinnten findet man neue, sinnvollere Wege, um Probleme anzugehen und mit der zur Verfügung stehenden Hardware zum Funktionieren zu bringen. Man arbeitet also mit dem einen Hersteller zusammen und finden für dessen Hardware eine Lösung. Damit ist man dann also in der Lage, dessen Hardware vollständig auszunutzen. Dann geht man zu einem anderen Partner, welcher über andere Hardware und Ressourcen verfügt, und man will natürlich auch auf dieser Plattform das Optimum herauskitzeln.

Dank der API-Erweiterungen können wir dies bewerkstelligen und verschiedene Plattformen entsprechend der Hardware vollständig ausnutzen. Mit Blick auf die Erweiterungen war der Wechsel zu Vulkan daher der nächste logische Schritt. Einfach weil es uns erlaubte, genau das Gleiche wie bisher mit Open GL zu tun und somit hoffentlich die Industrie als Gesamtes voranzubringen. Wir wollen dabei unterstützen, neue Dinge zu lernen, gemeinsam zusammenzuarbeiten und sinnvolle Beiträge innerhalb der Gaming-Industrie leisten. Deswegen war es uns sehr wichtig, dass wir diese Fähigkeit zur Nutzung von API-Erweiterungen bekommen und so im Endeffekt Software, Spiele oder generell Produkte herstellen können, die einen Einfluss auf die Industrie ausüben. Und Vulkan erlaubt uns, ebendies mit aktueller Hardware bestmöglich zu erzielen. Abgesehen von Vulkan könnte man prinzipiell das Gleiche auch mit Direct X bewerkstelligen, wenn auch ohne die gleiche, hohe Flexibilität durch die Extentions - es ist im Grunde lediglich ein anderer Prozess. Wir sind indes aufgrund unserer Open-GL-Historie mit dieser offenen API-Sache sehr vertraut. Vulkan war also nur eine natürliche Weiterentwicklung unserer bisherigen Geschichte.

Obendrein war der Wechsel zu Vulkan aber natürlich auch dahingehend extrem wichtig, weil wir so eng wie möglich an der Hardware arbeiten wollen: Wir wollen die dünnste Schicht zwischen dem Betriebssystem und der eigentlichen Hardware bilden. Vulkan erlaubt uns, das wie auch auf anderen Plattformen durchzuführen, wo die Schichten zwischen OS und Hardware ebenfalls sehr dünn sind.

PCGH: Zum Beispiel bei den Konsolen?

Billy Khan: Ja, Konsolen sind ein gutes Beispiel. Und selbst auf mobilen Geräten kann man in manchen Fällen, oder auf anderer Hardware, die nicht einmal mit Videospielen zu tun hat, per se sehr nahe an die eigentliche Hardware herankommen. Damit kann man also all die tollen Funktionen, die das Gerät bietet, auch wirklich vollends ausnutzen.

Vulkan nimmt also diese Treiberschicht, die auf der Hardware sitzt und zertrümmert diese, entfernt Einiges und gibt dem Entwickler mehr Verantwortung, aber auch mehr Macht über die Hardware. Das kann erstmal entmutigend und frustrierend sein, aber wenn man sich erst einmal damit befasst haben, macht es die Software im Allgemeinen besser. Wenn ihr euch mit Vulkan beschäftigt, erlaubt euch die Auseinandersetzung mit der API, besser zu verstehen, was die Hardware eigentlich von euch verlangt. Eure Software wird allein aus diesem Grund deutlich besser, weil ihr tatsächlich das Richtige tun müsst, damit die Software zufriedenstellend funktioniert.

Bei anderen APIs habt ihr beispielsweise diese API-Cut-Byte-Calls und ihr wisst vielleicht aus eigener Recherche, was die Hardware da eigentlich zu tun versucht. Aber die Schnittstelle, mit der ihr arbeitet, präsentiert die Dinge dann auf eine bestimmte Art und Weise. Was die Hardware dann aber tatsächlich tut, steht dann wieder auf einem anderen Blatt, darüber habt ihr eventuell keine Kontrolle und diese Information habt ihr je nach API vielleicht gar nicht erst. Um also ein besseres Verständnis zu bekommen, was tatsächlich im Rechner abgeht, muss man sich solche Low-Level-Sachen bewusstmachen. Im Grunde können wir mit diesem Bewusstsein mehr aus der Hardware herausholen. So ein Vorgehen reduziert nicht nur den CPU-Overhead, es verbessert auch die Stabilität der Treiber, denn je weniger Code vorhanden ist, der dann schlussendlich interpretiert werden muss, um das zu erzielen, was ihr eigentlich wollt, desto besser läuft das Spiel.

Quelle: PC Games Hardware Doom Eternal (6)
PCGH: Klingt logisch. Weniger und effizienterer Code ist schneller und zugleich kommt es auch zu weniger Fehlern.

Billy Khan: Ganz genau. Wir können jetzt also sehr viel exakter werden, beispielsweise können wir der GPU sagen, bitte mach dies oder das. Wir haben bestimmte Erwartungen an unsere Shader und Compute-Vorgänge und wie sie Informationen verarbeiten - und mit Vulkan ergeben all diese Erwartungen Sinn. Wir können genau ableiten, was in der Engine gerade geschieht.

Früher, in den alten Zeiten, lange vor den modernen APIs, da musste man sich ausgiebig mit dem Code des Spiels für das Programmieren eines Treibers beschäftigen. Die Treiber-Programmierer hatten damals oft nicht mal den Source Code des betreffenden Spiels, keinen direkten Zugriff und konnten so noch nicht einmal sehen, was dann im Backend vielleicht schlussendlich zu Problemen führte. Man konnte sich damals nur fragen, "Hey, was ist denn das?" "Was hat sich diese Person dabei gedacht?" Es war sehr schwer und gleichzeitig ziemlich erstaunlich, was die Treiber schlussendlich tun konnten und mussten, damit Spiele auf der Hardware gut liefen. Im Grunde mussten sie ohne direkte Anweisungen den Code korrekt erraten, richtig schlussfolgern, was im Spiel passierte. Oft ging das gut, aber oft genug hat es eben auch nicht funktioniert. Manchmal war es auch einfach so knifflig oder nuanciert, dass man keine zielgerichtete Lösung finden konnte. Wird in der Software beispielsweise an einer Stelle eine gezielte Korrektur vorgenommen, zerstört man damit eventuell unerwartetes etwas Anderes.

Mit Vulkan ist das nun anders. Wie schon erwähnt, ist die Konfrontation und der nötige Arbeitsaufwand mit einer Low-Level-API anfangs sehr entmutigend, aber am Ende zahlt es sich aber aus. Das Programmieren mit Vulkan mag anfangs wie ein Rückschritt vorkommen, wenn man damit zu programmieren beginnt - aber dann macht man nach einem Schritt rückwärts plötzlich fünf Schritte nach vorn. Stellt es euch wie einen kleinen Hügel am Anfang vor, den man mit Müh' und Not hochkommt: Hat man die Gipfel erstmal erklommen geht die Abfahrt umso einfacher und schneller.

PCGH: Wenn man Vulkan korrekt nutzt, dann ist es also effizienter, schneller und weniger anfällig für Abstürze als bisherige APIs?

Billy Khan: Ja ist es, aber egal wie gut euer Code eurer Meinung nach funktioniert, ihr könnt immer Verbesserungen daran vornehmen. Es gibt immer etwas, worüber ich bei meinem Code nachdenke, wirklich die ganze Zeit. Dann denkt man sich "Oh, das ist nicht das Beste was ich mit meinem Code machen kann" und ein paar Tage später fragt man sich, "was habe ich mir dabei bloß gedacht? Ich mach das jetzt lieber so, das ist ja um so viel besser." Das ist schließlich auch, was Software so interessant macht, richtig? Daher kommt auch der Name, denn Software ist formbar, sie verändert sich. Wir bringen sie durch Herumprobieren dazu, dass zu tun, was wir brauchen und wollen. Wir können uns cleverere Vorgehensweisen einfallen lassen, einfach dadurch, indem wir ständig an unserem Code und auch uns selbst arbeiten, uns verbessern - das ist, was es so interessant macht.

Im Endeffekt geht das sogar soweit, dass wir über Wege nachdenken, wie wir die Hardware zu vorher undenkbaren Leistungen bringen können, einfach, weil wir jetzt mehr Kontrolle über die API und damit die Hardware haben. Ich denke, die ganzen Erweiterungen sind wirklich ein wichtiger Faktor für uns, damit wir sagen können: "Hey, mit deiner neuen Hardware sind diese neuen Dinge hier möglich. Ich möchte das gern für X verwenden". Daran hatte man vorher noch nicht gedacht, sodass man in der Zusammenarbeit mit den Herstellern dann neue sinnvolle Möglichkeiten für den Einsatz dieser Techniken findet - die nicht nur Spiele betreffend, sondern auch andersartige Software. Das ist quasi der Grund, warum wir Vulkan unglaublich mögen.

Natürlich gibt es noch andere Gründe, beispielsweise glaube ich, dass Treiber jetzt einfach in abgespeckter Form vorliegen, weil ein Bedarf besteht, viel genauer auf die Hardware zuzugreifen zu können. Die Dokumentation für Treiber oder APIs fällt heutzutage deutlich weniger kryptisch und chaotisch aus und ist weitaus direkter, klarer und verständlicher. Hier mal ein Lob an das Vulkan Team und ganz speziell an Khronos [ Khronos-Group, ein Konsortium verschiedener Hard- und Software-Entwickler, darunter Nvidia, AMD, Samsung, Apple, Qualcomm und viele größere Publisher, die gemeinsam die Entwicklung u.a. von Vulkan vorantreiben], weil die Dokumentation eben so viel treffender ist, quasi auf den Punkt gebracht, sodass man hier schon von einem Nachschlagewerk sprechen kann. Sollte es mal Verwirrung geben, haben wir immer noch die Möglichkeit, mit dem [Khronos- bzw. Vulkan-] Konsortium und anderen Entwicklern zu reden. Das geht soweit, dass man hier schon von einem wissenschaftlichen Diskurs reden kann, um eben zu sinnvollen Lösungen zu gelangen - eine sehr kooperative Atmosphäre. Wenn man mich fragt, ist das eine sehr schöne Weise Software zu machen. Das ist auch einer der Gründe, warum wir uns für die Vulkan-API entschieden haben.

Quelle: PC Games Hardware Doom Eternal (7) PCGH: Ja, das klingt ziemlich einladend und nützlich. Wenn wir Doom Eternal und spezifisch das Ancient Gods-Addon betrachten, funktioniert euer Ansatz und eure Philosophie offensichtlich auch sehr gut. Doom Eternal sieht wirklich ziemlich nett aus und bezüglich der Performance gibt es beinahe nichts Vergleichbares, trotz des Umstands, dass in Doom Eternal - und vielleicht nochmals betont in Ancient Gods - so viele Details enthalten sind und dazu hochauflösende Texturen und aufwendige Effekte. Es ist also vielleicht ein bisschen viel verlangt, danach zu fragen, aber wie habt ihr das gemacht? Vielleicht kannst du beispielsweise ein wenig näher ausführen, wie ihr es geschafft haben, die Draw Calls zu erhöhen, beziehungsweise den Performance-Verlust durch einen Draw-Call-Overhead zu minimieren. Doom 2016 lief ja schon hervorragend, aber Doom Eternal ist nochmal eine andere Sache, wegen der ganzen Details und der viel größeren Umgebungen.

Billy Khan: Wir begannen den Prozess mit der id Tech 6 Engine. Nachdem wir von Open GL auf Vulkan umgestiegen sind, haben wir zunächst natürlich die Engine modernisiert und dann kurz nach dem damaligen Release mit der neuen Vulkan-API rausgebracht. Das war wirklich aufregend, einhergehend mit einer sofortigen Leistungssteigerung, was uns erlaubte Dinge expliziter und direkter zu bewerkstelligen. Die Zusammenarbeit mit AMD und Nvidia war erstaunlich gut und die Arbeit mit diesen Teams und der Versuch, das Spiel auf den Weg zu bringen, hat wirklich Spaß gemacht. Darauf blicken wir immer wieder zurück und erinnern uns gern daran, wie fantastisch gut das gelaufen ist.

PCGH: Ja, daran können wir uns auch gut und gern erinnern. Die Performance in Doom 2016 verdoppelte sich mit Vulkan teilweise.

Billy Khan: Ja, genau, das war schon sehr beeindruckend. Für uns war das aber eher so: "Das ist erst der Anfang und nur die Spitze des Eisbergs." Wir hatten zu diesem Zeitpunkt immer noch auf die alte Art gecodet und deswegen im Grunde den alten OpenGL-Pfad beibehalten, während wir gleichzeitig auf Vulkan umgestiegen sind. Als wir dann schließlich zur iD-Tech 7 Engine gewechselt sind, war für mich klar: Open GL kann weg. Alle sagten damals nur: "Oh, nein, was sollen wir jetzt tun?" sodass ich erwiderte, "Naja, wir schreiben einfach alles neu. Das Spiel, unsere Tools... nur eben dann in Vulkan". Große Fragezeichen in der Belegschaft, aber ja, so war es.

Wir fingen also an, all unsere Tools in Vulkan umzuschreiben, wie beispielsweise id Studio, mit dem wir die Spielewelten bauen. Eine Sache, über die wir damals gesprochen und die wir hier schon angerissen haben, war natürlich die enorme Leistungssteigerung. Das trifft auch auf unsere Tools zu. Man kann mit Vulkan viel mehr zum gleichen Zeitpunkt auf einen Schlag realisieren bzw. rendern, weil eben die Performance höher ist. Wenn ich als Artist beispielsweise einen Partikeleffekt auf dem einen Bildschirm bearbeite, kann ich in einem anderen Fenster im selben Moment die Welt rendern lassen oder in einem weiteren Fenster ich direkt Assets einfügen. Man sieht in mehr oder weniger in Echtzeit, was man gerade editiert und dank Vulkan ist die dazu nötige Performance da.

Beispiel: Man hat den Partikel-Editor, der Partikel simuliert, während das Spiel läuft, während man zusätzlich Materialien simulieren lässt. Man muss das so sehen: Dieser neue Workflow spart Zeit, die man dann in den Polishing-Prozess investieren kann. Diese Zeitersparnis ist wirklich entscheidend, denn wir sind ein verhältnismäßig kleines Team zu anderen Studios und wir wollen natürlich möglichst effizient beim Erstellen von Content sein. Es geht ja nicht nur um die Zeit, die man beim ersten Mal einspart, sondern man bearbeitet beispielsweise ein Asset ja immer und immer wieder, verfeinert es, bis es wirklich perfekt ist.

Quelle: PC Games Hardware Doom Eternal (2)

Wir machen das natürlich mit allem, mit unserem Spielcode, mit unserer Game Art, mit den Animationen und auch mit unseren Software-Tools. Schlussendlich kann man so die Iterationsschleife verbessern und möglichst viele Reibungspunkte vermeiden oder verringern. Die durch Vulkan erhöhte Effizienz unserer Tools erlaubt durch die Zeitersparnis wiederum, dass wir wiederholt über unsere Arbeit schauen und sie mit jeder Iteration noch ein wenig mehr verbessern können. Denn je mehr du an deinem Produkt arbeiten kannst, desto besser, optimaler, effizienter, fehlerfreier und stabiler wird es - das ist also fast schon so etwas wie in der Polishing-Phase, nur fangen wir damit schon gleich zu Beginn der Entwicklung an. Ich würde fast sagen, dass die größten Gewinne in der Spieleproduktion aus ebenso einer Polishing-Phase stammen. Es ist nicht so, dass die erste Umsetzung fantastisch ist. Klar, sie bringt uns auf den Weg, aber erst das Polishing erlaubt, ein Spiel zu etwas Besonderem zu machen.

Deshalb versuchen wir auch unseren Code so einfach wie möglich zu halten. Wenn Sie sich beispielsweise den Code für das alte Doom ansehen, der Open Source ist, oder den BFG-Code auf GitHub, sehen Sie, wie einfach dieser gestrickt ist. Ziel ist es, den Code so simple wie möglich zu halten. Die Abstufungen liegen in der Einfachheit und viele Leute schauen auf den Code und sagen dann: "Wow, das ich hätte nicht erwartet, ich dachte das wäre komplexer". Aber nein, wir verzichten bewusst auf Komplexität, weil wir immer in der Lage sein wollen, einfach so in den Code einzutauchen und ihn bei Bedarf zu überarbeiten.

Wenn ich oder ein Teamkollege eine Idee hat, möchte ich mich nicht mit einer komplexen Code-Monstrosität herumplagen. Stattdessen will ich in der Lage sein, ohne Umwege in den Code zu gehen und dort dann entweder chirurgisch ein Detail einzufügen, das sehr explizit ist, oder ich nehm das alte Stück Code und werfe es einfach raus. Genau das erlaubt uns, sehr schnell Änderungen vorzunehmen, was sicherlich auch eine unserer Stärken ist, und dabei spielt es keine Rolle, an welchem Zeitpunkt man sich in der Produktion befindet. Wir sind sehr vorsichtig aggressiv - ich weiß nicht, wie ich es sonst umschreiben soll - aber wir gehen ein sehr kalkuliertes Risiko ein, eben, weil wir mit dem Code so vertraut sind. Und gerade weil unser Code so simpel gestrickt ist, können wir größere Risiken eingehen.

Genauso ist das Experimentieren superkritisch und damit extrem wichtig. Es gibt ein altes Sprichwort, das besagt, dass man ein Omelett nur dann zubereiten kann, wenn man vorher ein paar Eier zerbrochen hat. Das stimmt natürlich und es ist genauso beispielsweise beim Skateboard fahren: Nur wer hinfällt, wird schlussendlich besser im Skaten. Man geht Risiken ein, fällt hin und lernt daraus - warum ist man gefallen, welchen Fehler habe ich gemacht? Vor dem Hinfallen darf man keine Angst haben, denn die besten Leute im Skaten haben tausende, wenn nicht gar zehntausende Male den Boden geküsst und haben jedes Mal etwas daraus gelernt. Und das ist genau der Moment, wenn man über sich hinauswächst: Wenn sich, nachdem man gestürzt ist, wieder aufrappelt und beherzt weitermacht. Genau wie im Beispiel mit dem Skateboard, darf man bei Software keine Angst haben, Änderungen vorzunehmen. Das ist genau der Ansatz, den wir hier bei id Software verfolgen: Wir halten alles sehr simpel, sehr nuanciert und leicht zu verfolgen. Auf diese Weise könnt ihr, wenn ihr den Check-Ins in unserer Quellcode-Datenbank folgen, direkt nachvollziehen und verstehen, wie sich Dinge ändern, wenn ihr diese oder jene Veränderung vornehmt.

Selbst durch bloßes Zuschauen lernt man bereits, wie der Code funktioniert - wie unsere Mitarbeiter. Auch wenn man nur mitließt und man die Veränderungen nach und nach sieht, man wird mit dem Code vertrauter. Wenn man dann mal tatsächlich daran arbeiten muss, hat man bereits das Gefühl, schon davor damit gearbeitet zu haben. Habt ihr stattdessen komplexe, undurchsichtige Systeme, wird das Ganze natürlich deutlich anspruchsvoller.

Ein weiterer Punkt: Denkt an Spezialisten, die auf spezifischen Einsatzgebieten - allerdings auch nur dort - sehr viel Erfahrung mit sich bringen. Wir glauben eher an Generalisten. Natürlich braucht jeder etwas, in dem er wirklich gut ist. Darüber hinaus gehend ermutigen wir unsere Programmierer, Grafiker und Artists, sich auch mit jeweils anderen Aspekten auseinanderzusetzen - also beispielsweise ein Programmierer, der sich neben seinem spezifischen Job auch mit Grafik oder Level-Design beschäftigt. So bekommen wir dann ein breites Spektrum an Wissen und Können, was wir natürlich in all diesen verschiedenen Bereichen fördern. Schlussendlich wird so insbesondere die Wissensbasis für die Programmierer breiter, weil es Überschneidungen gibt und wir uns gegenseitig helfen können. Wir können aber auch unterschiedliche Perspektiven einbringen und andere Denkweisen, was im Endeffekt unseren Code besser macht. Die Vielfalt des Denkens ist nicht nur super wichtig, sondern auch eines der besten Dinge, die uns passieren kann. Außerdem ist es eine sehr wissenschaftliche Herangehensweise, denn auch wir stellen, genau wie ein Wissenschaftler, erst einmal eine Hypothese auf, die andere dann in einem Peer-Review versuchen zu verstehen und dahinterzukommen, wie all das funktioniert. Es ist ein extrem positiver Ansatz, verschiedene Denkprozesse zu vereinen und das Beste rauszuholen. Denn genauso erhalten wir mehr Möglichkeiten, das Problem aus unterschiedlichen Perspektiven zu betrachten. Je mehr Personen ein Problem betrachten, desto nuancierter und präziser wird die Lösung sein.

Quelle: Bethesda Doom Eternal (4)

Das ist natürlich nicht nur auf den Code beschränkt, das machen wir bei allem tun, bei den Artworks, beim Design, beim Gameplay und auch bei unserer Software. Aber zurück zum Code: Seit der id-Tech-5-Engine, aber auch wenn man sich all den davor produzierten Code ansieht, nutzten wir immer sehr wenige Shader. Das war und ist eine bewusste Entscheidung, denn wir wollten die größtmögliche Wiedergabegüte mit der geringsten Menge an Code, der das dann eben ermöglicht.

Ich glaube mich zu erinnern, dass wir im kompletten Doom 3 vielleicht 20 Shader nutzten. Im Laufe der Zeit erwartet man dann, dass es zu einer massiven Steigerung diesbezüglich kommt und man sich mit zigtausend Versionen eines Shaders herumplagen muss. Natürlich kann man das so machen, aber ich denke, dass es schlicht und ergreifend nicht besonders gut skaliert. Das Ganze wird dann bloß unnötig kompliziert, sodass man nicht mehr dahinter steigt und versteht, wie die einzelnen Elemente des Codes jetzt zusammenarbeiten. Man kann außerdem nicht mehr vorhersehen, was eine Veränderung bewirken könnte oder es ist schwer erkennbar, welche Auswirkungen eine Manipulation nach sich zieht oder ob das Resultat so bedeutend ist, wie angedacht. Will man bei solch einer Herangehensweise beispielsweise die Beleuchtung ändern, muss man dann gefühlt 50.000 Dateien anpassen.

Wir verfolgen einen einheitlichen Ansatz für Beleuchtung und Schatten, sodass jeder einzelne Shader den gleichen Code-Pfad durchläuft. Wir haben unsere eigene Shading-Sprache, die sehr an die alte HL oder HLSL (High Level Shader Language) erinnert. Es sieht ein wenig wie altes CG von Nvidia aus, aber das ist dann nicht das Endresultat, weil wir es später mit einer Übersetzungseinheit in unserem Code transkodieren. Damit übersetzen wir unseren Code in all die verschiedenen Programmiersprachen, die es auf den unterschiedlichen Systemen gibt. Dieser Compiler ist unser eigener Code und wenn man sich den genauer ansieht, tauscht das Tool quasi bestimmte Teile lediglich mit anderen aus. Der Compiler ist so einfach gestrickt, dass man annehmen könnte, jemand aus der High School hätte den geschrieben. Natürlich ist das nur der Anschein, der Code ist eigentlich viel komplexer.

Manche würden wohl behaupten, es wäre hässlicher Code - wahrscheinlich haben die damit sogar recht. Die Stärke in dem bisschen Code liegt aber wo anders, denn wenn neue Funktionen hinzukommen, kann man mit dem Tool diese einfach hinzufügen. Nehmen wir mal an, es gibt ein neues Feature, das in OpenGL oder Vulkan neue Funktionen einführt, die man dann in den Shadern einsetzen kann. Wir fügen es einfach mit unserem Tool hinzu und voilà, das Spiel unterstützt das Feature nun vollständig. Shader-Sprache sieht wie ganz normaler Code aus, man muss also nichts Spezielles schreiben, was dann nur mit PSL, PsSL, HLSL oder GSS funktioniert. Wir schreiben unseren Code und er dann wird noch mit unserem Tool transkodiert, sodass der Programmierer sich am Ende nicht mehr darum kümmern muss. Natürlich gehen wir nochmal über das Ergebnis, fangen mit debuggen an, denken darüber nach, was man verbessern könnte und stellen sicher, dass der Compiler auch das Richtige getan hat. All das passiert immer noch, aber der Denkprozess und das Verständnis geht alles über diese eine Art des Codings. Schlussendlich wird dann noch alles bis zu den einzelnen Programmiersprachen kompilieren. Das gibt uns Flexibilität, neue Funktionen ganz einfach zu implementieren.

PCGH: Man könnte also beispielsweise ganz einfach Raytracing implementieren?

Billy Khan: Ähm, ich denke, Raytracing ist momentan noch ein zu großes Thema, lasst uns lieber von einer Erweiterung sprechen, die neue Features mitbringt, aber nur auf einigen wenigen System verfügbar ist. Mit unserem Ansatz kann man dieses Feature ganz einfach hinzufügen, ohne dass man sich weitere Gedanken darüber machen müsste, was mit dem anderen Code passiert. Es erlaubt uns, neue Funktionen schnell hinzuzufügen, was sehr vorteilhaft ist.
Aber zurück zum Ausgangspunkt: Unsere Shader nutzen nur sehr wenige Render-Pipelines. In so einer Pipeline ist alles, was der Renderer braucht, beispielsweise alle Informationen, Ressourcen und natürlich die Shader selbst. Früher hat man an so einen Shader an die entsprechenden Ressourcen gebunden und jetzt muss man einen bestimmten Render-State-Call durchführen, alles für die GPU einrichten und vorbereiten und dann kann ich erst alle Texturen einbinden. Nun, jetzt machen wir das mit den Deskriptors für die Texturen und innerhalb der Pipelines ist im Grunde alles schon voreingestellt. Die Render-Pipeline umschließt also im Grunde alles Wichtige wie eine Kapsel und mit diesem Ansatz geht es tatsächlich so einfach, dass man diese Kapsel im Prinzip komplett in einem Stück nehmen und direkt mit dem Command Compiler in die GPU schieben kann, sodass auf der Treiberschicht keine Arbeit verrichtet werden muss.

Wenn man sich all unsere Shader und all die verschiedenen Nutzungsmöglichkeiten ansieht, dann haben wir vielleicht 500 Pipelines und 97 Prozent was man auf den Bildschirm gerendert wird, wird vielleicht von fünf Shadern bewerkstelligt. Nun sind diese Shader sehr komplex, sehr nuanciert. Aber die Sache ist die: Wenn ich eine Änderung vornehme, dann weiß ich, dass das höchstwahrscheinlich eine große Wirkung nach sich ziehen wird. Wenn ich eine Optimierung vornehme, wenn ich den Registerdruck senke, wenn ich die Vgp-Stunden senke, wenn ich die Occupancy des Shaders optimiere, dann sehen wir eine sofortige Verbesserung in Sachen Geschwindigkeit und wir können das sehr leicht messen. Wir können das beobachten, denn während wir die Shader kompilieren, kann man gleichzeitig überprüfen, was die Treiber tun. Es erlaubt es uns, unser Spiel stabil zu halten während wir uns gleichzeitig mit über die Zeit verbessern. Und gerade bezüglich Raytracing - da ihr es ja eh schon angesprochen habt - glauben wir, dass weniger Shader besser sind. Mit unserem Ansatz wird das deutlich besser laufen, weil wenn ein Strahl sich im Raum fortbewegt und mit einem Material interagiert, dann will man davon keine 50 Versionen haben.

PCGH: Ein Beispiel für diesen spezifischen Umstand wäre also vielleicht ein Shader, den man nach dem eigentlichen Rendern der Szene nochmal laufen lassen müsste, um beispielsweise bestimmte Materialeigenschaften innerhalb einer Raytracing-Reflexionen korrekt darzustellen, richtig?

Billy Khan: Ja, definitiv. Das macht es das Ganze auch viel schwieriger, wenn man das schnell laufen lassen will. Es ist also viel einfacher, wenn bereits alles im Cache ist. Die GPU denkt sich dann auch "Oh, die Reflexionen auf dem Material sind quasi das Gleiche, was ich bereits im Cache habe." Und schwupps, die GPU ist startklar. Es wäre in unserem Fall dann also nicht so, dass die GPU nach Shader 5.000.000.000.027 suchen, dann noch für die Texturen in einer Hash-Tabelle nachsehen und sie dann natürlich auch nochmals in den Speicher laden muss. Letzterer Umstand macht das ganze Unterfangen langsam und da kommen dann auch zusätzliche Latenzen zustande. Die mag man einzeln als Mensch vielleicht nicht wahrnehmen, aber am Ende vom Lied summieren sich eine ganze Reihe dieser kleinen Verzögerungen. Passiert das ein oder zwei Mal, dann wird das Spiel davon nicht langsam oder gar schlecht laufen. Aber wenn sowas ständig passiert und man eine Menge angesammelt hat, dann war es das für das smoothe Gameplay. Tastsächlich laufen die meisten CPUs in Spielen sogar wesentlich langsamer als sie könnten, weil der Speicher falsch adressiert wurde, beziehungsweise die Register Pressure nicht geschickt gehandhabt wurde und es daher bei der CPU zu speicherabhängigen Latzenzen kommen kann.

PCGH: Das ist tatsächlich ein guter Punkt, denn wir wollten eh ein wenig über Grafikspeicher und Speicher im Allgemeinen reden. Doom braucht ziemlich viel Speicher, aber es ist dabei ziemlich stabil und bleibt auf einem Level, der Speicherhunger steigt also nicht oder nur geringfügig während des Spiels. Ihr habt also offensichtlich an der Speicherverwaltung Hand angelegt oder vielleicht spezifisch für Grafikkarten optimiert, weil euch die Vulkan-API ja dazu befähigt. Vielleicht kannst also etwas über den Grafikspeicher und den Arbeitsspeicher des PCs sprechen, weil es da ja ziemlich anders abläuft als beispielsweise bei den Konsolen.

Billy Khan: Klar, am PC habt ihr natürlich den Arbeitsspeicher und den VRAM auf eurer Grafikkarte. Eins, was man immer vermeiden will, ist das einem der VRAM ausgeht. Denn wenn der Treiber oder auch WDDM (Windows Display Driver Model - betrifft auch Vulkan) sagt: "Moment, den Speicher brauche ich aber", was soll er dann machen? Genau: Der Treiber oder WDDM holt sich den fehlenden Speicher dann aus dem System-RAM und urplötzlich fällt die Leistung massiv ab. Das will man natürlich nicht, deshalb bin ich der Ansicht, man sollte die Speichergröße auf einer Grafikkarte immer mit in die Kaufentscheidung einschließen. Man kann eine fantastische Karte haben, die wunderbar ALU und Floating-Point-Berechnungen durchführen kann, aber am Ende ist die Speicherlatenz ein Problem. Eigentlich war das schon immer so, nicht wahr? Wie kann man das was man brauch schnell in den Cache einlesen und dann ohne Umschweife darauf zugreifen? Wir schlagen uns schon lange mit Bandwith-Problemen auf der GPU herum. Oft wartet man nur darauf, dass alles endlich aus dem Speicher in die GPU gelangt. Wir versuchen diese Kosten zu minimieren, weshalb es für uns offensichtlich notwendig war, viel mehr zu streamen. Je nachdem, welche Einstellungen vorliegen, haben wir dafür jetzt dedizierten Speicher, quasi einen Brocken Speicher, der nur dafür dann abgestellt wird (Pool Size).

Dann haben wir auf der Streamer-Seite einen zusätzlichen Pool mit dem World Geometry Manager, wo im Grunde jedes einzelne Stückchen Geometrie vorliegt, egal ob es sich dabei um Partikel oder die statische Geometrie handelt oder was auch immer da im Pool drin ist. Wenn wir also Geometrie streamen, können wir etwas hinzufügen und defragmentieren dann das Ganze noch während des Betriebs. Und das Defragmentieren ist wichtig, weil es manchmal vernachlässigt wird, wenn man einen Haufen kleinerer Locations hat. Wenn man die dann entfernt, hat man plötzlich lauter kleine Löcher im Speicher, in die ein großer Block nicht mehr hinein passen würde, obwohl der insgesamt freie Speicher ausreichen würde. Also müssen wir das defragmentieren und deshalb defragmentieren wir auch unsere internen Tools in der Laufzeitumgebung ständig und das alles muss extrem schnell gehen.

Quelle: Bethesda Doom Eternal (3) PCGH: Ja, das können wir uns gut vorstellen.

Billy Khan: Wir machen das für Image-Streamer und Geometrie-Streamer, unseren GM-Caches usw. Quasi für alle Systeme, die speicherintensiv sind, verwenden eine dynamische Defragmentierung während des Betriebs. Nun, das klingt beängstigend, aber der Pay-off ist enorm. Das Spiel muss extrem schnell sein, man will kein Ruckeln oder Dergleichen wahrnehmen. Deswegen stellen wir sicher, dass alles rund läuft, indem wir die Defragmentierung einplanen. Wir haben also diese großen Pools, mit den Geo-Streamern, die eine bestimmte Menge an Speicherplatz für die unterschiedlichen LODs zugewiesen bekommt. Denn ist dieser Pool zu knapp oder defragmentiert ist, kann es sein, dass große, umfangreiche Geometrie verspätet nachlädt - eben dann, wenn die Geometrie wieder genügend Platz im Speicher findet. Und Popins will man natürlich nicht. Im schlimmsten Fall, also wenn der Pool des Geometrie-Streamers nicht ausreicht, kann die gesamte Geometrie nicht mehr korrekt angezeigt werden und können sich sogar Löcher in der Spielewelt auftun.

PCGH: Ein Beispiel das mir hierzu einfällt, ist Horizon Zero Dawn - es gibt natürlich viele mehr. Wenn man bei HZD mit einer GTX 970 und hohen Einstellungen und Auflösungen nutzt, dann fehlt bisweilen die ganze Geometrie und ploppt dann nach und nach ins Bild.

Quelle: PC Games Hardware Horizon Zero Dawn mit unpassenden Grafikeinstellungen: Die genutzte GTX 970 hat nicht ausreichend Grafikspeicher, nicht nur höher aufgelöste Texturen fehlen, sogar die Geometrie passt nicht in den schmalen Grafikspeicher.

Billy Khan: Es ist ein schwer zu lösendes Problem, vor allem, wenn man große, offene Welten hat, die vollgestopft mit komplexem Dinge sind und alle Speicherplatz benötigen. Es ist also ein Problem, mit dem jeder zu kämpfen hat, auch wir haben damit zu kämpfen. Ein anderes Problem ist, sagen wir mal in unserem Fall: Wenn an einigen Stellen Geometrie fehlt oder wegen Speichermangel ausfällt, kann das zu weiteren Problemen mit dem Culling führen. Denn jetzt haben wir ein riesiges Loch da und das kann dann unserem Verdeckungssystem sagen: "Hey, man muss hier was sehen können, denn da ist da ein Haufen Zeug dahinter" und schwupps, geht das ganze Performance hops, auch wenn beim Spielen oder beim Betrachten im Editor gar nicht zwingend auffallen muss, weshalb dem so ist. Wenn irgendwo ein noch so kleines ein Loch beispielsweise in einer Mauer ist, und das Culling-System denkt, es müsste deshalb die gesamte Geometrie dahinter ebenfalls anzeigen, kann es je nach Umstand sein, dass ein riesiger Part des Levels mitberechnet wird, obwohl man es nicht oder nur an einer sehr spezifischen Stelle sehen kann.

So ein Loch kann also schlussendlich dafür sorgen, dass mehr Daten in den Speicher geladen werden müssen, als eigentlich nötig. Wir haben eine Menge Werkzeuge, um dieses Problem anzugehen- Beispielsweise haben wir die Möglichkeit, die Spiel-Kamera zu sperren, während wir die Szene und all die geladenen Daten frei betrachten können. Im Grunde genommen werden damit die Streamer angehalten, sodass erst einmal nichts aktualisiert beziehungsweise neu geladen wird. Wenn man dann aber in der Welt herumfliegt, zeigt die Kamera, was das Team da im Endeffekt gerendert hat. Nicht nur Programmierer, sondern wirklich alle nutzen das Tool, um die Ansicht sperren zu können. Wir haben Werkzeuge, um eben solche Löcher aufzuzeigen, die müssen nicht mal zwangsläufig wegen eines Streaming-Problems zustande kommen. Vielleicht liegt es an der Art und Weise, wie das Level konstruiert wurde. Es ist also nicht nur Streaming-bedingt, aber das Verdeckungs- bzw. Culling-System kann dadurch beeinträchtigt werden. Mit unseren Tools können wir diese Löcher aufspüren und dann packen wir da einfach ein Volume (einen beliebigen 3D-Körper) hinein.

Auf der Image-Streaming-Seite machen wir genau das Gleiche, aber auf der Texturseite laden wir immer zuerst die niedrigsten MIPS in den Speicher. Wenn ich also ein Level lade, wir laden zunächst immer die niedrigsten und kleinsten Texturen, sodass wenn es dann mal nicht da sein sollte oder der Speicher des Image-Pools nicht ausreicht, man wenigstens irgendwas sieht. Dann erhöhen wir lediglich die Auflösung und die Ladegeschwindigkeit der MIPS, wir defragmentieren das natürlich ebenso. Die Metrik, die wir benutzen, um zu bestimmen, welche MIPS geladen werden sollen, ist auch interessant, weil wir die LoDs berücksichtigen müssen. Wir wollen die Texture-Auflösung und das LoD-Switching normalisiert, sodass es für den Spieler nicht wahrnehmbar wird. Der Doom Slayer läuft ja sehr schnell, man kann schon fast sagen, es ist, als würde man ein schnelles Auto fahren.

Und wir wollen nicht, dass dann irgendwas reinpoppt, wenn man da mit einem Affenzahn durch das Level rast. Im Grunde schaut man ja die ganze Zeit mit den Augen in die Mitte des Bildschirms und da will man nicht in der peripheren Sicht sehen, wie Gegenstände auftauchen. Gerade weil man so schnell läuft und der Kampf so schnell ist, man sich zudem mit der Maus so schnell umdrehen kann und Dergleichen müssen wir nach Möglichkeit auf null Pop-Ins bestehen. Weil die Texturen und Co mit einem LoD-Wechsel so schnell wie möglich gestreamt werden, wollen keine aufploppenden Assets sehen. Wir wollen, dass die Pixeldichte und die geometrischen Details normalisiert werden. Wenn man im Spiel dann an hochauflösende Texturen vorbeirauscht, neben denen nur Low-Res möglich ist, nimmt man das dennoch wahr. Man weiß zunächst nicht, was falsch an dem Bild ist, aber man merkt, dass etwas nicht stimmt. Man denkt sich nur, die Grafiken sind wieder reingeploppt. Vor allem, wenn es sich um Silhouetten mit geometrischen Details handelt. Also versuchen wir die Details der Silhouette so weit wie möglich zu erhalten. Das ist also ein superkritisches Kriterium, denn wenn beispielsweise die Hörner unserer Dämonen plötzlich verschwunden oder deformiert sind, dann bekommt man das als Spieler sofort mit. Die Silhouette ist also sehr wichtig und wir versuchen sie zu normalisieren. Wir versuchen das wirklich so hinzubekommen, dass man die Silhouetten der unterschiedlichen LoDs nicht unterscheiden kann. Manchmal klappt das ganz gut, manchmal nicht. Ich denke, wir haben auf allen Plattformen ziemlich gute Arbeit geleistet, denn die Heuristiken, die wir verwenden müssen, sind wegen der verschiedenen Plattformen leicht unterschiedlich.

Quelle: PC Games Hardware Red Dead Redemption 2 mit GTX 970 in Ultra HD und per Ini deaktivierter Speicherbeschränkung - ein konstruiertes Szenario, doch hier passt nicht einmal mehr das Geometrie-Streaming in den Speicher der Grafikkarte. Ebenso ist die Texturdarstellung kompromittiert. PCGH: Wenn ihr also die Silhouette der Modelle erhalten wollen, dann reduziert euer LOD die Polygone also vorzugsweise innerhalb des Modells, wo es weniger offensichtlich ist?

Billy Khan: Ja, genau. Wir wollen die Form beispielsweise dieser vertikalen Schulterplatten des Mauraders erhalten, also diese abgerundete Form beibehalten. Aber die inneren Details sind dann etwas reduziert. Die Kanten und das, was den Maurader so einzigartig macht, das wollen wir erhalten. Euer Gehirn macht dann den Rest und füllt den Low-Res Maurader mit Details auf, wenn ihr sie schon einmal gesehen habt. Das Gehirn erinnert sich an die Informationen und gibt sie weiter, obwohl sie eigentlich - wegen dem Low-Res - gar nicht existieren und wir versuchen, das auszunutzen.

PCGH: Das ist ziemlich schlau, das menschliche Gehirn so auszutricksen - beziehungsweise eigentlich trickst es ja uns selbst aus; es erinnert sich an viele Umstände und kann diese rekonstruieren und gerade was Bewegungen angeht, kommt es da ja zu einigen durchaus interessanten Wechselwirkungen mit dem menschlichen Sehen. Das könnte eigentlich ein guter Punkt für eine weitere Frage sein, der in dieser Hinsicht interessant ist. Also: Da sind ziemlich viele temporale Effekte in Doom und Doom Eternal. Vielleicht kannst du uns ein wenig darüber erzählen, denn ich glaube, euer temporal Super-Sampling war einer der frühesten wirklich guten temporalen Anti-Alias-Ansätze. Es war definitiv eines der besten TAAs zu jener Zeit (Doom 2016), wenn nicht sogar das Beste. Vielleicht kannst du uns und unseren Lesern ein wenig erläutern, warum temporale Effekte in aktuellen Spielen so wichtig sind und mit den kommenden Konsolen und Raytracing wahrscheinlich noch wichtiger werden.

Billy Khan: Im Grunde geht es darum, dass man ein Problem in kleinere Schritte zerlegt und vielleicht muss man all diese Schritte nicht im gleichen Frame erledigen. Mit den Daten aus früheren Einzelbildern können wir eine Bildqualität erreichen, die das Gehirn wiederum dazu bringt, Dinge zu sehen, die nicht da sind. Das ist für die Performance sehr wichtig, um die Leistung zu erreichen, die wir haben wollen. Denn das Spiel soll mit mindestens 60 Bildern pro Sekunde auf allen Plattformen laufen und natürlich gleichzeitig auch noch eine hohe Bildqualität vorweisen. Also einige dieser Prozesse, um sie wirklich schön aussehen zu lassen. Vor allem Anti-Aliasing ist ein großes Problem: Wenn man viele und feine geometrische Details hat - und wir haben davon einige - dann wird Aliasing ein großes Problem, insbesondere, wenn man noch unterschiedliche LoDs einführt und gleichzeitig auch noch die Silhouette erhalten bleiben muss. Man will auf keinen Fall Pixelflimmern sehen, weswegen wir zur Lösung unsere Bewegungsvektoren hinzuziehen und diese über mehrere Frames zerlegen, weil wir eben Informationen erzeugen müssen, die es vorher nicht gab.

Das kann man mit vielen Dingen machen, es gibt viele neue Techniken, die das so machen. Beispiel wäre etwa das maschinelle Lernen, das das genauso macht. Deswegen ist maschinelles Lernen auch eines der Dinge, in die wir sehr stark investieren. Für den Verbraucher machen die Auflösungen wie 4k, 1440p und 1080p am meisten Sinn, denn das sind alles fantastische Auflösungen, die erstaunlich viele Details liefern. Worauf wir uns jetzt also konzentrieren wollen, ist sicherzustellen, dass die Pixel, die wir haben, so aussagekräftig wie möglich sind. Das bedeutet: eine bessere Beleuchtung, dass Pixel auf eine Art und Weise von einem Anti-Aliasing geglättet werden, die nicht stört und die Bildqualität nicht beeinträchtigt oder dass wir anfangen, mehr Zeit auf die Simulation von Materialien zu verwenden. Das machen wir also gerade, wir zerlegen diese komplexen Prozesse, um sie zugänglicher zu machen. Das ist ein riesiger Fokusbereich und auch der Grund, warum ML oder neuronale Netzwerke immer wichtiger werden. Wir haben damit schon mit unserer Anti-Aliasing-Lösung begonnen, aber ich kann die Secret Sauce jetzt hier nicht offenlegen.

Quelle: PC Games Hardware Doom Eternal (1)
PCGH: Das ist in Ordnung. Dabei handelt es sich aber um eine Art Vorhersage, sodass es versucht den nächsten Frame zu erraten?

Billy Khan: Je nachdem nehmen wir die Bewegungsvektoren, um die Position der Pixel vorherzusagen. Man hat also die vorherige Farbinformation zur Hand und kann dann vorherzusagen, wie die Beleuchtungssituation in dem nächsten Frame sein könnte. Dadurch weiß man auch, wo man eventuell den Shader anpassen muss und man kann die vorherigen Informationen nutzen, um zu verstehen, wo die Kontur der Silhouette sein sollte. Dann werden in der Anti-Aliasing-Lösung sinnvolle Anpassungen vorgenommen, damit sichergestellt wird, dass die Merkmale den vorherigen Frame auch in der Folgenden beibehalten werden. Wenn man also ein sich schnell bewegendes Objekt hat, dann sieht das durch die Bewegung bereits unscharf, bei anderen Objekten ist das eher weniger wichtig, weil das auch durch das Sehen als solches verwischt wird. Wenn man aber immer auf den gleichen Punkt starrt, während man nach vorne rennt, liegt bereits Information vor. Einmal hat man dann Geschwindigkeit des Charakters zur Hand und das Auge hat beispielsweise schon erfasst, was auf einen zukommt. Wir können dieses Wissen nun nutzen, um im Zeitverlauf zu schauen, wie man das besser machen kann. Der Trick ist, man braucht genug Bilder, denn dann sieht das Ergebnis immer stabil aus.

Man muss also nicht auf die Stabilität warten, die lag bereits vor, weil wir in vorherigen Frames eben alles schon gesehen haben und daraus dann ein stabiles Bild erzeugen können. Dank asynchronen Berechnungen können wir das sogar teilweise überlagern, während die aktuellen Frames gerendert werden. So werden Informationen des nächsten Bildes bereits verarbeitet, obwohl diese noch nicht vorliegen. Ich denke, wir verwenden das für circa 80 Prozent des Bildes. Im Grunde bedeutet das, dass ein Compute-Shader läuft, während die Grafikeinheit etwas Anderes macht und der nächste Frame wird bereits von einer asynchronen Compute-Einheit verarbeitet, während der vorherige Frame gerade gerendert wird. Das geniale daran ist, wenn wir zum Beispiel einen Shader haben, der bandbreitengebunden ist, wenn es darum geht den Speicher einzulesen, aber kaum Alus verwendet: Das kann man dann mit ALU-Aufwand in einem Compute-Shader kombinieren, sodass man möglichst viel rausholt. Während also der Speicherabruf stattfindet, kann die GPU gleichzeitig Berechnungen durchführen. Würden wir auf den Speicher warten, wie etwa in einer einfachen Grafikpipeline, dann würden wir wertvolle Zeit vergeuden.

PCGH: Da wird dann also Performance verschenkt.

Billy Khan: Genau, deswegen schauen wir uns das Frame an und füllen entsprechend die Lücken mit Information. Dadurch lassen wir die GPU fast immer auf Anschlag laufen. Ich glaube, die Auslastung liegt bei 97%.

PCGH: Das ist ziemlich beeindruckend. Um ehrlich zu sein.

Billy Khan: Unser Stromverbrauch ist fast wie eine Nulllinie - immer ganz oben (lacht). Wir ermutigen alle, ihre PCs schön sauber zu halten und dafür zu sorgen, dass sich kein Staub ansammelt.

PCGH: Vielleicht kannst du noch etwas zu maschinellem Lernen erzählen oder welche KI-Ansätzen ihr bei id Software verfolgt. Glaubst du, dass das etwas ist, was in der Zukunft vermehrt in Videospielen vorzufinden ist?

Billy Khan: Ich denke, maschinelles Lernen hat enormes Potential. Man sieht es mittlerweile bei Verbrauchern, also in Produkten und deswegen ist maschinelles Lernen etwas, das wir fördern sollten, vor allem bei der Erstellung von Content. Heutzutage werden bereits viele Scans erzeugt, um Materialien fotorealistisch darstellen zu können, anstatt dass ein Künstler das selbst machen muss. Es kann mit ML also mehr Zeit in die Erstellung des eigentlichen Assets investiert werden, ohne dass man sich Gedanken über das Aussehen von Leder, Stein oder Chrom machen muss. Solche Scans erlauben, dass man sich auf die Präsentation konzentrieren kann, nicht mehr auf das Aussehen, sodass man mehr ins Detail und den künstlerischen Aspekt gehen kann, anstatt sich mit den technischen Begebenheiten zu befassen.

Genau wie beim Scannen von Materialien versuchen wir, anhand von Daten aus der realen Welt beispielsweise die Lippensynchronisation zu verbessern. Mit maschinellem Lernen kann man dann anhand der Performance eines Schauspielers Bewegungen der Lippen an beispielsweise unterschiedliche Synchronisationen anpassen. Es gibt aber noch mehr Anwendungsgebiete, beispielsweise weiß keiner wirklich, wie sich so eine Kreatur in Doom eigentlich bewegen sollte. Sowas kann keiner wissen, denn es gibt sie nicht wirklich. Deswegen behilft man sich, indem man die Bewegungsinformation eines Tieres hernimmt. Jetzt wird das noch mit den Bewegungen eines Menschen über maschinelles Lernen kombiniert. Damit wirkt das einerseits natürlicher, anderseits muss da niemand sitzen und das dann per Hand animieren. Ganz im Gegenteil, man kann das On-the-Fly dynamisch erstellen lassen.

Im Moment machen wir all diese verschiedenen Variationen, bei denen wir zwei Übergangspunkte haben. Das funktioniert dann so, dass - sagen wir ein Pinkie - von hier bis da drüben laufen kann und dann kommt eine Übergangsanimation, aber man musste vorher genau wissen, wie die Mechanik des Charakters funktioniert. Durch maschinelles Lernen wird nun einfach das Skelett und die Muskelstruktur des Pinkie simuliert, sodass es zu einer realitätsgenauen Umsetzung kommt, wenn das Monster von der einen Ecke zur anderen hüpft. Das vereinfacht natürlich die Produktion von Inhalten und reduziert die Zeit zur Erstellung selbiger. Ich denke, wir können mit dem maschinellen Lernen auch bei Anti-Aliasing eine Menge mehr erreichen. Das haben wir bereits bei einigen angewendeten Techniken gesehen. Im Allgemeinen kann man mit ML Materialien besser simulieren und wir sollten unbedingt in so etwas investieren und weiter daran arbeiten. Ich denke, es wird definitiv die Kosten für die Erstellung eines Videospiels reduzieren, aber auch interessante und neue Lösungen zu Probleme bereitstellen, die wir in der Vergangenheit per Trail-and-Error zeitaufwendig herausfinden mussten.

PCGH: Man kann Inhalte also leichter erstellen, aber man hat wahrscheinlich auch eine größere Palette, aus der man wählen und dann mischen kann.

Billy Khan: Ja, richtig. Man kann aber auch die KI trainieren. Nehmen wir an, ein Marauder aus Doom Eternal bekommt die Information, wie Spieler sich selbigen nähern und versuchen ihn auszuschalten. Die KI des Marauders bekommt nun diese Informationen und wird anhand des Data-Sets trainiert. Der Marauder lernt dann und kann entsprechend auf die Aktionen des Spielers reagieren. Er lernt dann weiter, während man spielt und stellt euch eine KI vor, die vom Release an von der Nutzerbasis lernt. Das klingt doch ziemlich cool, oder? Die KI wird also immer besser und besser und damit die KI nicht zu mächtig wird, implementiert man Beschränkungen. Denn wenn die KI mit jedem Ansatz umzugehen weiß, dann wird das Spiel langweilig. Man kann auch Fehler in die KI einbauen, sagen wir, der Marauder ist sehr narzisstisch oder er wird sehr selbstbewusst und trainiert dann nicht mehr. Das ist dann quasi ein Charakterfehler, der durch ML entstanden ist, weil dann eben nicht mehr adäquat auf den Spieler reagiert wird. Das könnte das Spiel vorantreiben und man könnte dann einen Zustand erreichen, wo die gegnerische KI von Spielern, während sie spielen, trainiert wird. Stellt euch vor, ich bin wirklich gut darin, den Marauder zu besiegen, aber echt schlecht, wenn es um Pinkie geht. Irgendwann muss ich als Mensch mich anpassen und dazulernen, nur damit ich dann Pinkie besiegen kann. Irgendwie machen wir das schon bei uns im Spiel, denn wir versuchen den Gameplay-Loop so zu gestalten, dass man alle Waffen nutzt. Das macht es so interessant und fesselnd, dass selbst hier eine Art Ressourcenmanagement vorliegt: Man muss stetig die Waffen wechseln, die Gesundheit im Auge behalten und Glory Kills oder den Flammenwerfer einsetzen, um Lebenspunkte und Rüstung zu generieren. Aber man erlernt auch nach einer Zeit, dass nur bestimmte Waffen für bestimmte Feinde nützlich sind. Die nächste Stufe wäre dann eben, dass die Gegner im Spiel genauso von dir lernen, wie du von ihnen. Dann wird die Spiel-Erfahrung viel persönlicher. Stellen Sie sich vor, Sie spielen ganz schön viel Doom, sodass sich die KI nach einer Zeit auf eine bestimmte Art und Weise verhält. Nun kommt ein Freund vorbei und spielt mit Ihrem Spielstand und hat eine total andere Gameplay-Erfahrung als auf seinem Rechner.

Für mich sind das super spannend. Wie so oft, erinnere ich mich gerne an Skyrim, auch weil es eins meiner Lieblings-RPGs war, als es herauskam. Ich erinnere mich an eine bestimmte Quest, die ich gespielt habe und ein Arbeitskollege von mir sagte: "Oh, diese Quest habe ich auch schon gespielt." Aber seine Erfahrung war ganz anders als meine. Diese Art von bedeutungsvollen Geschichten machen so ein Spiel erst interessant, weil Gaming so ein interaktives Medium ist. Warum gehen wir nicht weiter in diese Richtung und machen Videospiele so persönlich, dass es für jeden Spieler eine andere Erfahrung wird. Darum lieben so viele Menschen RPGs, weil so ein Spiel etwas Persönliches bietet. Und natürlich wird ML und KI auch bei anderen Dingen helfen, wie beispielsweise Raytracing.

Quelle: PC Games Hardware Doom Eternal (5)
PCGH: Eine letzte Frage, die ich Entwicklern gerne stelle: Bist du auf irgendetwas besonders stolz, was ihr bei id Software und Doom oder Doom Eternal erreicht habt?

Billy Khan: Das Ancient Gods DLC ist die nächste Stufe von Eternal. Es fordert den Spieler auf so sinnvolle Weise. Worauf ich besonders stolz bin, dass wir etwas geschaffen haben, das auf Skill basiert, aber dennoch für viele zugänglich ist, aber trotzdem sackschwer bleibt. Wir wollten, dass die Spieler weiterhin Spaß am Spiel haben, weswegen wir den richtigen Waffeneinsatz fördern. Um also Doom und Doom Eternal zu meistern, damit man da wie Bruce Lee auf Steroiden durch die Gegend fliegen kann, muss man eben diese Super-Moves verinnerlichen. Das heißt, man muss genau wissen, wann setze ich eine Double Barrel Shotgun ein, wann die Combat Shotgun und wann den Raketenwerfer? Das sind alles so Meta-Dinge, die man mit entsprechendem Training lernt und die wir eben mit dem Gameplay-Loop fördern, bis das in Mark und Bein übergegangen ist. Durchs Scheitern wird man vielleicht zunächst zurückgeworfen, aber sobald es Klick macht - das ist ähnlich wie beim Skateboarden.

Wenn man dann zum ersten Mal den Ollie gestanden ist, dann sagt man sich nur: "Wow, das war so schwer! Ich habe sechs Monate dafür gebraucht, damit ich es lerne und mir 50 Mal das Knie aufgeschlagen und 27 Mal fast den Knöchel gebrochen - aber die schlussendliche Belohnung war es wert." Man sieht das auch bei anderen Spielen, die es belohnen sich selbst herauszufordern und diesen Task dann auch zu meistern. Nur wenige schaffen es, dass auf eine Art und Weise zu bewerkstelligen, die nicht frustrierend wird, sondern tatsächlich Spaß macht. Das ist eins der Dinge, die wir wirklich gut in das Spiel eingebaut haben. Ich muss Hugo (Anm: Hugo Martin, Game Director bei id Software) dafür an dieser Stelle loben, da er sich die Mechanik dafür ausgedacht hat. Damit das so von Seiten der Engine funktioniert, mussten wir dafür sorgen, dass das Spiel immer mit voller Geschwindigkeit läuft. Da darf es zu keinen Latenzen kommen, das Spiel muss zwangsläufig flüssig laufen! Das ist entscheidend für das Gameplay und das darf man auch nicht unterschätzen: Die Framerate ist für das Spiel, so wie es ist, maßgeblich entscheidend. Und wenn das bedeutet, dass wir einige Effekte zurückschrauben müssen, denn das Spielgefühl lässt sich nur über die hohen Frameraten realisieren.

Die Kombination aus Geschwindigkeit, Grafik und fantastischem Gameplay - quasi eine symbiotische Beziehung zwischen Kunst und Coding - genau auf das bin ich besonders stolz; auch wenn man das als Spieler vielleicht nicht auf Anhieb sehen mag. Ich hoffe aber, dass der Käufer in gewissen Weise das Herzblut dahinter mitbekommt, wie das Team leidenschaftlich daran gemeinsam gearbeitet hat. Am Ende bin ich wahrscheinlich am meisten auf die Zusammenarbeit des Teams stolz, weil wir die richtige Balance zwischen künstlerischer, spaßiger und visuell beeindruckender Arbeit gefunden haben. Auch wenn man das so als Spieler nicht merkt, hoffe ich doch innständig, dass der Käufer spürt wie hochgradig gepolisht das Spiel ist, wie gut es sich spielt und welches Gefühl es erzeugt, wenn man es gemeistert hat. Das mag jetzt vielleicht kitschig klingen, aber man darf nicht unterschätzen was dabei rumkommt, wenn ein Team wirklich effizient zusammenarbeitet. Es ist fast so, als wäre man aufgelevelt, fast so, wie wenn man im Jiu-Jitsu vom weißen zu einem blauen Gürtel aufsteigt. Dieser AH-Moment, hat sich bei diesem Spiel tatsächlich so angefühlt, als würde man eine weitere Tür öffnen, die einem so viel mehr offenbart.

PCGH: Ich glaube auch, dass ihr einen großartigen Job gemacht habt. Vielen Dank! Ich glaube auch, das merkt man an einem ausgefeilt Gameplay, oder daran, dass die technische die Ausführung nahezu perfekt ist. Die Performance frustriert nicht, es kommt also nicht zu Frame Drops in bestimmten Momenten oder so etwas in der Art.

Billy Khan: Das Spiel muss auf jeder Plattform so schnell wie möglich, mit allem was diese Plattform bietet, laufen. Weil wir wollen auch, dass so viele Leute wie nur möglich das Spiel spielen. Ziel ist es, Titel zu produzieren, die in der Branche hervorstechen, aber wir wollen auch etwas bieten, was unterhaltet und fordert. Die Leute sollen mit unseren Spielen einfach eine schöne Zeit haben.

PCGH: Darum geht es doch Gaming und wohl auch beim Game-Design, oder? Vielen Dank für deine Zeit, das war ein sehr interessantes Interview.

Billy Khan: Wir können nächstes Mal gerne mehr über Technik sprechen, wenn Sie wollen. Aber ich hoffe, dass ich Ihre Fragen soweit beantworten konnte.

PCGH: Fürs erste reicht das wohl (lacht), aber wir können sehr gerne ein anderes Mal weiterreden. Wir sind da sehr dankbare Zuhörer.

Billy Khan: Danke euch, dass ihr euch die Zeit genommen habt. Ich weiß es zu schätzen und kann es kaum erwarten, den Artikel zu lesen. Hoffentlich habe ich nicht zu viel geschwafelt.

PCGH: Nein, ganz und gar nicht.

Billy Khan: Ich erkläre gern, wie es ist ein Videospiel zu produzieren, damit mehr Leute ein Gefühl dafür bekommen. Seien wir mal ehrlich: Es ist schwer, bestimmt genauso schwer wie einen Film zu drehen oder ein Auto zu bauen. Aber wenn man eben nicht selbst an der Sache arbeitet, ist es schwer, hinter die Kulissen zu blicken. Die Leute sollen einfach wissen, dass wir hier sehr leidenschaftlich an Videospielen arbeiten. Hoffentlich zeigt das Produkt, wie viel Schweiß und Herzblut in das Projekt geflossen sind.

PCGH: Besten Dank für das Gespräch, bleib gesund und auf eine erneute Begegnung!

Artikel teilen

Vulkan und die Technik hinter Doom Eternal - Interview mit Lead Engine Programmer Billy Khan Zum Erscheinen des ersten Add-ons für Doom Eternal haben wir das Angebot erhalten, uns mit id Softwares Lead Engine Programmer Billy Khan über die Technik des Spiels und die id-Tech im Allgemeinen zu unterhalten. Im umfangreichen Interview packt Billy Details zu der genutzten Vulkan-API, dem Speichermanagement, LoD- und Streaming-Systemen und vielen weiteren interessanten Aspekten aus.

Per E-Mail versenden

15