The Red Faction Tech Interview: Part One

From Digital Foundry's perspective as a commentator on game tech, Red Faction: Guerrilla is one of the most interesting releases of this generation, simply because the core technological concepts are intrinsically tied to a gameplay experience that is quite unique. I was determined to track down Volition and get them on the record about their techniques and achievements. The result was this feature published on the Eurogamer home page last weekend. But as with our Burnout Paradise tech retrospective, there was so much source material that we had to omit a lot of great stuff. So, here's the complete interview, split up into two parts. The concluding section will be published tomorrow.

Digital Foundry:
Can you explain the reasoning behind the move from first person to third? I can see the advantage of giving you a more strongly identifiable character, but what impact does it have on the gameplay from your perspective?

Sean Kennedy:
Early in development RFG actually started as an open world first person shooter. The change came as the result of the first person perspective not meshing well with destruction. Having a fully destructive environment it is important for the player to see everything around them. For example, when the game was in first person you would be inside of a building and start trying to break down the walls. Soon the stress system would kick in and the building would start to fall apart around you. Suddenly you would die but not realise why. It would end up being that a piece of debris would fall from the crumbling ceiling above you but you couldn't see it due to the perspective.

In the end you spend a great deal of time constantly adjusting the camera to look out for debris and if you managed not to die from it you would miss all of the destruction because you are running away from everything. So just as an experiment we pulled the camera back away from the player character, who was always there, to see what the difference was like. It was night and day. Suddenly the whole world was open to you and you could finally see all of your surrounding and see the destruction. After this there was no going back and it was the best decision for the project. If you are going to spend so much time creating the first truly fully destructible environment, then you've got to be able to enjoy that and just die all the time. That's not fun.

Digital Foundry:
Obviously we're going to talk about the destruction, but first let's discuss the move to an open world. What was the core reasoning behind this transition?

Sean Kennedy:
The move to an open world was really just a natural direction to go into. Open world and having full destructible environments just mesh together so well. If you are going to give the player the freedom of full destruction, which it is a freedom, then you need to give them the freedom of movement and choice in everything else they do which was a goal for RFG. Another reason is that as a studio we have made our focus be on open world gaming, starting with our Saints Row franchise and now the transition of the Red Faction franchise into the open world.

Digital Foundry:
How do you begin to conceptualise building an open world in what is quite literally a completely alien environment?

Sean Kennedy:
Being set in an alien environment in a way actually helps in that it allows us to be more creative in designing what we want our open world to be. We are able to take more liberties in the shape the world takes and the rules within it. Generally when you think of Mars you just picture a rugged red environment and we used that as our basis, but expanded upon it. When looked at what the planet is and created a look, feel and direction for what we could picture that world becoming. Thanks to the fiction of the terraforming process, we are free to shape the world to whatever vision we want. At the same time that is challenging too in that you need to have the right people on your team who can create something that works both in a gameplay sense and visual sense from essentially nothing. Fortunately we had an incredibly talented team of people who in the end were able to create something truly special.

Digital Foundry:
You started development in 2004, meaning two things – firstly that RFG is a five-year project, and that secondly, you started pre-production before you had 360 devkits and when PS3 must have been pretty much a complete unknown. Bearing in mind how technological performance plays such an important part in the game, how could you have anticipated the amount of horsepower you'd have to play with?

Eric Arnold:
It really started out as an educated guess. 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.

Dave Baranec:
At that stage of the project, I would say we were in some sort of entirely different state than even pre-production. We knew that the focus was going to be an entirely new and very challenging engine. 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. Generally speaking, there are two levels of optimisations involved in developing low level tech. Algorithmic optimisations where you are reducing the overall computational complexity of a problem, and micro-optimizations where you are fiddling around in some hotspot and trying to tease better performance out of it. Contrary to popular belief, algorithmic optimisations are most often where the very big wins come from. So, even though we didn't have final hardware, we had a broad feel of where it would end up and were able to bring the computational complexity of the system down to a manageable level at that time.

Eric Arnold:
Absolutely. There are custom tools in Max to add destruction information to a normal mesh, and we built a custom level editor from the ground up to allow designers to quickly build and iterate their levels. In the game we had to rig up more custom tools and displays to let artists and designers see what was going on behind the scenes. Early on in development it was common for buildings to fall apart shortly after being added to the game because they were structurally unstable. Without tools to analyse what exactly was going on they would have had to blindly guess and spend way too much time using trial and error to stabilize the building.