Tech Interview: Need for Speed: Hot Pursuit

Yes, but we'd obviously change it again. The actual engine, the underlying engine - partly because of the latency, partly because of the online - the underlying code is running at 60. The game code is running at 60. You can see that on the PC version, the stronger machines will run at 60FPS.

So there are many reasons we wanted the game code to be running internally at 60. It's only rendering at 30FPS because we wanted the visual quality. The game has to look stunning. These cars deserve that. But the game itself is still running at 60 and we would definitely choose to harvest a lot of this into a future project.

Similar to the run-time it's version 2.0 of the tools. With Paradise we built this thing around an asset database of our own so we could have this big world that wasn't an enormous file, it's a database full of bits of world. We took that idea, we've hugely improved the backend database so it's orders of magnitude faster and generally a lot more reliable.

The old asset manager was called Game Explorer. This is a complete rewrite of what we learned. It's about a hundred times faster. As of today we've got over a quarter of a million parts that make up the game in this database. It's a relational database but it's fully branchable and fully version controlled. The guys that wrote it aren't aware of anything like it that exists. There might well be one but we've not read about it. We can just build a new part off for a demo, we can build new parts and branch them back, we've got history and everything.

It's all totally relational so we can find what's connected to whatever else so we know that this texture is attached to this bit of world and that bit of world, this animation is applied to that... It's fully traceable so we can traverse the game world up and down. That was all-new for this. It's all live-updatable so you can slide sliders and move light placements or right click and update a texture, it's all live and you can connect to multiple consoles at once and do it all there.

We spent more time, or possibly better quality time, sorting out the basic creation of roads. We've been making driving games for 10 years now and we've never really made it easy for ourselves building a track or a road. This time we did. That's a huge improvement and we've made similar kinds of improvements in how we iterate things like the gameplay and the UI.

Before, at the end of Burnout Paradise, we had had most of the team trying to put the final polish onto the UI because it was such a painful process. It was playing back Flash animations. While Flash gives you some elements of data driving, it means a lot of what you're doing is in the hands of artists rather than programmers. This is a good thing compared to the old PS2 Burnout days. We got rid of programmers as the bottleneck but ended up with Flash artists as the bottleneck as they're just as hard to find.

This time we moved onto something far, far simpler and far, far quicker. It's great. We can have a designer sketch out a new bit of the Autolog flow and have it in the game within an hour rather than a week, which is what it sometimes took in Paradise.

This whole workflow is a game-changer, and so that's what it's called, the asset database is called Game Changer. We place a lot of reliance on being able to change and iterate and improve at a moment's notice to make it the best it can be. For us a few weeks is a lot of time. What you see now won't be what you see when the game comes out. It will change, it will improve.

You played the game this morning. I'm willing to bet that if you go back and play the latest build there'll be something very different about it.

It does change quickly. We've always been driven and always recognised the need to change the content of the game up until the last minute because it's not until you get something in front of you that you can tell what's wrong with it. If you've got difficult tech behind that which makes change difficult or if you're just scared to change it, you're not going to make it better. So we've put huge amounts of value just in that ability to keep on making it better up until the point where someone says, "No, stop, we really need to ship this now," or if the QA guys shout at us to stop changing things.

At least now we're at the point where it's not tech holding us back when making a game, it's down to us having the ideas and the time to put it into practice. It's still the case unfortunately that it's quicker to have an idea than to implement it and find out if it's genuinely good - our ability to come up with ways the game could be better will always outpace our ability to deliver that. That's inevitable. But we're able to keep pace with the designers and the producers far better than we were before.

It's always going to come down to what's between the chair and the mouse. It's down to the person. A small team of passionate, experienced people working efficiently should be able to do an awful lot of amazingly cool stuff when they're not battling the tools. A small, good team should be capable of phenomenal results - that's where we're trying to get to.