How Oxide Games is Making a 'Next-Gen' RTS with Ashes of the Singularity II

Oxide Games was founded in 2013 by Brad Wardell and several former Firaxis employees like Dan Baker, Marc Meyer, Briad Wade, and Tim Kipp. The studio focuses primarily on PC game development and created its own game engine called Nitrous to take advantage of new graphics APIs. The original Ashes of the Singularity RTS game was released in 2016 and was published by Stardock. The sequel, Ashes of the Singularity II, is coming soon and has a free demo on Steam that just went live today for Steam Next Fest.

We took the time to interview multiple members of the development team to learn about the game's creation, what powers it under the hood, and what exactly makes it a "next-gen" RTS game.

First, can you give us the elevator pitch for the game? What separates it from the original game and other RTS games these days?

Brett Norton, Executive Producer on Ashes of the Singularity II: Ashes of the Singularity II is a massive-scale real-time strategy that does not require crazy reflexes to play. We’ve simplified massive army creation and control to allow players of any skill level to enjoy sprawling battles featuring thousands of combatants.

What trends have you noticed becoming more prevalent in development now (such as hardware trends, player expectations, tooling, live-service adoption, etc.)?

Dan Baker, Chief Graphics Architect at Oxide Games: We’re seeing older systems stick around a lot longer than before. It’s not unusual to see a decent machine from 7 or 8 years ago that can still run our game. We’re also seeing a trend for handheld gaming, in things like the Steam Deck.

We’ve noticed both of those trends as well. PC hardware typically runs a few years old, and we’re testing Ashes II on mostly ‘5-year-old’ machines, trying to ensure it runs well there, while still having some great visuals for bleeding-edge enthusiasts.

Portability-wise, we’ve been building Ashes II to play well on the Steam Deck, as well as with a gamepad controller in general, which makes it easier to play on crowded airplanes or in other places where a keyboard/mouse setup isn’t ideal. The game still plays ‘best’ when you can use a keyboard/mouse, but since the game is more strategic than tactical in nature, our gameplay translates better to portable platforms.

Player expectations are a mixed bag; some want all of the bells and whistles of a AAA title, while others just want a fun game that appeals to their specific tastes. We have the unprecedented ability to target specific audiences with specific games now. The general gaming audience is now so large, and the barriers to distribution so relaxed, that we can make a game (cost-effectively) that targets X specific audience without always having to worry about appealing to every possible player.

Specifically, what does “next-gen RTS” mean to your team in 2026?

Norton: We have enough power in our PC hardware, even on portable devices, to utilize more threads to do more simultaneous work. Whether it’s graphics or gameplay, there’s always something you can be doing with those extra cores to give players a better, smoother, or more detailed experience.

The trick is coming up with scalable solutions that work across a variety of new and old hardware. RTS’s don’t have to sweat the fidelity of individual characters quite as much as say an FPS, but we still have to be able to push a high-quality bar over a lot higher quantity of onscreen characters, and that is really, really, really hard.

So a Next-Gen RTS is one that looks fantastic when you zoom in and take cinematic shots, but also holds up, performance-wise, when you’re playing with a lot of onscreen characters on a very old computer, or on a lightweight portable device.

What were some of the overarching technical goals for Ashes 2 (scale, fidelity, performance targets, etc.)?

Baker: One of the important goals for Ashes II was to really allow the scale of battles to be sustained, rather than an intense flash and be done. The idea is that the map will be filled with small, medium, and large battles constantly.  We also wanted the impact of the battles to be visible on the landscape. Compared to the original Ashes of the Singularity, players will notice mountains of hulks of burnt and burning vehicles, trees being knocked down by giant mechs, and a map littered with the scars of battle.  But we need to do this without bogging down, which means extremely efficient use of CPU cores. Ashes II uses the Nitrous 3 engine, which has significant performance improvements from the first Ashes.

What’s the practical ceiling for units on screen in Ashes 2—and what actually becomes the limiting factor?

Baker: The practical ceiling ends up being that at some point to fit more units on the screen, you have to zoom out more, and at some point the units become so small as to not be visible.  In terms of what costs GPU performance, it's just the raw number of triangles, the number of particles (which can be >1M), and the number of lights we are spawning (also >10k). In terms of CPU performance, our renderer for Nitrous 3 is really, really fast, so it’s unlikely to be limited by CPU overhead for units on screen. However, keep in mind that everything is simulated, even off-screen units, so that’s where the CPU load ends up going.

Explosions and VFX are a huge part of Ashes’ identity—what’s the VFX pipeline like in Ashes II (which authoring tools, how are FX triggered from gameplay events, etc.)?

Baker: Nitrous has a custom FX engine that’s somewhat unique. We have a sophisticated CPU/GPU solution in which the CPU processes and sorts particles before sending them to the GPU.  This is highly optimized code that takes advantage of SIMD instructions on the CPU.  Our effects are pretty open-ended, can spawn objects, lights, line lights (for lasers), etc. The engine can handle many simultaneous effects. Many units, for example, have little headlights on them that actually illuminate the surroundings.

What are your go-to techniques for keeping frametimes stable when the screen becomes pure chaos (Culling, LODs, batching, instancing, async compute, threading, FX throttling, simulation decimation, etc.)?

Baker: Well, pretty much everything mentioned! We have a high-speed custom scheduler, auto-GPU batcher, custom shading language, async compute rendering, etc. We have some pretty neat tech that automatically batches things up, for example. We also did a lot of work to never need to dynamically compile a shader. All shader compilations occur before you ever enter a game. In terms of simulation decimation, we don’t really do that because the gameplay elements need to always work.

Does the team use any AI tools or automation processes in the development workflow? Why or why not, and what are they if so? 

Baker: We use a little bit of AI for things like translation, code navigation, and also summarizing gameplay data. All our gameplay data is AI-parsable, so it can answer questions about the state of balance, for example. We’ve even hooked up our AI agent (Hallee) in the Discord chat channel, with full access to all the gameplay data rules. It’s kind of fun; you can ask her random questions about the game, and she stays in character.

Why stick with (or continue evolving) Nitrous instead of moving to Unreal or another general-purpose engine?

Baker: There are lots of great games made on these engines, but you hit the nail on the head: General-Purpose. We can do so much more if we make a specific-purpose engine. That’s why so many big games have an engine that’s specifically built and optimized just for that game, because you can get so much more out of the system.  It’s akin to the difference between a truck and a sports car.

Additionally, these engines don’t handle things like network synchronization needed at the scale of this type of RTS, so the gameplay would have had to be custom anyway. The amount of data you generate to render is pretty crazy.  We haven’t seen an off-the-shelf renderer handle that amount of data without extensive modification. When we analyze Ashes II, we see that we are approaching the theoretical limits of what the system can do. In addition, we still want to be able to target platforms like the Steamdeck which have limited GPU power.

Finally, there’s a big class of things that the engines don’t even attempt to solve, like procedural maps.

Are there tradeoffs you accept by not using Unreal, especially around hiring, middleware, marketplace assets, or tooling expectations?

Baker: The biggest tradeoff is just that people aren’t necessarily familiar with some of our pipeline processes. However, we’ve actually tuned our art process to be mostly compatible with art assets designed for Unreal/Unity, so it’s increasingly less of a problem.

For a game like this that relies so heavily on its spectacle, how do you design around the big CPU/GPU variance in PC gaming?

Baker: This is a big part of the reason we have a custom engine. For example, one of the things we talk about a lot is having a technology stack that scales down gracefully without an upscaler. We’ve noticed many player complaints about games being blurry with these upscalers. Since these problems are worse in RTS-style games, we really wanted to avoid them. However, that means steering away from some of the rendering approaches that Unreal/Unity do, since those don’t necessarily scale down easily.  For the PC space, we are supporting hardware all the way from a Steam Deck to a 5090.

Oxide Games, Game Development Studio

Interview conducted by David Jagneaux