Digital Foundry vs. Respawn: the Titanfall interview

When we started the company and tried to figure out what game to make, we didn't have an office, we didn't have computers. We were actually squatting on the floor that we're now in, before we even had a lease, we brought in folding chairs, sitting in a circle. There were like 30, 40 of us and there was a big group process, talking about games that we'd liked, games that maybe disappointed us and why - what we thought that would be great, or mechanics that would be great but weren't done well. Once we had an actual office and computers and a Perforce set-up, we were doing stuff - a lot of prototyping. Some of the early stuff was figuring out mobility in an FPS. It felt so limiting - go back 15 years to Quake, to Unreal, Doom, Tribes, stuff like that...

No rocket jumping, no crazy combos, no nothing... it's really flat. FPS games have become really one-dimensional for the most part.

Yeah, you know, Counter-Strike and Rainbow Six came out around the same timeframe. And they both were really popular and did things that made it accessible to the average person. You didn't have to be super-crazy-awesome with the best reflexes, you had the off-chance of getting a headshot with a stray bullet and people understand an AK-47 or an M9 - and that started the trend of trying to make things as realistic-feeling or authentic as possible.

It does limit you and one of the reasons we are a sci-fi game is that all that prototyping and stuff led to us having double-jumps and wall-runs and giant robots and all this stuff - and we needed a way to explain why this is possible with the world that we're making. We can't do that with a current-day setting so sci-fi really serves the purpose in creating a universe of our own that supports all of these things.

There's a lot of crazy stuff. I probably shouldn't say much. It'll probably come back in another game or something. We try not to work on something for too long that we don't think is going to work. It's always painful to throw something away but sometimes you have to, or we can save it for later when we have the time to finish it properly.

The idea was that when you're making a first-person shooter, you have a single-player campaign and a multiplayer game - you're really dividing your time and resources. We only have around 70 developers, we wanted to pool all of our resources into one experience. We had guys that were really good at single-player cinematic presentation and all that kind of stuff and other guys that were really good at core gameplay, multiplayer - so we wanted to mash that together. Basically we'll play through a story in an order and it's not just a random level here or there, and so each level tells its own little story. It's not so much a by-the-nose linear three-act thing - each level is more like a portion of the bigger picture of what's happening.

No, each level in the campaign will be like the level of a single-player game. It's telling its own story.

Theoretically you could do side patches or whatever to tell more of the story or flesh out the universe a little more. The idea is to give some context to the things that are happening and help tell the story that we have.

We evaluated tons of engines - all the well-known ones, and the not so well-known ones.

Yeah, we chose it because a lot of our designers wanted to prototype gameplay from day one and we had effectively 10 years of gameplay toys that were already in the engine from all the Valve games that we could use, like, "oh they did that in Team Fortress, let's pull that in and see how that works" and if it's good, then we'll go and make our own that's better suited for what we want to do.

At this point I hate to say that it's the Source Engine.

Yeah, I mean we've replaced... it's a whole new renderer, all-new audio code, all-new net code, all-new input code for gamepad. There's some stuff that we've just improved but we've done massive changes. We have our own level editor, we have our own lighting, the way that maps are compiled...

The thing about the Source Engine when we got it is that we actually branched from Portal 2. It was DX9, very single-threaded and they used the way that engine worked to its best possible potential for Portal. It can't render that much on-screen. The main thread just can't push out enough jobs, so we've done a huge amount of work. We didn't choose this engine because it was going to be 60, we chose this engine knowing that we'd be spending the next two years making it fast.

It's actually a pretty slow engine for showing stuff on-screen. What we have in a level now would run in single digits on what it was before - if you could even get it to load at all. It's been a huge engineering task, so what we did was put all the engineering [team] on the back-end so design [team] could be up and running at the task, otherwise engineering would have to be creating tools and design would be sitting around twiddling their thumbs. We only have a dozen or so engineers - it's pretty small for the amount of work they've done.

It's all-new. It's like going from a 360 engine to a PS3 engine - or more. It's now a 64-bit app, it's DX11, we've rewritten the way lightmaps are rendered and we have our own lighting system in it. It's not the crazy global illumination real-time everything. It's very tailor-made for our needs. We don't tend to add the whizzbang technical features just because they exist, so that's what we should have. We put more of our effort into design, gameplay and giving our artists the tools they need to make stuff look good. Good performance is our goal.

Yes, I do lots of latency testing.

[Laughs] You never know when these [issues] crop up, whether it's code, app or data. If there's a couple of frames of animation in there before it starts, like a reload or a jump animation or whatever. We want to make sure there's nothing in the way of that happening as soon as you press the button.

That's not true.

Our network engineer John Shiring wrote a really good article for our website, so you understand the basics of how it works. Based on demand in the region it'll spin up virtual machines and we have a package that has our server code in it that we can update whenever we need to, and it'll spin up an instance.

No - it's not done yet. Technically, if we worked really hard we could have the same server binary for all platforms. I don't think that's going to happen but it doesn't really matter. It'll just spin up 100,000 PC servers, 200,000 Xbox One servers...

Right, so all the AI is server-side, the physics... Well, some of the physics are still client-side.

Oh yeah, you have to. Even running a listen server - you know, playing on a server you're running - on any game there's still latency between the server and the client and without prediction there's still a weird feeling of disconnect. Prediction exists no matter what.

Well, absolutely. It's going to be a more consistent experience. On a client-hosted game you have one person who has zero lag. Everyone else depends on their route to him. If he's in North Dakota, everyone's going to North Dakota.

Yes. It's fairer. It's faster. It reduces headaches with parties and matchmaking, you don't need to worry about NAT traversals, host migrations. It frees up quite a bit of CPU time. On a client-hosted game anyone can be the server so you can't assume we have all CPU and memory resources available for the client. So you have to say, OK we'll set aside whatever it is - one, 10, 15% of CPU time - in case they are the server. Now we know that the client won't be running the server at all, so we have all available resources.

There are various types. I think ragdolls are client-side as they don't have any impact on gameplay. If it has an impact on gameplay we'll want it to be server coordinated. If it's not, like shooting a Titan with a rocket and pieces of him fall off, we'll run it client-side.

The good stuff we chose the Source Engine for - 10 years of gameplay stuff - also means that there's 10 years of legacy audio code that has so many things that are unnecessary. It's unbelievable, like a spaghetti-style codebase. So it got to the point where what we wanted to do was way easier than using what was there, so we started over. We're not doing HDR audio... It's kind of funny because it's more like LDR audio because you're limiting the range of what you can hear, but hey - it's great, it's awesome - but we have a finite time to finish the game, and we have our own sound designer who previously worked on Battlefield and Medal of Honor so he knows his way around making good-sounding games.

It's great. We have dev kits, tons of them. We have as many people seeing it as possible as often as possible. There are currently no visual rendering effects that aren't on Xbox One versus PC or vice-versa. Performance is always something we're going to be working on right up until we ship. I mean, the hardware's not done yet, the software's not done - our software's not done. There's tons of optimisation to do.

We're spring [2014] - I'm not sure if that's still the launch window or not. A lot of people will be launching ahead of us, which hopefully smoothes out the [development] process a bit. We would have loved to make launch because there's a certain amount of pride in coming out when the system does, but schedules... that kind of thing.

Other than we're having someone else do the porting of it.

We're not talking about it [laughs]. I'll say that the guys who are doing it are really smart and they're doing a good job on it. We're fairly hands-off on it. We're not telling them what to do but we have calls about it, we see it, we sync our Perforces... it's not going to be its own separate crazy off-shoot game with different content. The goal is to have the same gameplay experience.

We'll see how performance goes. Frame-rate is king.