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.
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.
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.
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:
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:
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?
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.
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:
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.
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:
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”.
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.