Interview
October 13, 2026
Fuse Games uses UE5 to make a fast and authentic Star Wars™ racing game
From wielding lightsabers to harnessing the Force, Star Wars™ has inspired countless childhood fantasies—and hopping into the seat of one of the franchise’s iconic vehicles has got to be near the top of the list.
Star Wars: Galactic Racer™ is a game built around this premise. You play a driver in the galaxy’s renegade racing circuit, taking speeder bikes, skim speeders, and landspeeders for a spin as you make a bid to climb the ranks and take pole position.
This is more than a racing game with cool Star Wars™ vehicles, however. Developer Fuse Games has pulled a masterstroke by adding a roguelite loop that enables you to plot your own path across the planets, choosing branching routes and tackling time trials, elimination events, and lap races while customizing your character and upgrading your vehicle with gameplay-altering abilities.
With a winning game loop locked in, the team turned to making it look every bit as good as it played. That’s where Unreal Engine 5 came in.
We caught up with Andrei Shires, Co-Founder and Head of Technology, and Karl Wickens, Studio Technical Art Director at Fuse Games, to discover how Lumen, Nanite, and World Partition freed the team from building core technology so they could focus on delivering high-quality visuals worthy of a galaxy far, far away.
Star Wars: Galactic Racer™ is a game built around this premise. You play a driver in the galaxy’s renegade racing circuit, taking speeder bikes, skim speeders, and landspeeders for a spin as you make a bid to climb the ranks and take pole position.
This is more than a racing game with cool Star Wars™ vehicles, however. Developer Fuse Games has pulled a masterstroke by adding a roguelite loop that enables you to plot your own path across the planets, choosing branching routes and tackling time trials, elimination events, and lap races while customizing your character and upgrading your vehicle with gameplay-altering abilities.
With a winning game loop locked in, the team turned to making it look every bit as good as it played. That’s where Unreal Engine 5 came in.
We caught up with Andrei Shires, Co-Founder and Head of Technology, and Karl Wickens, Studio Technical Art Director at Fuse Games, to discover how Lumen, Nanite, and World Partition freed the team from building core technology so they could focus on delivering high-quality visuals worthy of a galaxy far, far away.
Q: Thanks for joining us! The game looks amazing! Please tell us about your core goals for Star Wars: Galactic Racer™ and what the game is all about.
Andrei Shires, Co-Founder and Head of Technology at Fuse Games: Our job as a technology team is simple in principle: support the best possible player experience. Everything we do is in service of that.
Karl Wickens, Studio Technical Art Director at Fuse Games: From a technical standpoint, our core goals were high-fidelity content and cinematic presentation, without sacrificing consistent frame rate or fluid controls.
Q: Why was Unreal Engine 5 chosen for this project and which UE5 features stood out to you most during development (and why)?
Shires: We evaluated multiple engines at the outset. What mattered most was finding one that let us build quickly to a very high, consistent standard, so our focus could stay on making the game, not building core technology from scratch. Unreal Engine 5 was the clear opportunity there, particularly the way Nanite, Lumen and World Partition work together. That combination was hugely attractive for a game like ours.
Wickens: We knew we’d need to grow the team fast, and using an off-the-shelf engine with well-established best practices made onboarding much easier. It also sped up our own learning curve and let us bring in purchased tools and content as a starting point for our own game-specific assets.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q. Racing games expose every millisecond of latency. What were the biggest technical challenges in making vehicles feel responsive at such high speeds?
Shires: A few things. For a racing game to feel consistent and fair, the physics simulation has to run at full frame rate, independent of the game’s frame rate, and fast enough to handle vehicles travelling—and crashing—at extreme speed. We put a lot of effort into getting that physical simulation as solid as possible, because everything else depends on it: consistency, fairness, low latency, and a vehicle that actually responds the way you expect it to through a corner.
Wickens: One thing that mattered enormously—not quite rendering, but adjacent to it—was managing several different ‘layers’ of each level simultaneously. There’s the render mesh, which is mostly Nanite. There’s a separate collision layer for the racing simulation. And there’s the Lumen scene: the 3D geometry that feeds global illumination, plus the far-field scene beyond that. As you race through a level, multiple layers of data are active at once—some visible, some not, some affecting racing physics, some affecting lighting. We spent a lot of time tuning the resolution of each of these, testing what was actually perceivable if left out of the Lumen ray-tracing scene, to hit the frame rates we needed.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How has Nanite enabled the team to use highly detailed assets, including vehicles with millions of triangles, while still targeting smooth performance? Also, what sort of tangible results did the team see in terms of visual quality and production time?
Wickens: Nanite was a genuine paradigm shift from the old LOD-based world, where you’d carefully hand-pick the triangle budget for every level of detail on an asset. With Nanite, you provide one fixed high-resolution version and let it dynamically resolve however many triangles the scene needs. The old LOD approach is expensive to produce and, because LODs work in fixed bands, it’s inherently wasteful—there’s a sweet spot in each band where detail looks right, and a stretch either side where you’re not getting the quality you could be. Nanite also killed the ‘popping’ you’d get as assets switched between LOD bands, since it resolves detail smoothly instead.
The fidelity gains were tangible in some unexpected places, too. Our head of content is still delighted that we can pull straight from in-race vehicle assets for close-up marketing imagery, with zero extra modelling work. Those same assets held up as cinematic props, and in photomode you can get right up close and still see the detail holding—with none of the popping artefacts LODs used to cause.
Production time is an interesting story. The old LOD pipeline is a bit like hand-finishing furniture. Every cut matters: every edge loop has to earn its place in a tiny triangle budget. Nanite takes a lot of that technical overhead away. It’s still there, just reduced significantly, which opens the work up to more artists and lets them move faster.
Shires: I’d plus-one that. The biggest change I’ve seen is being able to get a level or vehicle looking good and running at a good frame rate at the same time. In the old pipeline, you’d get gorgeous meshes in and immediately tank your frame rate until the LODs were done, so you’d see ‘what the game will look like’ and ‘what the game will play like’ as two separate moments, weeks apart.
With Nanite, we had assets that weren’t optimized at all running at a good look and a good frame rate very early in development. That’s the real shift for me. Not that the game looks better, because I think we could’ve hit similar visual quality with LODs too, but it’s how much faster we could iterate on that experience and Fuse, the more we travel through the iteration loop, the better our game gets.
We even added a Star Destroyer model that had been made for the films. Unreal Engine allowed us to drop it straight into the level, and it just worked on PS5. That was pretty special.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How have Lumen and physically based rendering helped create convincing lighting across different environments and times of day? Could you talk about how this impacted artist workflows and iteration times?
Wickens: Lumen let us reach an attractive, if not fully polished, baseline of lighting very quickly and let the lighting team iterate through different looks for a level at a rough pass before committing.
One of the more interesting outcomes on the PBR side was a workflow we built to sample real-world color from our reference footage and convert that into physically accurate reference color for our assets. That took a lot of the guesswork out of choosing texture colors—guesswork that varies wildly depending on someone’s monitor, room brightness, or ambient lighting, since not every artist works in a color-controlled environment.
We paired that with custom Unreal Engine validation tools that show artists where a given color sits on a percentual scale, from very dark and dark, through mid-tones, up to bright and very bright, plus flags for anything that falls outside that range entirely. Artists often start out choosing colors that look right in isolation—in Photoshop—but don’t hold up once lit in engine. Having that consistent PBR framework meant that whether someone was building textures for characters, vehicles or environments—often in isolation from each other—everything sat together correctly once lit in the Lumen scene, with no visual disparity between them.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How have you optimized Unreal Engine to deliver consistent framerates and preserve the feeling of speed?
Wickens: We built a fairly complex validation tool that codifies our technical specs into actual enforced rules. Take Nanite triangle density: Nanite will happily accept as many triangles as you throw at it, but we still want a consistent density going in, so we calculate a target density per object based on its size and curvature.
Every check-in tests each asset against the rules set for its type, flags anything that doesn't pass, and rolls it up into dashboards across the whole content repository. That's just one example of more than 250 rules we have across asset types. The whole system exists to give us confidence that everything reaching the game is the quality bar it needs to be.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Shires: On top of that, we run automated processes that play the game in different ways and log huge volumes of metrics. Not just top line frame rates or dynamic resolution scaling, but every element of how the game is performing across every corner of every level. That gives us a feedback loop: if a rule is set slightly too loose—invisible on a single asset, but breaking things once it's multiplied across 1000 assets—we can go back and tighten it, then iterate. We didn't have all the right answers up front, but we built the tooling to let us find them.
We apply that same measurement to systems beyond content, too. Physics timing, network latency, and the server versus client tick rate all feed a second set of dashboards alongside the content ones. Getting that visibility early, building on top of Unreal Insights for trend data over time, was one of the first things we prioritized. It means when two features collide and break something in combination—even though they’re fine in isolation—our automated tests can catch it immediately.
Wickens: That tooling also shaped level structure, not just individual assets. It ties into how well partitioned Nanite and Hierarchical LODs interact: being able to see our World Partition resolutions against HLOD transition distances lets us refine our streaming settings. We ended up implementing variable streaming radii tied to vehicle speed, so the game loads further ahead the faster you're going.
We apply that same measurement to systems beyond content, too. Physics timing, network latency, and the server versus client tick rate all feed a second set of dashboards alongside the content ones. Getting that visibility early, building on top of Unreal Insights for trend data over time, was one of the first things we prioritized. It means when two features collide and break something in combination—even though they’re fine in isolation—our automated tests can catch it immediately.
Wickens: That tooling also shaped level structure, not just individual assets. It ties into how well partitioned Nanite and Hierarchical LODs interact: being able to see our World Partition resolutions against HLOD transition distances lets us refine our streaming settings. We ended up implementing variable streaming radii tied to vehicle speed, so the game loads further ahead the faster you're going.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How does the team ensure visual consistency across various hardware?
Shires: It ties back to the same principles. If the game holds the frame rate in resolution it will look good on any platform. Unreal Engine handles cross-platform consistency well. But compromises are inevitable, so the goal is understanding which compromises we're choosing versus which are happening by accident and making sure we're compromising in the right places. We've put a lot of effort into low-end PC and Xbox Series S specifically, so if you put that series S and series X side by side, the difference is visible but explicable—better hardware earns its advantage.
For most of the production, we reviewed on-target platforms every week. A tech art director, tech director, graphics engineer, and often a senior lighting artist would gather around the same screens comparing PlayStation to Xbox, or console to PC, digging into platform-specific settings to close any unintentional gaps.
When the inevitable YouTube comparison videos land, we want players to see that we tried hard on their hardware specifically—that the weaker hardware still looks good, still plays great, still holds frame rate, even where it's had to compromise.
Wickens: Exactly, we were literally comparing two hardware setups side by side on the same TV panel, every week. We also invested heavily, very early, in playtesting together in context rather than building content and isolation and squeezing it in at the end. That's a big part of our culture, and something we talk about a lot when hiring.
We run multiplayer playtests and block out levels from early on, with people on PlayStation, Xbox, high-end PCs, and lower-powered PCs all in the same session so problems on specific hardware surfaced fast. Walking around as an individual in those sessions, you'd see the game across a dozen different screens and setups. On top of that, daily auto builds report performance across every console on a single graph, so we can confirm our scalability decisions for lower-end hardware are actually holding up on frame rate and memory.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How has Fuse’s development approach tied into UE5’s workflow and flagship rendering technologies?
Wickens: We saw early on that there's a real production advantage to using World Partition, HLODs, Lumen, and Nanite together. It's an ecosystem that plays nicely as a whole, with efficiency gains you wouldn't get building any one of those systems custom in isolation. So we leaned into it. Given where we landed in UE5's lifecycle, we tested both software and hardware ray tracing through several iterations before settling on hardware-ray traced Lumen.
Shires: I plus-one everything Karl just said. Prior experience with engines where we didn't own every line of code taught us that there are two ways to work with a tool you don't fully control: with it, or against it. And against it, you're fighting the engine forever. Learning how Epic intended Unreal Engine to be used meant we could lean on Epic support, and it meant developers who shipped games before could step in and immediately understand our pipeline.
We extended that philosophy into our whole tool chain. How we distribute the editor internally, how we run auto builds—all of it follows the Epic way. There's a great set of talks where Epic walks through their own process for making Fortnite, and a lot of what we do borrows directly from that. If it holds up at Fortnite scale, it's more than enough for us. So rather than demanding the engine work in a particular way, we start from what we're trying to solve and ask how Unreal Engine already solves it. That mindset runs all the way from syncing code and content across the team, through the pipelines Karl mentioned, to how we actually package and ship the game.
Q. The tracks span iconic Star Wars™ locations. How did Unreal Engine's world building tools help the team create environments that feel authentic while remaining highly readable at racing speeds?
Wickens: Landscape painting tools were a big help for iterating quickly through early block-outs and initial designs. And procedural content generation in particular let us define procedural rule sets to populate levels: high-density trackside elements, tapering to lower density procedural population further out. That let us handcraft key landmark buildings and then quickly populate the surrounding detail around them.
STAR WARS © & TM 2026 Lucasfilm Ltd. All Rights Reserved.
Q: How important has it been for you to have access to UE’s source code throughout development?
Shires: Extremely important. It's how we understand not just what the engine should do, but how it actually does it underneath, so we can build our content to match. Without that visibility, you're guessing and you'll never quite marry the two up. Having that access means we can push the engine harder, occasionally fix a bug ourselves, and send the patch back to Epic—and when we're in a support conversation with the engineers, we're having a deep technical conversation from the first sentence rather than starting from scratch.
Q: Thanks for your time! Where can people go to learn more about Star Wars: Galactic Racer™?
Shires: You can head to our official website at starwarsgalacticracer.com to learn more, as well as find all of our social media links and our official game Discord server!