F: Vielen Dank, dass Sie dabei sind! Das Spiel sieht fantastisch aus! Bitte erzählen Sie uns von Ihren Kernzielen für Star Wars: Galactic Racer™ und worum es in dem Spiel geht.
Andrei Shires, Mitbegründer und Head of Technology bei Fuse Games: Unsere Aufgabe als Technologieteam ist im Prinzip simpel: das bestmögliche Spielerlebnis zu unterstützen. Alles, was wir tun, dient diesem Zweck.
Karl Wickens, Studio Technical Art Director bei Fuse Games: Aus technischer Sicht waren unsere Hauptziele detailgetreue Inhalte und eine filmreife Präsentation, ohne dabei eine konstante Framerate oder flüssige Steuerung zu opfern.
F: Warum wurde die Unreal Engine 5 für dieses Projekt ausgewählt und welche UE5-Funktionen sind Ihnen während der Entwicklung am meisten aufgefallen (und warum)?
Shires: Wir haben zu Beginn mehrere Engines evaluiert. Am wichtigsten war es, eine zu finden, mit der wir rasch einen sehr hohen, konsistenten Standard erreichen konnten, damit wir uns auf die Entwicklung des Spiels konzentrieren konnten und nicht bei Null anfangen mussten, um Kerntechnologien von Grund auf zu erstellen. Die Unreal Engine 5 bot hier die eindeutige Gelegenheit – insbesondere die Art und Weise, wie Nanite, Lumen und World Partition zusammenarbeiten. Diese Kombination war für ein Spiel wie unseres äußerst attraktiv.
Wickens: Wir wussten, dass wir das Team schnell vergrößern mussten, und die Verwendung einer gebrauchsfertigen Engine mit etablierten bewährten Verfahren erleichterte die Einführung erheblich. Es beschleunigte auch unsere eigene Lernkurve und ermöglichte es uns, gekaufte Werkzeuge und Inhalte als Ausgangspunkt für unsere eigenen spielspezifischen Assets zu verwenden.
F. Rennspiele offenbare jede Millisekunde Latenzzeit. Was waren die größten technischen Herausforderungen, um Fahrzeuge bei so hohen Geschwindigkeiten reaktionsschnell zu machen?
Shires: Da gab es einiges. Damit sich ein Rennspiel konsistent und fair anfühlt, muss die Physiksimulation mit voller Framerate laufen, unabhängig von der Framerate des Spiels, und schnell genug sein, um Fahrzeuge zu verarbeiten, die mit extremer Geschwindigkeit fahren – und abstürzen. Wir haben viel Mühe investiert, um diese physikalische Simulation so robust wie möglich zu gestalten, denn alles andere hängt davon ab: Konsistenz, Fairness, geringe Latenzzeit und ein Fahrzeug, das tatsächlich so reagiert, wie du es in einer Kurve erwartest.
Wickens: Eine Sache, die enorm wichtig war – nicht ganz das Rendering, aber angrenzend daran – war die gleichzeitige Verwaltung mehrerer verschiedener „Ebenen“ jedes Levels. Es gibt das Render-Mesh, das hauptsächlich aus Nanite besteht. Es gibt eine separate Kollisionsebene für die Rennsimulation. Und da ist die Lumen-Szene: die 3D-Geometrie, die globale Beleuchtung erzeugt, plus die Fernfeld-Szene dahinter. Während man durch ein Level rast, sind mehrere Datenebenen zugleich aktiv – einige sichtbar, einige nicht, einige beeinflussen die Rennphysik, einige beeinflussen die Beleuchtung. Wir verbrachten viel Zeit damit, die Auflösung jeder dieser Ebenen abzustimmen und zu testen, was tatsächlich wahrnehmbar ist, wenn es aus der Lumen-Raytracing-Szene entnommen wird, um die benötigten Bildraten zu erreichen.
F: Wie hat Nanite es dem Team ermöglicht, hochdetaillierte Assets zu nutzen – einschließlich Fahrzeuge mit Millionen von Dreiecken – und dabei eine flüssige Performance zu erzielen? Welche greifbaren Ergebnisse hat das Team in Bezug auf visuelle Qualität und Produktionszeit erzielt?
Wickens: Nanite war ein echter Paradigmenwechsel von der alten LOD-basierten Welt, in der man das Dreiecksbudget für jede Detailstufe eines Assets sorgfältig ausgewählt hat. Mit Nanite stellt man eine feste hochauflösende Version bereit und lässt sie dynamisch so viele Dreiecke auflösen, wie die Szene benötigt. Der alte LOD-Ansatz ist teuer in der Produktion und, da LODs in festen Bändern funktionieren, ist er von Natur aus verschwenderisch – er gibt in jedem Band einen Sweet Spot, an dem Details richtig aussehen, und eine Strecke auf beiden Seiten, bei der man nicht die Qualität erreicht, die man hätte bekommen können. Nanite hat auch das „Popping“ beseitigt, das man erhält, wenn Assets zwischen LOD-Bändern wechseln, da es Details stattdessen flüssig auflöst.
Die Wiedergabetreue-Gewinne waren auch an einigen unerwarteten Stellen greifbar. Unser Head of Content ist immer noch begeistert, dass wir direkt Material aus den Fahrzeug-Assets im Rennen für Nahaufnahmen im Marketing ziehen können, ganz ohne zusätzliche Modellierungsarbeit. Dieselbe Assets hielten als Filmsequenz-Requisiten stand, und im Fotomodus kannst du ganz nah heranzoomen und siehst immer noch die Details – ganz ohne die Popping-Artefakte, die LODs früher verursachten.
Die Produktionszeit ist eine interessante Geschichte. Die alte LOD-Pipeline ist ein bisschen wie das Handfertigen von Mobiliar. Jeder Schnitt zählt: Jede Kantenschleife muss sich ihren Platz in einem winzigen Dreiecksbudget verdienen. Nanite nimmt einen Großteil dieses technischen Overheads weg. Er ist immer noch da, nur deutlich reduziert, was die Arbeit für mehr Künstler zugänglich macht und sie schneller vorankommen lässt.
Shires: Dem würde ich zustimmen. Die größte Veränderung, die ich gesehen habe, ist, dass ein Level oder Fahrzeug zugleich gut aussehen und mit einer guten Framerate laufen kann. In der alten Pipeline bekam man wunderschöne Meshs herein und die Framerate sank sofort, bis die LODs fertig waren, so dass man „wie das Spiel aussehen wird“ und „wie das Spiel gespielt werden wird“ als zwei getrennte Momente sah, die Wochen auseinander lagen.
Mit Nanite hatten wir schon früh in der Entwicklung Assets, die überhaupt nicht optimiert waren und eine gute Bildrate boten. Da liegt für mich der eigentliche Wandel. Nicht, dass das Spiel besser aussieht – ich denke, wir hätten auch mit LODs eine ähnliche Grafikqualität erreichen können – sondern es geht darum, wie viel schneller wir an diesem Erlebnis arbeiten konnten: Und je öfter wir bei Fuse den Iterationszyklus durchlaufen, desto besser wird unser Spiel.
Wir haben sogar ein Sternenzerstörer-Modell hinzugefügt, das für die Filme gebaut worden war. Die Unreal Engine erlaubte uns, es direkt in das Level zu droppen, und es funktionierte einfach auf PS5. Das war etwas ganz Besonderes.
F: Wie haben Lumen und physikalisch basiertes Rendering dazu beigetragen, eine überzeugende Beleuchtung in verschiedenen Umgebungen und zu verschiedenen Tageszeiten zu schaffen? Könnten Sie erläutern, wie sich dies auf die Workflows der Künstler und die Iterationszeiten ausgewirkt hat?
Wickens: Lumen ermöglichte es uns, sehr schnell eine attraktive, wenn auch nicht vollständig ausgefeilte, Ausgangsbasis für die Beleuchtung zu erreichen und das Beleuchtungsteam verschiedene Looks für ein Level in einem groben Durchlauf durchgehen zu lassen, bevor es sich festlegte.
Eines der interessanteren Ergebnisse auf der PBR-Seite war ein Workflow, den wir entwickelten, um reale Farben aus unserem Referenzmaterial zu sampeln und diese in physikalisch genaue Referenzfarben für unsere Assets umzuwandeln. Das ersparte uns viel Rätselarbeit bei der Auswahl von Texturfarben – eine Spekulation, die stark je nach Monitor, Raumhelligkeit oder Umgebungslicht variiert, da nicht jeder Künstler in einer farbgesteuerten Umgebung arbeitet.
Wir kombinierten dies mit benutzerdefinierten Validierungswerkzeugen der Unreal Engine, die den Künstlern zeigen, wo eine bestimmte Farbe auf einer prozentualen Skala liegt, von sehr dunkel und dunkel, über Mitteltöne, bis hin zu hell und sehr hell, plus Flags für alles, was ganz außerhalb dieses Bereichs liegt. Oft beginnen Künstler damit, Farben auszuwählen, die isoliert – in Photoshop – richtig aussehen, aber nicht standhalten, sobald sie in der Engine beleuchtet sind. Dieser konsistente PBR-Rahmen bedeutete, dass unabhängig davon, ob jemand Texturen für Charaktere, Fahrzeuge oder Umgebungen baute – oft isoliert voneinander – alles korrekt zusammenpasste, sobald es in der Lumen-Szene beleuchtet war, ohne visuelle Unterschiede zwischen diesen.
F: Wie haben Sie die Unreal Engine optimiert, um konstante Bildraten zu liefern und das Geschwindigkeitsgefühl zu bewahren?
Wickens: Wir haben ein ziemlich komplexes Validierungswerkzeug entwickelt, das unsere technischen Spezifikationen in tatsächlich durchgesetzte Regeln kodifiziert. Nehmen Sie die Nanite-Dreiecksdichte: Nanite akzeptiert gerne so viele Dreiecke, wie man ihm gibt, aber wir wollen immer noch eine konsistente Dichte – deshalb berechnen wir eine Zieldichte pro Objekt basierend auf seiner Größe und Krümmung.
Jeder Check-in prüft jedes Asset anhand der für seinen Typ festgelegten Regeln, markiert alles, was nicht besteht, und rollt es in Dashboards im gesamten Inhalts-Repository zusammen. Das ist nur ein Beispiel von mehr als 250 Regeln, die wir über verschiedene Asset-Typen hinweg haben. Das gesamte System soll uns die Gewissheit geben, dass alles, was das Spiel erreicht, die erforderliche Qualitätsstufe hat.
F: Wie gewährleistet das Team die visuelle Konsistenz über verschiedene Hardware hinweg?
**Shires**: Es knüpft an die gleichen Prinzipien an. Wenn das Spiel die Bildrate in der Auflösung hält, sieht es auf jeder Plattform gut aus. Unreal Engine meistert plattformübergreifende Konsistenz gut. Aber Kompromisse sind unvermeidlich, daher ist das Ziel zu verstehen, welche Kompromisse wir wählen und welche zufällig geschehen, und sicherzustellen, dass wir an den richtigen Stellen Kompromisse eingehen. Wir haben viel Mühe in Low-End-PCs und Xbox Series S investiert – stellt man also die Series S und Series X nebeneinander, ist der Unterschied zwar sichtbar, aber erklärbar – bessere Hardware verdient ihren Vorteil.
Während des Großteils der Produktion haben wir jede Woche auf Zielplattformen geprüft. Ein Tech Art Director, Tech Director, Grafikingenieur und oft ein leitender Lichtdesigner versammelten sich um dieselben Bildschirme, verglichen PlayStation mit Xbox oder Konsole mit PC und befassten sich mit plattformspezifischen Einstellungen, um unbeabsichtigte Lücken zu schließen.
Wenn die unvermeidlichen YouTube-Vergleichsvideos kommen, wollen wir, dass die Spieler sehen, dass wir uns speziell auf ihrer Hardware wirklich Mühe gegeben haben – dass die schwächere Hardware immer noch gut aussieht, sich weiterhin großartig spielt und die Bildrate hält, selbst wenn sie Kompromisse eingehen musste.
Wickens: Genau, wir haben buchstäblich jede Woche zwei Hardware-Setups nebeneinander auf demselben TV-Panel verglichen. Wir haben auch sehr früh stark in das gemeinsame Playtesting im Kontext investiert, anstatt Inhalte isoliert zu erstellen und am Ende alles reinzuquetschen. Das ist ein großer Teil unserer Kultur und etwas, worüber wir bei der Einstellung oft sprechen.
Wir führen Mehrspieler-Playtests durch und blockieren Levels von Anfang an mit Spielern auf PlayStation, Xbox, High-End-PCs und leistungsschwächeren PCs in derselben Sitzung, sodass Probleme auf bestimmter Hardware rasch sichtbar werden. Wenn man als Einzelperson in diesen Sitzungen herumläuft, sieht man das Spiel auf einem Dutzend verschiedener Bildschirme und Setups. Darüber hinaus zeigen tägliche Auto-Builds die Leistung auf jeder Konsole auf einem einzigen Graphen an, sodass wir bestätigen können, dass unsere Skalierbarkeitsentscheidungen für Low-End-Hardware tatsächlich in Bezug auf Bildrate und Speicher stabil sind.