Tech Interview: Need for Speed: Hot Pursuit

The circle is now complete. Just over a year ago, Digital Foundry kicked off its extensive range of tech interviews with the leading lights in game development by talking to Criterion technical director Richard Parr and senior engineer Alex Fry. Last week, we visited the Guildford-based developer to take a look at the new Need for Speed: Hot Pursuit and took the opportunity to meet up with Parr and Fry once more to discuss the latest technological innovations for their new game.

Need for Speed: Hot Pursuit represents a big departure for Criterion. This is no mere re-skin of Burnout Paradise - the development team has created a brand new engine for the game, with a different driving experience and a new graphical look far removed from their previous title. It's Need for Speed, but more than that, it's classic Need for Speed, brought up to date for the high-definition era with state-of-the-art rendering and physics.

We'll be talking in more depth about the game soon, and revealing some surprise information on the creation process, but in the mean time, it's transcript publication time: Fry, Parr and Leadbetter in the Criterion war room. This is what happened...

Digital Foundry: So, you wrote a brand new engine for Burnout Paradise and now it appears you've done it again for Need for Speed. Was there not a temptation to build upon what you created for Paradise rather than re-build from scratch?

Alex Fry: Yeah. We learned a hell of a lot in Paradise. One of the things you learn when you do a game... from your post mortem, you put together a lot of your experiences: what went well and what didn't go so well and what can you do better. Sometimes what you can do better means you need to make some big changes.

The biggest change we did was to the threading model for this game, so it's all new. We went from dual threaded which is what Paradise used. We had update and render threads. We dropped it and went back to one thread. The reasons for that were... well, there were several reasons.

Firstly we wanted to do a 30Hz game that looked stunning and we wanted fast controller latency. With an extra render thread at 30Hz you have serious latency issues so we went single-threaded. So 30Hz... it'll be really interesting to see what your latency measurements come out as. We think latency is pretty good.

Digital Foundry: It feels good. But obviously when you're playing the game you've got the display lag to factor in and all that sort of palaver. Thus far, from the games we've tested in our features, the record is 100ms for a 30Hz game.

Alex Fry: We think we might be 83ms... or 100ms.

Digital Foundry: Fantastic. WipEout at 60Hz is 83ms based on our tests...

Alex Fry: If we're more than 100ms I'll be very disappointed.

Digital Foundry: When you're using the latency board and you're counting the frames between LED and action on-screen, there is a bit of a grey area depending on what point during the 16ms window the LED is activated as the frame is recorded...

Alex Fry: Also, I'm pretty sure the consoles don't reflect the controller state to the game instantly. There's some kind of background processing in the console that gives you the information so it wants a 60Hz frame or it wants a 30Hz frame. I don't think it's instant.

Digital Foundry: And from what I understand, latency from the Xbox 360 controller itself is at 8ms.

Alex Fry: Wireless or wired?

Digital Foundry: Wireless, I gather.

Alex Fry: We've tried to get overall lag as low as possible. That's one of the reasons for doing the single thread. We played a few games that were 30Hz and they did appear to be dual threaded and they did seem to have a lot of lag. It wasn't a particularly good experience to play. The designers can't have had a particularly good time working with that and making it feel good. We also tried running Need for Speed dual-threaded at 30Hz in the early days, and it was too laggy for us.

Digital Foundry: So, define what you mean by single thread and dual thread. These consoles have a big array of processors on hand, so aren't all games multi-threaded almost by default?

Alex Fry: You have to use parallelism - you don't have to use threads. A classic way to speed up a game is to run a separate render thread. Your game simulation, your update physics, AI and all of that run on their own thread while your rendering is running decoupled from that in parallel, typically around a frame behind. Sometimes, decoupled it can render at an arbitrary rate and update at an arbitrary rate. In Paradise we decoupled it by a frame, so we always ran a frame behind the update but running in parallel with the next one.

Digital Foundry: I'm sure it's less of an issue when you're running at 60Hz.

Alex Fry: It is. Latency is less of an issue and it helps you to squeeze some more out of some pretty tight constraints at 60. With single-threaded we do sequential updates then a render and that's all within the one thread. One of the benefits of that is latency. That's a big deal. Another one is memory. You get an awful lot of memory back because you don't have to buffer.

When you buffer between threads you need to keep copies of some game state and data to allow it to safely execute in parallel. It adds a lot of overhead. You need to funnel stuff around and if you don't funnel it around you need to have lots of synchronisation. I think between Paradise and this game we must have saved in the order of 20 megabytes of memory. That's an awful lot just by removing that thread and all the buffering that went along with it. Part of our new architecture is about how all of our game modules talk to each other. Basing it on the knowledge we learned, we took the ideas of Paradise and implemented them differently: that’s the new engine.

Richard Parr: There was a lot of copy and paste from Paradise code where that code was good enough. Whether it's a new engine or not, it's at least a version 2.0 of the Paradise engine, not a 1.1.

Digital Foundry: It almost sounds like a different engine for a different purpose.

Alex Fry: That's one way of looking at it.

Richard Parr: The graphics side of things certainly is new.

Alex Fry: Put it this way. It's a new architecture but we harvested the best code from Paradise back into the new architecture where it made sense. A good example of this is Black. We harvested a lot of the rendering and physics code from Burnout 3 into Black. It was a completely new architecture, a completely new engine but we re-used a lot of the low-level building blocks to help us make Black. That's still true here. We didn't re-write every line of code. That would be insane.

Every company takes its good stuff and re-uses it. We didn't take our whole architecture, our whole engine. We did take large subsets of the code and reformulated it into the new architecture. We've always done that. We've taken it all apart completely and put it back together again in a different structure then replaced some bits, written some new bits and re-used some of the good bits but in terms of the architecture, the engine, it's an all-new structure.