Tech Focus: Killzone 3

For Killzone 2 we already had some pretty good stats to track frame-rate. With the flip of a dip-switch on the devkit an artist or programmer can see what is being drawn, what it costs (and who's fault if may be!). Although this gave us insight, it didn't always end up in a smooth frame-rate, some specific sections were bad or we'd have occasional hiccups.

For Killzone 3 we did a few things. First of all we wrote a tool called Autobot, which is a robot (well... server) that starts up each section of the game a few times a day and makes snapshots at artist-specified positions. It records frame-rate, polygons drawn and other vital stats, as well as make a screenshot. We have a technical artist that leads the optimisation who puts cameras at the worst points in a level and Autobot presents all of this on a web page. We can then see graphs over time of how close we are to hitting our performance target and our artists use these numbers to crunch down on geometry and shaders until everything fits.

That helps with the static analysis (of just the art), but what really matters is what happens when it gets in the hands of the players, on the final disc. So we have a special cheat code in the (pre-release) game that turns on some vital statistics on screen like poly count, frame rate and so on, and we capture this as movies. A tester plays the entire game from start to finish each build and we save the movies to a network share. The numbers on screen flash up in red when they go over our thresholds. This allows our optimising artists and coders to quickly scrub through the game and look for performance problems.

It's quite a simple mechanism, but it helped us find dozens of performance hotspots, frame-rate drops when certain actions happened and so on. This used to be difficult to spot and slipped through the nets, but the movies were very effective.

There were a lot of changes to all systems related to input, movement, gunplay and player response. We fixed a few bugs where we inadvertently added latency, but we also tightened up deadzones and the responsiveness of particle effects to show your bullet hit something. Anything that wouldn't change the weight, but improve the feel and control of the player we polished up.

"3D is all about immersion... there is such a difference between a vista looking out over an icy landscape on a flat screen, or in 3D where 3km viewing range feels like 3km."

We did a lot of testing with high-speed cameras to verify our changes and see if we were still on track. We also added a system to the engine that would track an event through the engine from the initial button press as it would travel through code, all the way down to when the RSX would send it to the TV. So you can see when the button was pressed, when the game code responded to it, when the bullet was fired, when the particle was spawned and so on. If the high-speed camera then indicated we had long latency or jitter, we could pin-point the exact problem.

Madness! Well, actually no. I don't recall it was suggested that we should do it as such. We got light of some 3D research going on and got to play with some prototype hardware which really impressed us. We got offered the opportunity to do it, played with the numbers a bit and then decided to go for it. We're always up for a challenge and this all seemed very promising.

Our basic technical approach for 3D was building on the work we did for split-screen. We knew we were going to have to run the renderer twice for two players looking in completely different directions with no coherency between them. We must be able to use that technology and optimise it to pieces if we have two eyes looking in the same direction, right?

We have a fixed resolution per eye. We've played with the idea of doing dynamic resolution, but I don't think the technique translates that well to shooters. We focused our efforts on optimisations so we wouldn't have to!

3D is all about immersion, feeling that you're really there, forgetting you're sitting on the couch, being on Helghan and wanting to get off the planet. There is such a difference between a vista looking out over an icy landscape on a flat screen, or in 3D where 3km viewing range feels like 3km.

We went for a full stereoscoping solution, not re-projection. This allows us to pull depth separation apart much further and prevent the layered feeling other techniques have. We also get proper stereoscopic reflections to boot and we can be much more free with things like depth of field.

The real trick of 3D is to not make it fall apart. Most people like 3D, but when something is off - your crosshair 'feels' unnaturally placed, you gun feels like it sticks through the wall, something you try to focus on stays blurry - it breaks for people. And when it breaks, it breaks the immersion.

We did a lot of work to avoid it breaking, we dynamically scale depth perception based on circumstances - some of them artist-driven, some of them automatic, depending on what the player is doing. The trick is in getting people to forget they're watching 3D and assume it as real.

A co-op campaign and split-screen rendering are pretty tough challenges to face. As a studio we hadn't done this in a long time and that's what we set as a challenge for ourselves to do, for entire campaign, no cheating, no short-cuts.

Doing it on PSN as well would be tricky because - like doing a 'normal' multiplayer game - game state needs to be synced over the network and in case of packet loss or other issues, things need to be arbitrated and made robust so nobody can get stuck, or cheat. Because we do the entire campaign in co-op, that means that all of our game code, even the one-offs, the end-bosses, they all need to be coded with network conditions in mind. We worried that taking on too much might distract us from delivering a solid offline co-op experience, so we decided to focus on that for Killzone 3.