Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
June 13, 2021
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: Stardock and Oxide Games' Ashes of the Singularity

Postmortem: Stardock and Oxide Games'  Ashes of the Singularity
April 26, 2016 | By Brad Wardell

April 26, 2016 | By Brad Wardell
More: Console/PC, Programming, Art, Audio, Design, Production, Business/Marketing

Article Start    Page 1 of 3  

Brad Wardell is the founder of Stardock Entertainment and the cofounder of Oxide Games

Ashes of the Singularity is a real-time strategy game that takes place in the distant future where humanity has begun to expand into the galaxy. Each match takes place on a particular planet where the player builds and controls vast armies to conquer it.

Released in April 2016, Ashes of the Singularity was a fairly well known quantity in hardware circles due to its distinction as the first native DirectX 12 game (it runs on Windows 7/DirectX11 as well). The question on many people’s minds was whether the game itself could outshine its various technological achievements.

This postmortem will walk you through a few of the things that went right, but mostly we want to focus on the things that didn’t go right. That way, other developers, as well as gamers, can gain a better understanding of the process for creating a brand-new large-effort game, from scratch, in 2016.


Within the first week of the game’s release, it made the top sales charts and has received some very positive reviews due to its strong replayability, lots of maps, good AI, and multiplayer features as well as some mixed reviews due to the expectation that RTS games should focus more on a story with characters. We will discuss the lessons we learned from this. 

In our minds, good strategy games create their own stories from their game play. However, that doesn’t somehow make the criticism of the game’s relatively light campaign invalid. As game developers, our job is to deliver games based on the demands of the market.

In short, Ashes has had a very successful launch. And, lest one is tempted to say “Of course you’d say that,” I will point you to my last postmortem.

How we got here

No game is made in a vacuum. Well, not yet. I mean, they could probably make a game in space in space suits, I guess. Maybe next time.

Anyway, the origin of Ashes of the Singularity goes back to 2000, shortly after Cavedog (the makers of Total Annihilation) closed. We had recently worked with Blizzard and GT Interactive on the StarCraft expansion, StarCraft: Retribution. Our proposal was to license the Total Annihilation engine and create either a new game or a Total Annihilation II

The original Total Annihilation

Our proposal included two primary gameplay additions to Total Annihilation. First, we wanted to let players zoom out further if they wanted. Secondly, we wanted to allow players to build a new series of structures called “Orbitals” that would give them global abilities. 

The idea was that StarCraft units had abilities and we wanted to give players the ability to act tactically, but without turning the game into a click-fest. Thus, building an orbital would unlock a new button on the screen that would have a cool-down. An example would be, for instance, an ability that would let the player insert a construction unit on a far off big map if they had vision or an ability that would give units a temporary shield while engaged in combat.

Unfortunately, GT Interactive went defunct and was acquired by Infogrames. So no Total Annihilation 2, and no new game. We were starting to feel cursed.

Build a game engine? Or license a game engine?

After it became clear that a new RTS built on the Total Annihilation engine was no longer viable, Stardock, like many game developers of that time, found itself struggling to build a third-generation game engine.

This talk of generations and game engines probably requires a little background.  Briefly:

  • 1st Generation: DOS, 16-bit, 640K max, single-threaded 320x200 max with 256 colors, sprites
  • 2nd Generation: Windows, 32-bit, single core, 640x480 typical with 256 colors, sprites
  • 3rd Generation: Windows, 32-bit, single core, 2GB max memory, DirectX 9c

By 2006, Stardock had just barely managed to cobble together a 3rd generation engine and released Galactic Civilizations II

From 2006 to 2010, Stardock worked to develop a true 3rd generation engine called Kumquat which was going to be used to power Elemental and Society. However, in doing so, it learned just how technically challenging it is to develop. 

If you, the reader, are wondering why everyone just uses Unity these days, now you know why. Unity is a fantastic, mature, fully featured 3rd generation engine.  What they’ve accomplished is non-trivial.

Stardock learned a great deal of hard lessons while developing its own 3rd generation engine:

  1. 2GB of memory disappears very fast if you want to have a large map with hundreds of unique units.
  2. You don’t really have 2GB. You have whatever the largest chunk of free memory available when you allocate (memory fragmentation). If your clever engine does a lot of dynamic memory allocations, you can run out of memory at 1.3GB with relatively few tools to explain this (2009).
  3. The ramifications of some of the DirectX 9c limits had on creating really cool, deformable, randomly generated terrain in terms of texture limits, vertices, etc.
  4. DirectX 9 only lets the main thread (the one that launches the game) actually talk to the video card, making it very difficult to get any sort of high fidelity visuals when combined with lots of units. 

Stardock’s partner, Ironclad, successfully built their own 3rd generation engine (the Iron engine) for Sins of a Solar Empire. Similarly, Gas Powered Games had pioneered third generation engines with the Dungeon Siege engine, which later became the basis for Supreme Commander.

Gas Powered Games' Supreme Commander

By 2011, it became clear that Stardock didn’t really have a viable third generation game engine. This was an existential issue because historically, the company’s strength had been based on the scope of its games. If we had to license our engine from a third party, we would lose some of our distinctive abilities to make truly custom games.

For example, Paradox’s development studio has a third generation engine called Clausewitz that they’ve used to build Europa Unversalis, Hearts of Iron, Victoria, Crusader Kings, and Stellaris. As a result, Paradox has been able to leverage their powerful engine to make a host of outstanding and unique game titles that are also very robust.

In short, Stardock needed a robust game engine if it wanted to continue to develop distinctly unique large-scale game designs.


For a long time, we’ve dreamed of making a game where the player could zoom in and see individuals living out their lives while zooming out to see an entire world with various wars being fought out by dozens or even hundreds of players (ranging from nation states down to liberation fronts). 

Unfortunately, no such engine existed and in fact, such an engine would have to be a theoretical 4th generation engine. What would be a 4th generation engine?

  • 64-bit
  • Scale seamlessly with multiple cores
  • Every core could talk to the graphics API simultaneously

Only an engine that performs as listed above could seamlessly deliver high fidelity visuals and massive scope at the same time. Given that Stardock had struggled to create a 3rd generation engine, even thinking of building a 4th generation engine was daunting. 

Then…a miracle happened. 

Jon Shafer (Civilization V) and Soren Johnson (Civilization IV) were working with us on other game projects and introduced me to several of the former leads of Civilization V: Dan Baker, engine lead, Tim Kipp, systems lead, Brian Wade, lead developer, and Marc Meyer, UI engine lead.  

With Civilization V done, they were looking to do something incredibly ambitious. They wanted to create a new type of game engine that would allow for strategy games of nearly unlimited design sophistication and with the literal fidelity of CGI in movies.

Their dream was my dream.

But could they actually deliver such an engine? What they wanted to create wasn’t just a 4th generation engine, but one that promised to deliver visual fidelity beyond anything we had previously considered.

To be clear: their engine was going to use object space lighting like you’d see in a CGI movie, except in real-time. While I was familiar with deferred rendering, forward rendering, and forward+ rendering, what they proposed was something beyond my development experience.

Whenever someone suggests they do something like do movie like CGI rendering in real-time the obvious question is: If this were possible, why hasn’t someone done it yet?  That was why I was so skeptical of their proposal. However, their credentials gave me confidence that they could actually pull it off.

First, they had just finished developing the most successful strategy game of all time, Civilization V (even as I write this, it has over 50,000 people playing it simultaneously). Secondly, each of them had a long track record of technical success. Dan was one of the developers of DirectX, Brian had been the lead developer and/or AI programmer on countless well known and beloved PC games, Marc had developed the UI system that helped make Civilization V such a success, and Tim was the guy who built a threaded animation system for the Xbox 360 and helped build the engine for Battle of Middle Earth II.

Their proposal: fund their start-up and they’ll build the engine that would solve all or problems. I did. And so did they.

Ashes of the Singularity is born

Now that Ashes is out and is a success, there is always the temptation to look back and think “if only we had spent more, we could have launched with so much stuff. But in 2012, the project seemed very risky.

Stardock's Ashes of the Singularity

Let’s recap on their proposal (understanding that this is 2012) for their new engine:

  1. It would be a core-neutral engine. That means, there is no “main thread”. There is no “graphics thread”. The more cores you add, the better the engine will perform. As a reminder: In 2012, most people only had single core CPUs. Core-Duos were relatively new and only crazy people had more than 2 CPU cores. 
  2. The engine would be 64-bit only. You wouldn’t be able to even use it unless you had a 64-bit machine.
  3. Every CPU core would talk to the graphics API (DirectX) - something that, at the time, no one to my knowledge was doing. Moreover, DirectX (at the time) serialized its output to the GPU so this very expensive engineering endeavor would have limited benefit.
  4. The graphics engine would render using object space rendering (OSR) as opposed to deferred rendering, forward rendering, or forward+ rendering. OSR is basically how CGI in movies is done (think Pixar’s “Bug’s Life” level rendering but in real-time) and use OSL (Object Space Lighting).

The backdrop of this proposal can’t be ignored: Stardock had just been burned spectacularly in the most public of ways by trying to develop an excessively ambitious 3D engine for a fantasy strategy game.

Fortunately, we had recently set up a fund specifically to invest in new ideas like this. So this endeavor was given a very modest budget.

Designing an RTS on a very limited budget

To put Ashes' budget in perspective: Supreme Commander 1.0’s reported budget was 9 times bigger and GPG started with the Dungeon Siege engine base.

The reason the initial budget for Ashes was so small was because it was such a high-risk project. The industry is littered with “a bridge too far” games, ranging from Strike Commander to Jurassic Park: Trespasser

When it came time to design the game, we had to keep our budget in mind and Oxide invented a number of ingenious technologies that dramatically reduced the cost of making the game (which we’ll get into shortly).

From a design point of view, we had to be very careful with our resources. For example, myself along with the other Oxide founders, are engineers. That meant that the art for the game would need to be contracted out either to Stardock proper or to third-parties and it had to be done in such a way that wouldn’t kill our budget.

Some examples of where we reduced our budget included:

  • Focus on the sand box game (skirmish)
  • Limited animation (units are inorganic, don’t walk)
  • Limited map assets (e.g. no fighting in cities)

What we lacked in art assets, however, we made up for with gameplay features. The goal was to have a game with “good bones” to build from.

If the game was successful, we would have a new IP built on an engine that has an indefinite lifespan ahead of it. A 64-bit, core-neutral engine with “real” lighting won’t get dated any time soon. We could build on that – as long as the base game succeeded in having “good bones”.

Mantle & DirectX 12 change the playing field

With all the coverage Ashes of the Singularity has received due to it being the first DirectX 12 game, it’s easy to forget that neither it nor Mantle existed when we began development.

When AMD announced Mantle, a new graphics API set to compete with DirectX 11, we were well placed to demonstrates Mantle’s benefits. Since every CPU core in our engine wanted to talk to the GPU simultaneously, Ashes got a massive performance benefit.

The bump in performance from DirectX 11 to Mantle was so substantial that it caused some marketing headaches for AMD. For example, during the prototype tests on an AMD 390 we saw performance gains of over 60 percent. However, marketing materials would go out that indicated only a 20 percent boost, because there was concern that no one would believe such a massive jump.

For reference, on the shipping version of Ashes of the Singularity, the average frame-rate of an AMD 390 at 2560x1440 with highest settings is 30FPS on DirectX 11 and 53FPS on DirectX 12. That’s an 80 percent boost in performance based on the real-world results of thousands of players submitting their benchmarks.

Meanwhile, Microsoft also saw the real numbers we were getting and began working with us the “new” DirectX they were working on which would become DirectX 12. 

The difference between DirectX 11 and DirectX 12 is very easy to explain: On DirectX 11, all your threads in your game can talk DirectX at once but DirectX 11 only talks to the GPU one thread at a time. By contrast, on DirectX 12, all the threads in the game can talk to the GPU at the same time. 

In theory, a 10-Core Intel Broadwell-E, for instance, could do 10X the performance in DirectX 12 than in DirectX 11 -- provided the video card was fast enough to keep up.

Article Start    Page 1 of 3  

Related Jobs

Disbelief — Cambridge, Massachusetts, United States

Disbelief — Cambridge, Massachusetts, United States

Senior Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline

Loading Comments

loader image