Red Faction: Guerrilla's Big Bang Theory

Impressive gaming tech is one thing, but the application of it in providing an innovative gameplay experience is quite another. This generation we've seen quite an extraordinary technological "arms race" take place, particularly in the first person shooter genre, where the boundaries have been pushed in different directions, from the precision 60FPS gameplay of Call of Duty 4: Modern Warfare to the sheer visual allure of Killzone 2. But despite the truly impressive technical leap witnessed in both games, in gameplay terms they are still clearly cut from the same cloth in terms of what we – as players – have come to expect from the genre.

The release of Volition's Red Faction: Guerrilla is perhaps an exception to the rule, and that's the reason why Digital Foundry was determined to get the developers on the record in an in-depth tech interview. The core of what this game achieves is designed to do more than just one-up its competitors in terms of its sheer destructive power – the engine itself opens up a whole new host of gaming opportunities and surprise moments that in many ways revolutionises the genre.

"Honestly my favourite moments are when things go wrong and I die in spectacular ways," senior programmer Eric Arnold says. "The enemy could shoot a carefully laid remote charge setting off my own trap while I'm in it, or I could see a shadow sweep across my screen and turn around just in time to see the nearby smoke stack crush my face. What really makes it special is that we don't script big set pieces that the player watches, we allow the player to create their own wow moments and take ownership of the destruction."

But how does it work? What makes it different? Eric Arnold gave me detailed primer I'll be publishing unabridged on the Digital Foundry blog next week, but the key difference is that the new GeoMod 2.0 engine works on the basis of stress points. It evaluates the structural stability of every object in the scene on a continual basis as they take damage. Every kind of object from a knee-high section of retaining wall to a bridge the size of a football field undergoes the same analysis.

Number crunching then kicks in – objects being supported by the structure under stress are factored in, the stress code scans from top to bottom adding up the force generated by the mass above and compares this to the strength of the material. If that force is too much, the material breaks, which can bring the whole house down if it is the final connection. As the stresses increase and the material weakens, suitably ominous groaning and creaking sound effects kick in.

As Eric sums up: "The end result is a world that physically reacts to the player in the same way that real objects would – snap off two support legs of a tower and it will tip over sideways, if there happens to be building next to it the tower will crush the roof and tear a hole in the wall, if there happens to be enemy troops inside that building they will wake up with a splitting headache if they get up at all. And the best part of it all is that the engine is entirely player driven, they are given a set of tools, a list of goals to accomplish, and the freedom to solve them in any way they see fit."

It's fair to say that gaming's biggest bangs in the PS360 era have mostly been contained to cut-scenes, engine-driven if we're lucky. In fact, it can be argued that we've not seen apocalyptic levels of in-game destruction that aspires to this level since Criterion's Black on previous generation platforms.

"I would bet that many developers have tried, only to shy away in horror," says another of RFG's senior programmers, Dave Baranec. "The problem with a system like this is that it touches absolutely everything else in the game. It makes rendering tremendously more difficult. It makes level design extremely hard. It causes memory usage for what appear to be simple structures to be staggeringly high. So if you want a whole-hog destruction system like we have, you had better be prepared to pay for it with a ton of effort and sacrifice."

"It is freaking hard!" Eric Arnold adds. "Not only do you have to spend a whole lot of time to create the technology... but it also creates problems for every discipline on the game. Rendering guys have to deal with way more stuff to put on the screen and make it look pretty, AI guys and designers have to deal with the level constantly changing, sound people have to create assets for exponentially more interactions, then if you want online play you have to come up with a way to synchronise all of it. That's not to mention the memory and processing time that large scale destruction chews up. It is not a feature that can be dropped in to an existing game, it has to be planned for up front."

And that planning first begun back in 2004, before Xbox 360 devkits were in the hands of the developers and when PlayStation 3 hardware was still in its formative stages. Coupled with this is the fact that Red Faction: Guerrilla's core tech was actually based on foundations provided by the third party Havok physics library – a piece of code that must surely have been tortured to breaking point in its implementation in this new game.

"It really started out as an educated guess," remembers Arnold. "Even after we got the kits we weren't sure that our idea would work (we were told by the guys at Havok early on that it, in fact, would NOT work because it would put too much of a strain on their system). It wasn't until about two years in to development that we were able to prove that we could pull it off and make it look good, up to that point there was a lot of finger crossing that we would pull some magic out of our hats."

However, much of the pre-production work actually seemed to be based on feasibility studies on just how Volition would actually achieve its ambitions for the stunning destruction model.

"We knew that the focus was going to be an entirely new and very challenging engine," adds Baranec. "Before we could figure out the horsepower necessary, we had to develop the techniques for the destruction system in the first place. I'd say we spent the first ten months with just one programmer working at that level, along with one artist and one designer."

And as for Havok, let's just say that the team became very intimately involved with the creators of the physics technology that has become the de facto standard on PC and current generation consoles.

"The best way to think about it is: Havok is to Geo Mod 2.0, as DirectX is to the Unreal Engine or Crysis," explains Baranec. "It provides some core functionality, but the engine itself where all the fun stuff happens."

"We used Havok mainly for rigid body collisions, vehicle simulation, and ray casts," adds Arnold. "The entire destruction engine was custom built to sit on top of Havok, and we did have to customise a good bit of their internals (especially for the PS3 to get it all running fast on the SPUs). The guys at Havok were great to work with and joked that they all groaned when I sent them an email because we were stressing their code in ways no one else was coming close to, so the bugs I uncovered were particularly nasty."

One particular challenge facing Volition was that the sheer scope of their destruction model could in many cases overwhelm the Havok code, even when it had been optimised for the target platforms.

"Internally, the destruction system is capable of modelling and processing buildings of super high complexity," Baranec continues. "But if you let a simulation of that fidelity run, it is very easy to get into a situation where you are just presenting the console hardware with too much work to do. So we spent a large amount of time balancing out extreme detail with what the hardware can reasonably do."

Which brings us on to the question of where you draw the line between mathematically correct physics and just how realistic they need to be within the confines what is – at the end of the day – just a game. To what actual level of precision do the calculations have to reach before the effects become basically unnoticeable?

"There is a definitely a diminishing returns curve here, the problem is what is noticeable to the average player is a moving target based on what is happening in game at any particular moment," says Eric Arnold. "Knocking a hole through a wall right in front of your face is a completely different problem than a two story office building collapsing in on itself. We had handle both, and everything in between, without slowing the game down or pulling the player out of the fiction we created."

There's also the concept of you what might call "hero" physics to consider. As the Burnout team will tell you, adhering to reality too closely might well be the mathematically correct thing to do, but it will be to the overall detriment of the game.

"For the most part we stayed as close as possible to reality mainly so things react the way the player expects," admits Arnold. "But the rule was 'this is a game, fun trumps correctness!' The largest example is probably the sledgehammer. Not even the world's strongest man could tear through a wall or send a bad guy sailing the way you can in the game, but that doesn't matter because it feels good and is a whole lot of fun. If we insisted on realism the player would spend half an hour chipping away at a wall to make a small hole (or more likely give up after a few swings because it is boring)."

"One of my favourite phrases about game development is 'we're not making simulations, we're making games'," adds Baranec. "This is often used to chide a young programmer who is trying to get too fancy or complex with a new piece of code. A corollary is 'perception is everything'... what was important was to get a bunch of eye-pleasing objects flying around and crashing into each other in believable ways. Better to have a game than a mathematically correct simulation that takes 30 minutes to render a frame."

Red Faction: Guerrilla came under scrutiny in our recent Face-Off 20 feature, which also featured an extended high definition video showing that Volition's conversion work on both platforms is of a very good quality.

"This was one of our top priorities," admits Eric Arnold. "We knew from the start it would be cross platform even though the PS3 development hardware was still years off when we started. Once we got it and had the game running the two machines moved in lock step to the end of the project... Given how hard we are pushing the systems I'm still impressed that we were able to make them virtually identical, it certainly took a lot of hard work from some very smart people on the team to get there."

In our previous Burnout tech retrospective, Criterion explained its system of "balance points" – the notion of creating a game experience that runs almost identically on multiple systems by taking a holistic view of what each platform is capable of in its entirety. Code was essentially identical regardless of the hardware being targeted. An elegant approach, but while there were similarities in their way of handling things, the Volition guys optimised each platform individually.

"In terms of hardware specifics, the multiprocessing setups on the 360 and the PS3 are significantly different," says Baranec. "At some point, you simply have to diverge big pieces of code to efficiently deal with this. For us, the two big areas here were physics and rendering. Both areas had high level cross-platform frameworks, but when you get to the most performance oriented areas, they did diverge into totally platform specific code. Thankfully, the volume of code this represents of the overall codebase is very small."

Keeping the two platforms at the same level of performance did however incur several sacrifices from the team.

"We went as far as cutting optimisations because they would only work on one platform," reveals Arnold. "For our own sanity we tried to keep the internals as close as possible, but with the SPUs we had to do custom solutions at the time for performance reasons. For destruction, I had to physically remove functionality and code from Havok in order to make room for our system on the SPUs."

"Generally speaking, we like to keep both platforms developing in parallel. You can't really afford to let one platform slip behind because then it becomes difficult to make predictions about overall performance and features," adds Dave Baranec. "Which then impacts the ability to create assets, which then impacts the schedule, which then impacts the budget, etc."

Regardless of the challenges working with the current generation consoles brought about, the fact is that Volition and the GeoMod engine will be around for a long time yet – with the principles and fundamental technology now established, it will scale up to the next generation and even beyond. And for those lamenting the passing of the terrain deformation in the original GeoMod, there is hope it may return.

"In terms of an improved feature set, anything is possible," reckons Baranec. "The original GeoMod engine was a boolean solid operation engine, which made it ideal for terrain modification. While this is a distinct piece of functionality from GeoMod 2.0, there's nothing inherently stopping them from being rolled together into one world... What I find really exciting is that the tech is trivially expandable as hardware improves. The core system is capable of doing much more than you see in RFG. What limits us currently is how much rigid body simulation modern hardware can do. In that sense, the engine is very much a mean nasty dog that we have to keep leashed... for now."

Red Faction: Guerilla is out now for both Xbox 360 and PlayStation 3, with DLC announcements due imminently. A PC version is set for release on Friday, August 28.

Do you want to know more? The Digital Foundry channel is updated frequently with new technology stories and performance analyses. The full transcript of our interview with Volition will be running next week.