Skip to main content

Long read: The beauty and drama of video games and their clouds

"It's a little bit hard to work out without knowing the altitude of that dragon..."

If you click on a link and make a purchase we may receive a small commission. Read our editorial policy.

The Making of Killzone 3

Guerrilla walks Digital Foundry through its latest technical miracle.

While Killzone 2 only used around 60 per cent of the available SPU cycles, the sequel sees Guerrilla tightening up its code and transferring systems across to the satellite processors, to the point where they are approaching capacity. Going forward, optimisation and rewrites of key systems would be required to free up more processing time.

Michiel van der Leeuw reckons that the Guerrilla team is now pretty au fait with the complexities of SPU coding. "By the end of Killzone 2, we had a lot of people on the team who were pretty comfortable with it, so it was just a natural progression for us to continue using it. We got to the point where they were all full though, so we had to optimise our SPU code quite a bit to fit it all in at the end."

One of the key objectives with Killzone 3 was to make the game a more social experience and this issue was tackled on two fronts. First of all, the multiplayer mode via PSN was radically upgraded with a whole new set of infrastructure, and while the game is already receiving plaudits for its online gameplay, it looks as though Guerrilla will be gradually improving the experience over time based on the new tech it has in place.

"A lot of the network code was scratched and re-written from the ground up. For us community is one of the most important aspects of multiplayer and although we were quite happy with Killzone 2's feature set we felt our networking systems wouldn't scale with what we wanted to do in future," says van der Leeuw.

"It's too bad that you don't get street credit for re-inventing yourselves, but we've got a much more flexible system now which is much more stable, responsive, gives us richer stats and provides a solid foundation for things to come."

More shots from Autobot. Here you can see how main system RAM and the RSX's GDDR3 are being utilised. XDR seems to top out at around 125MB or thereabouts, so we're not seeing a full memory map here - more likely just the sections relating to the level being profiled.

Secondly, Guerrilla implemented a split-screen two-player mode into the game, a considerable achievement bearing in mind that the core Killzone 2 technology was never designed with this feature in mind. Presumably for streaming purposes, players are kept within the same areas of the map (with catch-up in play should one player progress too far without his partner), but the technological challenges are still significant - two completely independent views, with two entirely separate rendering passes.

While fill-rate issues aren't especially an issue here, geometry still needs to be processed twice - a process Guerrilla solved with techniques including optimised LOD (level of detail) management. But simply getting the game logic in the single-player mode to accommodate multiple players is an achievement in itself, and Michiel van der Leeuw is keen to point out that the entire single-player campaign is replicated in co-op mode; there are no developer-side cheats, shortcuts or omissions in place.

There are limits to the implementation, however. Whereas some FPS titles could support a full co-op campaign featuring online play, the Killzone co-op experience is split-screen only, with no PSN integration. Michiel van der Leeuw explains the reasoning behind this decision:

"Doing it on PSN as well would 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," he says.

"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."

Part of that solid experience entailed creating a seamless gameplay experience - or as close to it as possible. Loading times were identified by Guerrilla as detrimental to the overall product (describing them as "very jarring and disruptive") so the team used techniques similar to those seen in Uncharted and God of War III to overcome the issue. Pre-rendered cinematics stored on the Blu-ray disc are played while the next level is loading in the background.

For the sake of consistency with the in-game visuals, the FMVs in Killzone 3 are generated entirely by the engine, rendered offline, then encoded using the Bink compressor.

"We could have cheated and oversampled them or do something else to make them look fancy, but it would defeat the purpose - people would notice and it'd drag them out of the game," adds Michiel van der Leeuw. But why choose Bink as the codec of choice bearing in mind its sub-optimal performance in so many games?

"Because we have the entire game streaming in data while we're showing the movies, we have to be very light on CPU usage and we have only very little memory to spare. Often games play movies when there are no game assets loaded, we play movies when all of the assets are loaded," he says.

"The more popular h.264 profiles require large buffer sizes, to deal with VBR or for reference frames. To use h.264 we'd have to drop down to a simpler profile and probably write a player which is optimised for our particular use, instead of quality and speed. In the end, Bink fares pretty well compared to other codecs when they're starved on memory and it was easy for us to integrate."