Tech Interview: Need for Speed: Hot Pursuit
Digital Foundry visits the tech leads in Guildford for the inside story.
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...
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.
We think we might be 83ms... or 100ms.
If we're more than 100ms I'll be very disappointed.
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.
Wireless or wired?
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.
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.
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.
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.
That's one way of looking at it.
The graphics side of things certainly is new.
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.