An Interview With Oxide Games: The Evolution of Nitrous

Two years ago, Oxide Games had emerged on the scene with Nitrous, its new engine that promised to take a different route from the competition when it came to creating next-generation visuals. Roughly two years later, Oxide’s Nitrous has evolved significantly with the studio releasing its first DirectX 12  supported game in Ashes of the Singularity (currently in Steam Early Access). The achievements of the studio thus far can’t be ignored and luckily, GamingBolt had a chance to speak to the Nitrous development team about the engine’s development and any changes that have been made since its introduction.

"We’ve had a very good results with DX12. We’re pretty far along with our Vulcan support. We’re phasing out the Mantle and phasing in the Vulcan. We don’t have it working yet because the spec isn’t quite in provisional yet. It will be soon."

Ravi: Can you tell us a bit about yourselves and Oxide Games; and how you started it; and how you first got into games development?

Dev Team: That can be a long story. (Laughing) The founding members of Oxide. We’ve all been in the industry for a really long time now. Probably been in the games industry 20 plus years. We’ve all been developing software for a really long time. Did a bunch of different stuff. During the course of our careers we met each other along the way. At the end of it we all wound up at Firaxis.

Ravi: Yeah, Sid Meier’s studio.

Dev Team: Right. We wanted to try out some new, riskier things and that’s difficult to do in a publicly owned company. That’s why we decided to form Oxide Games and take some risks on what we thought would be disruptive game technology that we could tie in with multi-core, next-gen API.

Ravi: Nitrous is the key thing here because Ashes of the Singularity is on it. When you first announced it, it caused that “disruption” you’re talking about. It’s been some time since the announcement. What sort of changes have you made to the engine over the years?

Dev Team: Whenever you’re building new technology you start with a problem. And a theory on how to solve that problem. You put that solution into practice and see what problems that solution caused. etcetera, etcetera. That’s where we started. We had a lot of ideas on how we’d utilize multi-core. We had a lot of ideas on how we could tie that into both gameplay and graphics for next gen APIs. What we’ve been doing since then is a refinement. The biggest thing we’ve noticed is that everything matters. We found ourselves changing in terms of synchronization, and that can really destroy a multi-core engine. Our interest isn’t just frame rate, but fast to get into it. Last night I tested it. From launch to the executable when the main movie plays its 7 seconds on DirectX12 its 4 on DirectX 11. And that’s to load the entire content of the game. That was a theory we had about synchronize loading and how we form out the loading system to a variety of different cores. We refined that overtime. We do a lot of work with different performance tools. We try to study the frame. One thing we focus on is we don’t just assume there’s a problem we try to track it down and make sure it’s the problem before we try and solve it.

Ravi: When you first introduced Nitrous you were one of the biggest supporters of AMD’s mantle API. Has the tech been converted into a universal API which is the Vulcan API? Given that you are supporting Vulcan has this made the Nitrous Engine a platform agnostic engine of sorts, which gives better compatibility across several devices and consoles?

Dev Team: I would say that probably true. We’ve had a very good results with DX12. We’re pretty far along with our Vulcan support. We’re phasing out the Mantle and phasing in the Vulcan. We don’t have it working yet because the spec isn’t quite in provisional yet. It will be soon. We’ve been spending out time trying to get early access out. We believe by sometime next year we’ll be showing off Vulcan. All indications are indicating that our engine is well build around next generation technologies. When the new APIs come, everyone’s got these new technician costs. DX11 comes out and everyone has DX9. But we’ve already found all that tech transition. We’ve paid that cost. They’re all completely next generation on everything. Adopting Mantle early has given us an edge. We’ve already mapped out a lot of the models for next gen API. We have baselines; we know how fast things should be. When Mantle was new and being accepted, no one know what the results of that were going to be. Everyone had well informed ideas but no one actually sat down and proved how well it could work out. By adopting Mantle early, it’s made out transition to DirectX 12 a lot easier. We’re confident that those platforms are going to work out really well. For us.

"We built Nitrous. We didn’t just build an engine and say “we’re going to go out and compete with Unity and Unreal.” We built Nitrous because Unreal and Unity could not handle the type of games we wanted to make."

Ravi: One thing that’s defined Ashes of the Singularity is that it’s one of the first games that will utilize DirectX 12 — it’s been built for it. What kind of benefits has this resulted in when used in conjunction with the Nitrous Engine?

Dev Team: There are lots of benefits. The direct control is really big. We can guarantee smoothness and get rid of hitches and do synchronization. DX11 has a lot of bugs even after we send our game in. DX12 is so much cleaner. We all this performability early on in it. When we shipped DX11 5 years ago, with Civ 5, those drivers were a mess. The fact that DX12 is working this well so early bodes well for them. A lot of the problems we were just anticipating would just go away.

There are a few things we’ve been able to embrace: object space, lighting. If you look at the next gen API they are what really make those technologies feasible. Both of them require increased draw count. If you look at it in DirectX 11 it was a very batched limited API. Two of the fundamental technologies we developed and embraced both the temporal anti-aliasing and the object space lighting require a significant increase in the number of batches that can be submitted to the GPU. Without that we would be more limited. If you look at Nvidia’s DirectX 11 driver performance, they’ve gotten what I would consider stellar results out of that. DirectX 12 should result in more stable game releases.

Ravi: When you consider that Nitrous has gone to that point where it’s going onto multiple platforms, and it has that compatibility — right now it’s only announced for the PC platform and given that it is compatible with the PS4 and Xbox One are there any plans to bring it to consoles? Is there anything stopping you from current-gen consoles?

Dev Team: No. We’ve worked really well on current-gen consoles. It’s strictly just what games we’re working on and what our customers are wanting us to ship from right now. It’s well suited for consoles.

Ravi: The game is going into early access in October 22. Besides gameplay feedback what is your current aim, what kind of data are you looking for? Say, for optimizing it across multiple GPUs for DirectX12 benchmarks and such.

Dev Team: We did our tuned benchmark back in August and this one isn’t set up for bench marking. We’re looking more for compatibility, troubleshooting stuff. We haven’t done an enormous amount of tuning for the GPUs and probably isn’t as useful for benchmarking. We want to make sure we can run on a wide variety of — especially — lower-end hardware. We should be able to run and scale down on mobile parts and integrated graphics. From a technical stand point, make sure we edit the tech settings appropriately. We want a lot of feedback with the DX12 to make sure everything is working correctly.

Ravi: With regards to licensing the Nitrous engine. There’s been this thing in the past– this year actually: Unreal Engine 4 has gone free. Unity 5 also went free. How have these announcements affected your plans for licensing?

Dev Team: Two things about licensing. We built Nitrous. We didn’t just build an engine and say “we’re going to go out and compete with Unity and Unreal.” We built Nitrous because Unreal and Unity could not handle the type of games we wanted to make. We built Nitrous for the types of games Oxide wants to make. As for our plans for licensing, I don’t think we’re ready to announce that.

When we built Nitrous, our goal wasn’t to compete with Unity and Epic. The goal was we saw a serious of problems in the gaming space that we wanted to try and solve. Mainly that games were limited on their scope, their complexity. When you look at Unity and Epic those engines are really good content play back–especially sandbox games. Those engines aren’t very good at that. Nitrous is the opposite philosophy. It’s designed for more simulation, broad scope, and huge non-stop stuff going on.

We haven’t worried about competing in terms of price. If those guys want to fight it out to see who can be the most “free,” they’re more than welcome to do that. If you look at it, Unreal takes 5 percent on the back-end, and Unity takes a fair bit on the back-end.

People say it’s a fair bit, but it’s gross. It’s not that different from the previous model. They sort of changed which side they did that math on. They’re both fighting over certain developers. I think we’re in a different space entirely. They’re welcome to do what they want in the marketplace. It’s not much of an issue for us.

"When you try to get a game down into the 16 milliseconds consistently, it’s amazing how those milliseconds add up. Going to 30 frames per second is like gaining those extra milliseconds really is huge in terms of flexibility you’ve got there. It’s very difficult."

Ravi: In the past oxide games has claimed that DirectX 12 will improve visuals and this has become apparent on the PC. But DirectX 12 will also be coming to the Xbox One. As far as we know the Xbox One already has an API library which is similar to DirectX 12. Do you think this could be improved further when DirectX 12 actually arrives on the console?

Dev Team: We’re not experts on the Xbox One, but I can tell you what my understanding is. There are two benefits with DirectX 12 that are performance related. It’s a lot lower CPU overhead. That’s important because the CPUs on the consoles are not powerful. You have many of them but each one is not powerful. You’ll get a huge CPS benefit if you were having trouble with that by using DirectX 12. The other thing that DirectX 12 really does it offers more support for advanced GPU features. And there’s not a great way of doing that at all on DX11. By enabling that on Xbox One you can get pretty big (word sounds like per, or perf? Can’t understand) improvements on consoles. There should be tangible benefits. It will take people a few years to acclimatize to how to program and get those benefits.

Ravi: Like you said, it reduces CPU overhead. Can this, for Xbox One in the long run, can it result in games pushing out more pixels or a better resolution or better FPS?

Dev Team: Sure. If you use synchronous compute feature, if you optimize your research transition barriers that you have direct control over for DirectX, there are things you can do that you have no way to analog in DX11. There’s potential for substantial performance improvements which could manifest in increased resolution and frame rate.

There’s also additional benefit for developers to invest in trying to really pull the most that they can out. So they can bring that directly back to the PC. Because if you have to build two different paths you have to optimize one over the other. That’s as much a budget and a resource issue as anything else. It certainly is going to encourage people to invest more in that technology.

Ravi: Microsoft is working on– they’re trying to make Windows 10 a singular platform across every system, with Xbox One having that along with the PC having that as well. They’re encouraging a lot of cross platform compatibility between it. Do you think this kind of feedback that comes back and forth between developing on Xbox One and on PC, is it like a mutual benefit between the two platforms? This kind of work that’s being done.

Dev Team: Yeah. I think it is. It’s certainly very attractive for a developer to have to have a unified platform. To be able to code on DirectX 12 and be on the PC and then put it on the Xbox with minimal changes is hugely beneficial. It definitely homogenize their platform. Instead of Xbox One as a separate platform and Windows 10 as a separate platform, now you just have Microsoft as one platform and that’s clearly a lot simpler.

Ravi: One thing that’s been a major issues with the current gen consoles since they were announced– it’s been a PC issue since the beginning of time — from a developer’s perspective, 1080p at 60 frames per second: why do you think that isn’t a norm for this generation as such? Because when we looked back at the beginning there was all this hype that the new consoles would be capable of this and since then it’s like not many developers have been able to deliver on those promises, per se. Why do you think it’s been a struggle to balance between frame rate and resolution?

Dev Team: It’s simple math. Last generation consoles and this generation, I think the number I heard quoted was it was 6 times more powerful. That’s great, right? Then you do the math. You realize that if you’re running at 720p and going to 1080p you’ve doubled the number of pixels. If you were running 30 frames a second at 720 and you doubled your pixels and wanted to double your frame rate, you just used 4 more per and you have no more perf. Then you additionally want to increase the fidelity. You’ll see the same thing on 4k. It has 4 times the pixels as 1080. You need a GPU 4 times as powerful just to do the same thing you did before just at a higher resolution level with most engines. With Nitrous you actually don’t. That’s probably why you haven’t seen the big jump that some people were expecting.

It also takes increased bandwidth, etc. etc. When you try to get a game down into the 16 milliseconds consistently, it’s amazing how those milliseconds add up. Going to 30 frames per second is like gaining those extra milliseconds really is huge in terms of flexibility you’ve got there. It’s very difficult. Every game generation you want to do something a little more ambitious. And to pack additional graphics plus additional AI, plus additional gameplay and everything else into 16 milliseconds can be really, really challenging. Especially when trying to do that consistently. The last thing you want to do is stutter between 60 frames per second and 30. You don’t want to jump back and forth there a whole lot. There’s a lot of people that will argue the development cost and the discipline it takes to make a game run consistently at 16 milliseconds is just very difficult to achieve.

There are other things you can say too. As resolution increases the computational cost increases. I think we’re one of the only engines out there that have been reinvestigating how you render a frame. To some extent, as the resolution increases, not only is there a cost of more pixels but those pixels are being faded in a very simple manner. As we scale up in resolution how can we change our rendering so it’s less expensive? Because we’re doing the object space lighting we actually would scale better as the resolution increases. If you run our games at 4K, a lot of engines are 3 or 4 times slower we’re like less than half speed.

"To some extent whenever you’ve got something new like DirectX 12, you need people to pioneer the way. Once they prove that it works then you start to see a greater adoption. It’s an exponential growth. Somebody’s got to start somewhere."

Ravi: When it came to optimizing Nitrous for PS4 and Xbox One, both consoles have a similar architecture. They’re both AMD based per se. Did you see any major differences in how the memory works or the number or GPU or ROPs and such?

Dev Team: I don’t think we can talk about differences that we can see. It’s not clear what part of that is for NDA and what part isn’t.

Ravi: The overall differences between the two APIs on both consoles and which one is easier to work with.

Dev Team: I think the PS4 has a pretty nice API. The PS3 had this thing called the GCN. They did something similar for PS4. It’s a bit of a learning curve, but it’s pretty good.

Ravi: Given that you have a close relationship with Microsoft with DirectX 12 and such, what are your thoughts on the adoption rates on the API and the feedback that you’re getting back from developers that have used it so far?

Dev Team: We have a pretty good relationship with Microsoft. I actually worked on DirectX years ago, so I know those guys personally. We gave Microsoft out entire mantle station and said, “have at it.” We worked back and forth with them for a year. They helped us a lot with the initial implication. We’ve learned a lot. The difference between DX12 and the previous API is that the previous API was designed by Microsoft and they threw it over the fence and hoped it worked. This time around we actually had everything working and prototyped before the API was finalized. We’re pretty sure that everything works great. That’s a huge change in previous ones. Consumer adoption seems pretty positive. DX12 works with a vast majority of GPUs. We’re not at a point yet where we would drop our DX11 support. We wish we could. Wish we could because we can’t completely take advantage of all of DX12 until we kill our DX11 version. We’re pretty happy with the adoption.

To some extent whenever you’ve got something new like DirectX 12, you need people to pioneer the way. Once they prove that it works then you start to see a greater adoption. It’s an exponential growth. Somebody’s got to start somewhere. I’m really glad we’ve got such a good working relationship with Microsoft and Nvidia and AMD because trying to pioneer a new engine on top of a brand new graphics API and a brand new OS is definitely challenging for everyone involved.

Ravi: In our last interview with Brad, he was talking about how Sony was considering opting for Vulcan on thePS4. What kind of advantages do you think this opens up in general to regards to the Nitrous engine?

Dev Team: From our standpoint, writing a back-end for PS4 is a few months cost and then we’re done. I think it’s a better move for Sony because that means people can invest money in API and it will work everywhere. It will be a lot easier for them to put their code onto.

Ravi: As regarding the GPGPU on both consoles using the Nitrous engine, the PS4 has wider computer for that and get more utilization out of the ALU. What’s your philosophy is on the GRGPU on the Xbox One and PS4. What’s your take?

Dev Team: The PS4 has more synchronous compute queues which could allow you to develop more dependency with gameplay. You could preempt work. I know I could give you a better answer — but I can’t.

"We really want to get those most of what we can out of your systems. We’ve been working hard to do that. It’s one of those things where the hardware guys need developers to produce content that utilizes it."

Ravi: That’s perfectly fine. The PS4 GPU is a step above the Xbox One’s. As you were saying earlier, you don’t have too much trouble when you’re scaling down the Nitrous engine to these different platforms. When you consider the GPU differences, how do you approach this situation? Are you able to scale accordingly to the hardware? Do you go for that or do you try to stick to the lowest common denominator?

Dev Team: We have this problem way more on consoles because we’re PC focused. PS4 and Xbox One are relatively in the same ballpark in performance. There are some differences. With PC space we have to 10x scale not like 30-40 percent type of thing. Our engine is built for integrated graphics. We’re going up to a Furry or a Titan. We have all sorts of knobs we can turn up and down. A lot of them are subtle. You may not notice a GPU that’s a little bit slower. Like 20-30 percent. I don’t know if you’d notice if one is that slower. The average person probably wouldn’t see that too much. We can hide that pretty well.

It goes back into investing in different rendering technologies. The object space lighting stuff is very ALU efficient. Because of that we got a ride range of stuff there that we can do. It’s also resolution independent. If you’re computer ALU bound we can change how much of the scene is shaded at what rate. Where as, say you’re triangle bound we can change the TXAA settings to get different settings there. We have a lot of different knobs use to control that. Most traditional renderers are fixed. You’ve got ‘low,’ ‘medium,’ and ‘high.’ It’s very difficult for them to scale because resolution is going to cut into them. There are a lot of things that hamstring them. Where as we have a lot more freedom to embrace whatever the hardware strengths are.

Ravi: As you said, you’re a PC focused studio and one of the main concerns that’s been coming out the various bottlenecks that have been coming between components. One of the main things we’re wondering is that GPUs and APIs they’ve been progressing at a very fast rate compared to CPUs and memory speed. Are there concerns about bottlenecks in the future in regards to CPUs and memory speeds? And why do you think the industry is not quite working towards making those CPUs faster, where as they’re working more on the GPUs and progressive APIs?

Dev Team: The main problem is chicken and egg. We’ve been told that the hardware guys don’t see scaling. No one’s using all four cores. And a lot of that is the API. They can’t make a single core much faster. But they can add more cores. But they don’t want to add more cores because the games are easier. So we’re in this sort of nasty pattern.

It’s a great question. We’ve been looking at this a lot. We’d be labeled hardware enthusiasts as well as developers. We really want to get those most of what we can out of your systems. We’ve been working hard to do that. It’s one of those things where the hardware guys need developers to produce content that utilizes it. It’s worse than the chicken and the egg because there’s also got to be some business case for it as well. It becomes more complex than a simple chicken and egg things. Aside from the core issue that we’re looking at I think bandwidth is the next interesting thing that we’re looking at. There’s bandwidth and latency. From what we’ve found, as you scale up both in terms of complexity of the game that you’re making such as an RTS, we’re not looking for thousands of units but tens of thousands of units.

The memory you need for that all of a sudden becomes an issue. If you want to look at it, all of a sudden you have 16 cores instead of 8 and trying to use the same memory bus. Again you’ve got a bottle neck problem. One of the interesting things here is we build our own systems and we generally check them pretty well. I’ve got an I7 development box and we had another I7 development box and one of them was running at 50 frames per second was our CPU score. The other was at 74. We were looking at them and knew there shouldn’t be that fundamental difference between the two. That’s absolutely impossible. There’s something clearly wrong here. I ended up running Vtune on the box that was running slower and we notice that the bandwidth on the slower machine was capped at 11 gigabytes a second. It turns out; whoever had built the box had put the two memory dibs in the single channel slots so it wouldn’t register. It registered a single channel to a dual channel memory. Once we fixed that it went right back up to 70 frames per second. We’re seeing cases where increased bandwidth is going to result in increased CPU performance. We’re interested in testing out the newer DDR4 platforms especially with the higher frequency RAM, lower latency.

Ravi: One thing I found interesting that the PCs that are having these problems come up every few years. The same issue we come back to it. Whereas with consoles which have that limited hardware for years and years at a time, they’re finding ways to think outside the box. With Cloudgen on Xbox One developing Crackdown 3 and such. What’s your overall take on the cloud that makes a static console more powerful? Is there something in store like that for Nitrous? Have you ever considered inserting cloud computing with Nitrous?

Dev Team: Like cloud rendering?

"I think the cloud tends to be much more successful when you’re aggregating data and crunching numbers and then spitting those results out to a large number of users. From either a shading stand point there’s a reduced bandwidth cost there and there’s latency tolerance."

Ravi: Yeah.

Dev Team: Maybe. There are things we could do. You could do significant rendering calculations on the host and upload them. The way our engines works there are no latency issues. You might see some occasional rendering every now and again. So we haven’t really invested in it. Other than to know the architecture is compatible. From a business standpoint we’re always skeptical when we see cloud computer. The reason why is when you add up all the overhead in a big machine somewhere else, it’s not that expensive to have a machine locally. It’s never clear when it becomes a benefit.

I think a lot of it tends to wind up, as Dan says, a cost calculation. I think the cloud tends to be much more successful when you’re aggregating data and crunching numbers and then spitting those results out to a large number of users. From either a shading stand point there’s a reduced bandwidth cost there and there’s latency tolerance. If you look at AI generation and running AI in the cloud that becomes a really interesting idea. Because you can aggregate a lot of different users results, put them together and then dynamically form that data back out to other players. If you’re doing procedural generation of various parts of worlds or things, you’re streaming some of the results down, I think there are a lot of ways that that can work. But you definitely have to be careful about it.

Ravi: Coming to Ashes of the Singularity, the first thing I was wondering with regards to the gameplay: when I saw the concept for the gameplay there was tens of thousands of units on screen at the same time; and there were these battles happening simultaneously; what really struck me was that this is very similar to Total Annihilation.

Dev Team: I would say Total Annihilation is a good comparison.

Ravi: Even Planetary Annihilation.

Dev Team: I would say that Total Annihilation and Supreme Commander. There’s really like 4 different touchtone groups: there’s Total Annihilation, Supreme Commander, Company of Heroes, and Starcraft. I think all 4 of those games have provided, hopefully, an informed decision. Whenever we’re forced with a decision to make in the game those are the games we go back to the most and take a look at.

Ravi: When you look at the gameplay model itself there’s always that concern Supreme Commander was coming out there’s that concern that, “how are people going to manage when battles happen all at once.” How are you going to cater to the hardcore strategy gamers, but also help newer gamers to get into it as well? How will you manage these concerns?

Dev Team: We use traditional tools: there’s mini maps and there’s an expanded map to help give you an idea of what’s going on. In addition we have something we call the “Empire Tree.” Basically, it’s very similar to what’s in Sins of a Solar Empire. Keeping track of what units and factories are doing. And as much automation as we can get away with.

We’ve got the battle groups. Battle groups can have a hundred guys in it. And you’re managing them with one order. The production queue has been modified.

You can order reinforcements from units. If an army at the front gates needs more guys they can just say, “some factory, please send me these guys as soon as possible.” Things like that help speed up and help manage gameplay. Anywhere that we’ve noticed that it tends to be tedious or extra work to go back and do something we’re trying to remove those bottlenecks where we can.

"I think we’re actually more set up for the next generation, whenever that’s going to be. Not that we know anything of what it’s going to be or anything yet. If you double the cores and increase the GPU Nitrous will scale."

Ravi: With regards to what you’re going to have with Early Access– there’s going to be a skirmish mode, 1v1 multiplayer, and 3 medium sized maps for both single and multiplayer. What are the long term plans for the game in terms of content? What kind of maps, modes are you going to add into it?

Dev Team: Oh my goodness. That’s a huge question. I would say the best thing to do would to follow up with Brad on that and see what he’s got planned. To some extent, to be very frank and honest some of that is going to be based on the user feedback for Early Access. Some of that’s going to be based on feedback when we launch the game. There’s stuff users are really excited about and we’re going to focus on that stuff rather than focus on stuff we think is going to be more interesting. We want to make sure the users are enjoying themselves and having a good time. Some of the things we’re interested in is making sure people can access to as many maps as they can. There’s a couple ways we’re looking at that. We’re also looking at different terrain types. The game modes is also very interesting. I think we’ll likely be — not in Early Access — for release and beyond we’ll be looking at adding different types of game modes, not just traditional skirmish.

Ravi: The final question I have and I’m not sure how you’re going to answer this. There are these rumours going around with Nintendo’s next platform, which is the NX. How are you going to get a PC to run a high end– we need a high end CPU and GPU chip just to run the tech demo. I was wondering your thoughts on that. Given that we’ve already had one current generation of consoles and then we have this platform that’s apparently going to be even more powerful. What are your thoughts on that and how Nitrous Engine will scale as the next wave of consoles approaches?

Dev Team: I don’t know anything about the NX. You probably know more.

Ravi: I probably don’t.

Dev Team: I don’t know what they’re building. I think we’ll run great on it. I think we’re actually more set up for the next generation, whenever that’s going to be. Not that we know anything of what it’s going to be or anything yet. If you double the cores and increase the GPU Nitrous will scale. We’ve done 16 threads. We’ll scale with 16 cores right now. The only reason I’ve tested higher than that is because we don’t have more in the machine than that. We’re well prepared for the next gen tech transition. If someone’s going to ship a console with double the performance of the current consoles, we’d definitely love to play around with it. I think we’d be very successful there.

---