Pilot, der ein Speeder-Bike in „Star Wars: Galactic Racer“ fährt.

Interview

13. Oktober 2026

Fuse Games verwendet UE5 für die Entwicklung eines rasanten und authentischen Star Wars™-Rennspiels

Vom Schwingen der Lichtschwerter bis zum Nutzen der Macht hat Star Wars™ unzählige Kindheitsfantasien inspiriert – und ein Sprung in den Pilotsitz eines der ikonischen Fahrzeuge des Franchise dürfte dabei ganz oben auf der Liste stehen.

STAR WARS™: Galactic Racer™ ist ein Spiel, das rund um diese Prämisse erstellt wurde. Man verkörpert einen Piloten einer der Renegaten-Rennligen der Galaxis und steuert Speeder-Bikes, Skim-Speeder und Landspeeder, während man versucht, die Rangliste zu erklimmen und die Pole Position zu erobern. 

Dies ist jedoch mehr als ein Rennspiel mit coolen Star Wars™-Fahrzeugen. Entwickler Fuse Games ist ein Geniestreich gelungen, indem es eine Roguelite-Gameplay-Loop hinzufügte, die es dem Spieler ermöglicht, seinen eigenen Weg über die Planeten zu planen, sich verzweigende Routen zu wählen und Zeitrennen, Eliminierungs-Events und Rundenrennen zu bestreiten, während man seinen Charakter anpasst und sein Fahrzeug mit Gameplay-verändernden Fähigkeiten aufwertet.

Nachdem eine erfolgreiche Gameplay-Loop feststand, konzentrierte sich das Team darauf, das Spiel optisch genauso gut aussehen zu lassen, wie es sich spielte. Hier kam die Unreal Engine 5 ins Spiel.

Wir haben uns mit Andrei Shires, Mitbegründer und Head of Technology, und Karl Wickens, Studio Technical Art Director bei Fuse Games, getroffen, um herauszufinden, wie Lumen, Nanite und World Partition das Team vom Aufbau der Core-Technologie befreit haben, damit es sich darauf konzentrieren konnte, hochwertiges Bildmaterial abzuliefern, das einer weit, weit entfernten Galaxis würdig ist.

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.
Ein Landspeeder und ein Skim-Speeder treten in „Star Wars: Galactic Racer“ gegeneinander an.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

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.
Ein Podrenner rast durch eine Wüstenschlucht in „Star Wars: Galactic Racer“.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

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.
Ein Skim-Speeder zieht eine Kurve über eine felsige Landschaft in „Star Wars: Galactic Racer“.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

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.
Ein Mann beobachtet eine Wüstenstrecke in „STAR WARS™: Galactic Racer“.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

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.
Piloten fliegen in „Star Wars: Galactic Racer“ an einem Raumschiffwrack vorbei.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.
Shires: Darüber hinaus führen wir automatisierte Prozesse aus, die das Spiel auf verschiedene Arten spielen und große Volumen an Metriken protokollieren. Nicht nur Spitzen-Framerates oder dynamische Auflösungsskalierung, sondern jedes Element der Performance des Spiels in jedem Winkel jedes Levels. Das gibt uns eine Rückkopplungsschleife: Ist eine Regel etwas zu locker gesetzt – unsichtbar auf einem einzelnen Asset, aber kaputt, sobald sie auf 1000 Assets multipliziert ist – können wir zurückgehen, sie straffen und dann iterieren. Wir hatten nicht alle richtigen Antworten von Anfang an, aber wir haben die Werkzeuge erstellt, um sie zu finden.

Wir wenden dieselbe Messung auch auf Systeme jenseits des Inhalts an. Physik-Timing, Netzwerklatenz und die Server-gegen-Client-Tickrate liefern zusammen mit den Inhalts-Dashboards eine zweite Reihe von Dashboards. Diese Sichtbarkeit frühzeitig zu erreichen, indem wir auf Unreal Insights für Trenddaten im Laufe der Zeit aufbauten, war eines der ersten Dinge, die wir priorisierten. Das bedeutet, dass unsere automatisierten Tests es sofort erkennen können, wenn zwei Funktionen kollidieren und etwas kaputt machen – selbst wenn sie isoliert in Ordnung sind.

Wickens: Diese Werkzeuge haben auch die Levelstruktur geformt, nicht nur einzelne Assets. Das hängt damit zusammen, wie gut partitionierte Nanite- und Hierarchische LODs interagieren: Wenn wir unsere Weltpartitionsauflösungen gegen HLOD-Übergangsdistanzen sehen können, können wir unsere Streaming-Einstellungen verfeinern. Wir haben letztlich variable Streaming-Radien implementiert, die an die Fahrzeuggeschwindigkeit gebunden sind, sodass das Spiel umso schneller lädt.
Nahaufnahme eines Piloten in „Star Wars: Galactic Racer“, der einen Rennhelm trägt.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

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.
Piloten treten in einer Wüstenumgebung in „Star Wars: Galactic Racer“ an.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

F: Wie hängt der Entwicklungsansatz von Fuse mit dem Workflow und den Flaggschiff-Rendering-Technologien von UE5 zusammen?


Wickens: Wir haben früh erkannt, dass es einen echten Produktionsvorteil gibt, World Partition, HLODs, Lumen und Nanite im Zusammenspiel zu verwenden. Es ist ein Ökosystem, das als Ganzes gut zusammenspielt, mit Effizienzsteigerungen, die man nicht erhält, wenn man eines dieser Systeme einzeln individuell erstellt. Also haben wir uns darauf eingelassen. Angesichts unseres Standorts im Lebenszyklus von UE5 haben wir sowohl Software- als auch Hardware-Raytracing durch mehrere Iterationen getestet, bevor wir uns für Lumen mit Hardware-Raytracing entschieden haben.
Shires: Ich stimme allem zu, was Karl gerade gesagt hat. Frühere Erfahrungen mit Engines, bei denen wir nicht jede Codezeile besaßen, haben uns offenbart, dass es zwei Wege gibt, mit einem Werkzeug zu arbeiten, das man nicht vollständig kontrollieren kann: mit ihm oder gegen es. Und beim Kampf gegen es kämpft man für immer gegen die Engine. Zu erfahren, wie Epic die Unreal Engine nutzen wollte, ermöglichte uns, auf Epic-Support zurückzugreifen, und es bedeutete, dass Entwickler, die zuvor Spiele veröffentlicht hatten, sofort unsere Pipeline verstehen konnten.

Wir haben diese Philosophie auf unsere gesamte Werkzeugkette ausgeweitet. Wie wir den Editor intern verteilen, wie wir Auto-Builds ausführen – all das folgt dem Epic-Weg. Es gibt eine großartige Reihe von Vorträgen, in denen Epic seinen eigenen Prozess für Fortnite erklärt, und vieles von dem, was wir tun, ist direkt daraus entlehnt. Wenn es im Fortnite-Maßstab standhält, reicht das für uns mehr als aus. Anstatt also zu verlangen, dass die Engine auf eine bestimmte Weise funktioniert, beginnen wir mit dem, was wir lösen wollen, und fragen, wie Unreal Engine das bereits löst. Diese Denkweise reicht von der Synchronisation von Code und Inhalten im Team über die von Karl genannten Pipelines bis hin zur tatsächlichen Paketierung und Veröffentlichung des Spiels.
 
 

Q. Die Rennstrecken sind an ikonischen Star-Wars™-Orten angesiedelt. Wie haben die Worldbuilding-Werkzeuge der Unreal Engine dem Team geholfen, Umgebungen zu schaffen, die authentisch wirken, aber bei Renngeschwindigkeiten sehr gut lesbar bleiben?


Wickens: Landscape-Malerwerkzeuge waren eine enorme Hilfe, um rasch durch frühe Blockouts und erste Entwürfe zu iterieren. Und insbesondere die Prozedurale Inhaltsgenerierung ermöglicht es uns, prozedurale Regelwerke zu definieren, um Level zu befüllen: hochdichte Elemente am Streckenrand, die weiter hinten zu niedriger dichter prozeduraler Besetzung auslaufen. So konnten wir wichtige Wahrzeichen von Hand gestalten und dann rasch die umliegenden Details darum herum befüllen.
Ein Speeder-Bike-Pilot nimmt in „Star Wars: Galactic Racer“ die Verfolgung auf.
STAR WARS © & TM 2026 Lucasfilm Ltd. Alle Rechte vorbehalten.

Wie wichtig war es, während der gesamten Entwicklung Zugang zum UE-Quellcode zu haben?


Shires: Extrem wichtig. So verstehen wir nicht nur, was die Engine tun soll, sondern auch, wie sie es tatsächlich darstellt, damit wir unsere Inhalte entsprechend gestalten können. Ohne diese Sichtbarkeit raten Sie und werden beides nie ganz verbinden. Dieser Zugriff bedeutet, dass wir die Engine stärker belasten, gelegentlich selbst einen Fehler beheben und den Patch an Epic zurückschicken können – und wenn wir in einem Support-Gespräch mit den Ingenieuren sind, führen wir von Anfang an ein tiefgründiges technisches Gespräch, anstatt bei Null anzufangen.
 


F: Vielen Dank für Ihre Zeit! Wo können Menschen mehr über Star Wars: Galactic Racer™ erfahren?


Shires: Sie können auf unserer offiziellen Website unter starwarsgalacticracer.com mehr erfahren, sowie alle unsere Social-Media-Links und unseren offiziellen Discord-Server im Spiel finden!