Tech Interview: Crackdown 2 • Page 2

Agency resupply point.

Digital Foundry: The freeform nature of Crackdown combined with the extraordinary physics engine seemed to create a legion of great YouTube videos. Did anything in particular catch your eye there as an example of the tech being utilised in ways you couldn't have imagined?

Gary Liddon: We're massive fans of the mountains of great gameplay videos from Crackdown 1 you can find on YouTube. We really liked the vids by DuvalAK47, like Rubber Ducky of Doom and Infinite Jump.

We got in touch with DuvalAK47 (who turned out to be a particularly smashing chap called Dustin) and gave him and his chum some kits to make some more vids for Crackdown2. And he's made some crackers. Fights, Camera, Action is really nice.

Digital Foundry: Onto Crackdown 2 and in a basic comparison with the first game, overall performance seems to be generally smoother. Was there a concerted effort to optimise? Can you give us a general notion of improvements under the bonnet?

Janq: From the start of the project rendering performance was always one of my main concerns. I did a lot of work optimising CD1 and so I knew how close to the limit it was (often under 30FPS actually!). We also knew that we wouldn't have a large amount of time at the end of the project for optimisation so we just had to be very careful with anything changed or added. In the end performance has worked out pretty well - I'd still like it to be better, but it manages 30FPS most of the time.

CPU performance in Crackdown is kind of all over the place. Sometimes there is a lot to spare, other times there isn't - again it was just a case of making sure that what we added in CD2 didn't have a very big performance impact. More reliance on the crowd system for enemies is one area that helped a lot (since the crowd uses very simple and cheap AI).

Digital Foundry: There's a sense that Crackdown 2 has had something of an accelerated production cycle. At E3 2009 there was nothing to show publicly aside from a CG trailer. One year later almost to the day and we have a gold master that passed certification. Is this timescale a major factor in building upon the existing tech as opposed to creating a new engine?

Janq: Since we had little over a year to complete CD2 we had to take a very conservative approach. A lot of my time was taken up working on the art pipeline which by the end of CD1 was nearly unworkable (huge turnaround times for the artists - tools that sometimes worked and sometimes didn't, etc). I don't want this to seem like I'm putting the RTW folks down because I'm not - some really talented people work there, and some of them now work for Ruffian.

CD1 went through a fair amount of development hell during its time and by the end things were falling apart a bit. We needed to completely replace the art pipeline to make it possible to complete CD2 in such a short amount of time. Taking this into account we knew that we wouldn't be able to make massive improvements to the tech. We have made a lot of improvements and additions but it's definitely not a new engine. I still think we've managed to improve the look of CD2 a lot though. The lighting is nicer, there is much more detail in the middle distance, performance is better.

Gary Liddon: We had to be pragmatic and the timescale from inception to gold disc was around 18 months which translate to only around 12 months fully staffed production. During that time we also had to create and staff a studio so a big deal was picking our battles carefully. The guys who worked on CD2 are mature bright developers and in that timeframe a completely new engine was too big a risk to take on.

That said several key technologies were ripped out and rebuilt from scratch. As Janq mentions the data pipeline and world editor were real problems in the first game. It took a long time for designers or artists to see their work in the game (sometimes weeks) so that had to go in favour of something more practical.

And networking was a big deal. A full bodied hyper-kinetic physics-based experience in an open world is tricksy in itself. Taking that experience and scaling it across four players in real-world networking conditions without watering down that experience in any way is near impossible. Which is why no one else has done that before Crackdown 2.

Anything you can do in one-player Crackdown 2 you can do with three other pals and it'll look just as spectacular. Crackdown 1 worked as lockstep, was two-player only and each player had half the amount of active objects than they would get in a single-player game. That wasn't acceptable for what we wanted to do with CD2 so we had to some very exotic things in our network code to deliver the experience we wanted.

Digital Foundry: You could see in the original Crackdown that the engine managed to handle a lot of NPCs roaming the city in any given scene. In the sequel we have the enormous waves of Freaks infesting the city at night. Is this an evolution of the existing tech, or completely new code?

Gary Liddon: It's all new code so a revolution rather then evolution and a really challenging one at that. Not only do we have to render scenes with thousands of NPCs but we also have to keep them synced in a four-player network game under the fairly strict bandwidth limits imposed on us by the Xbox 360 TCRs.

Neil Duffield: For those reasons, the NPC crowd has to be as efficient as possible in many areas, memory, performance and most importantly bandwidth. Attempting this challenge was a bit daunting, but we feel we now have an engine which can be optimised in future to produce even more characters.

We managed to increase the NPC crowd count by around a factor of eight from CD1 to CD2, so who knows what we will have for Crackdown 3. The NPCs are fully LODed, in behavioural terms, so as you approach them they will be capable of different, more complex actions. This is designed to reduce the CPU and Network cost of all the characters, however they still have to be rendered, so they are also graphically LODed. In addition we have some very fast skeletal animation code (which certainly helps).

The characters also represent a rather large navigation problem; as we have so many of them, so we use a time-driven approach when calculating their position, which helps with compressing our network data and also provides a reference for keeping the characters in sync.

Comments (115)

Comments for this article are now closed, but please feel free to continue chatting on the forum!