[In this extensive interview, executive producer Patrick Bach explains how his team at DICE built Battlefield 3 from the ground up, and what techniques enabled the team to create the game they wanted to create, and stay inspired -- from 2006 onwards.]

Battlefield 3 isn't a yearly update to a popular franchise. While some of the team that worked on this game also contributed to last year's Bad Company 2, the game has been in the works since 2006 in one form or another -- or perhaps even longer, if you count conversations that happened when 2005's Battlefield 2 wrapped up.

All eyes are on this game; in a world where the number one title in the console space has been a military shooter for the past few years, and the rivalry between Activision and EA remains hot, there's no question that people want to know if Battlefield 3 has the power to compete.

Executive producer Patrick Bach of Stockholm, Sweden-based developer DICE, and his team are well aware of this pressure -- though as he tells Gamasutra, the real push for success comes from within the developers. External pressures hurt, not help. Fortunately, he says, EA knows to trust its developers.

Bach, in this interview, discusses exactly how he manages his team, how work is delegated, and why working autonomously with an experienced team is key to the way in which the Battlefield series is created.

So, Patrick Liu, who I spoke to before -- you're his boss?

Patrick Bach: Yeah, you could put it like that. (laughs) We have a very loose hierarchy in the office. We try to, more or less, let people do what they're good at, and let them live out their urges to create great games. We don't really see it as like, who's boss or not. Even though you could argue that, yes, we have a hierarchy.

How do you do that on a project of this size?

PB: I would actually turn it around, and say that it's the only way to create a game like this. Because if you would have someone that controlled every little part of it, and tried to be the master of all the details, you would definitely fail.

Because the game has so many features, and so much depth in almost all areas, you need everyone that is working on the game as more or less an owner of that area. Which then feeds the creativity, and makes people do even more.

How did you control the scope? This is a very immense game.

PB: Yes. (laughs nervously)

And we all know that there tend to be things like feature creep and planning problems.

PB: Yeah, yeah, yeah. I'm super experienced in feature creeping. That's one of my best traits actually. I'm awesome at that!

When everyone loves what they're doing, everyone will feature creep. And that's both good and bad. It's good, because everyone will try harder to get even more things into the game, and find ways to do that, and put that extra energy.

The bad thing is that when you have a lot of stuff getting pushed into a game at the same time, stuff breaks, and it takes forever to get people off the project -- because the more people you have working, the more problems they will add.

This is the game that everybody's eyes are on this year. I think this game is the one everyone is paying attention to -- to see, "Can EA pull it off?" or "Can DICE pull it off?" On one hand, that does inspire that level of people wanting to put everything they possibly can into it, but…

PB: Well, I think it's more of a challenge. People put a lot of pressure on themselves to just make the best game they've ever made, and adding this pressure on top of it is not always helping. Some people get really, really scared, because they feel some kind of demand on them -- that they need to please someone that they might not understand.

We try to build games that we love to play rather than building games for someone else. Because we have so many different types of people in the studio, so if we like it, we think that we are a pretty good average of what the consumers are as well. So getting all this extra pressure is not always helping.

When it comes to scoping the game, was there a lot of external, publisher-side focus testing and that kind of stuff? Or was it all primarily internally decided upon?

PB: It's actually quite interesting, when you mention it, that we didn't do that much consumer testing. We did some consumer testing on the style and tone of the game, "What kind of style and tone do you want in a game like Battlefield 3?"

But we haven't really done much more than that. We get a lot of trust from EA that we know what Battlefield should be. And getting that trust makes us do even more -- because we want to prove that our view of a first person shooter is the best way of creating games.

You sound pretty confident. Do you feel confident about what you've achieved at this point?

PB: I'm always confident that I know what the team I'm working with can do. They can do miracles. But I'm never confident that I know that other people will like it. So to me, just seeing people playing it makes me nervous, because I don't know if they will like it or not. Just because I like it, doesn't mean that other people like it. So I'm probably very bad at understanding consumer research, but I'm very good at gut feeling. So I'm hoping that if I like it, if my team likes it, then everyone else will like it -- but my confidence is not that others will like it.

It sounds like a fair degree of gut feeling and intuition went into a project of this scale and this importance, which is almost hard to believe in a certain sense.

PB: Yeah, I know! I know. And come to think of it, why would anyone put this amount of money into a project that is based on gut feeling? You would think that doing more market research, doing more photo ops and reports, and more mechanical testing, would be the way forward.

But I think EA is such a mature company -- they know if they try to control the developers, they will just break things. And we have a lot of confidence from EA that we know what's best for the franchise. So that makes me very, very happy.

But then again, that also puts the pressure back on us -- because if we did consumer testing that told us that this was good, I could always blame the consumer testing. Now I have nothing to blame. I can only blame myself. And we in the team feel like, "Now, when we have done what we wanted, who will now back us?" It's up to us to prove it.

This is the first time in the mainline Battlefield franchise where we've had a single player campaign.

PB: Yes.

That must have put a lot of pressure to say, "How do we make the campaign live up to the standards that we set for ourselves?"

PB: Yeah, it is. It is actually quite interesting. Because people tend to see the single player as like, "Oh, it's the other part of the game." We have been building Battlefield games for so long that we see single player as the icing on the cake. It's pretty decent icing, but it's still a complement to what we see as the core of the franchise, which is the multiplayer.

So our focus is to make sure that we have the strong multiplayer component, because that's where we're going to spend the most hours. Single player you will play through once, maybe two times tops, because that's what people usually do with single player campaigns, and then they move over to multiplayer.

So we understand that our focus needs to be on making sure that the multiplayer is great, but we also want to use the power of Battlefield, the variety when it comes to locations, and vehicles, and different types of gameplay, and create an interesting narrative around that as well. But we do see it as a very pretty icing on the cake.

A couple years ago I think that would have been a weird statement, but when you look at what's emerged with these games, and with your direct competitor, at how the multiplayer sustains that franchise -- basically between installments.

PB: Yeah, yeah. I definitely think that if you don't have a strong multiplayer component in the first person shooter game today, then you better have a really, really good single player. I can't really see many games doing that, to be honest. I can't think of one, actually. There needs to be some kind of longevity in the product, and that needs to be beyond a single player campaign. Even if you had a really long one, it's not even close to how many hours you spend in multiplayer.

Were the people working on this game the same people who were working on Bad Company, or is it a separate team?

PB: It's somewhat the same people, yes. But it's far from only those people. This is a huge team, and we've had a lot of people working on it, and we've had for a long, long time.

I get the sense that it would probably out-scope anything you've done in the studio.

PB: Absolutely. This is way bigger than anything we did before.

How was that, as a challenge? Managing that, keeping that working?

PB: The challenge is actually accepting the right framework for everyone. What's the scope, what's the emotion, where do we put the focus? Rather than creating a design document, and then handing that out, and saying "This is what you're going to spend the next couple of years doing."

We have so many creative people working at the studio -- they only work at DICE because they want to build the games. So we don't really have to tell them to build a game; we need to tell people what game to build.

Because they will build a game; that's not an issue for us. It's more the framing of what that game is, rather than building at all. We don't have to tell people to put in extra hours to finish something, because it's their dream project. This is what they wanted to build, so they will make sure that it's great -- because they put so much pride in it.

To go back to what you said a moment ago about not really handing down documents -- you talked about people very much wanting to build things, and being specialists in what they want to build. But in the end, how do you get to the place where people are doing the right work?

PB: I think it's creating the right inspirational material. And one thing that is -- you could call it a trade secret -- but showing people what they have built is actually magic. Because there are so many people that focus so much on exactly what they're doing, that they never have time to look at it -- and especially look at it together with what everyone else is building.

So just showing the game to the team inspires the team to build a better game. And you can see that. When I look at a game it's like, "Wow, this is starting to look really, really good." And then you do some adjustments, and then you feed that back to some people, and they keep working on it.

And then when you show that to the team, when they see it, they get surprised. It's like, "Wow, this looks really, really good. That's my part -- but the rest is also really good." And you have all these people that are experts, that the focus is so much on what they do, that they sometimes miss out on the whole picture. And that's what I'm looking at.

So you could call it very, very easy to control a team of this size, because when you have talented people working in a team like this; the only thing you need to do is to show them what they've done.

Do you have a process for that, like a formal meeting every so often? Or do you just grab people, sit them down for a while, and just go?

PB: If you build things by a process, you will get the same thing that you got the last time you used that process. A process in itself doesn't build good stuff. You can use a process as a core of building, but then what you build needs to be dynamic. It needs to be based on different emotions, and different focuses at different times. So I don't use a process on inspiring people.

But there is a lot of showing the game. Again, for the whole team. It's showing one person what another person is doing. It's bringing the right people together in a room, talking about the problem, or talking about an opportunity to do something better. And then that spark turns into a big fire that creates a great feature.

So there's a lot of people that know what they want to build for Battlefield, and they will fight to do it. And sometimes it's more work actually to keep people down, and cut scope, rather than adding scope, because there's no one trying to avoid working, that's for sure.

When you talk about "if you use process you end up with the same stuff that you got before," where did you start at the beginning, with scoping things out? That's what I'm trying to figure out. If it grows organically and inspirationally, what do you start with?

PB: Well, this project started with, more or less, a simple kind of sketch on "What parts do we want to focus on? What is the core of the game?" And then you do more or less a balloon chart on different features, or different emotions that you want to have a part of this.

And then you can see that, "Oh, all these things together will actually complement each other in this area," and then it starts to grow from there organically. When you start, then, to show that to people, then you get feedback. That then turns into a more and more solidified vision for what the game should be.

And you could argue that you only have to fix what is broken, and since we've been building Battlefield games for quite some time, we know exactly who can build this area, and if you just let that person build that area it'll turn into good. But then what do you need to add to turn it into great?

So having a very senior team and experienced people around you helps. If I only had a junior team, and this was the first game they ever built, the process would have looked completely different -- so I'm adjusting everything to the people that I'm working with.

How much of it would you characterize as preproduction? How long did you stay in preproduction, and did it seamlessly transfer into production?

PB: Different parts of the game are shorter or longer in preproduction. Some areas, you know exactly what it should be. "This should be exactly like this, we can start producing it today," more or less. Other areas are more risk-taking and we said, "Hmm, we don't know how this will work, so we need to try it out for quite some time." And then when you know what it is, you build it really, really fast. So it depends on what area.

But then for the game as a whole, you need to have different phases for it. But some stuff might be sliding in and out of that phase. So it's quite hard, actually, to define a project. And again, looking back at what we talked about before, if you have a process that is strict and stale, you might not use all the potential of that team.

When you talk about different elements, are we talking about mechanics, are we talking about modes, are we talking about maps?

PB: Yeah, it's everything. It's everything from animation, to characters, to specific mechanics, gadgets, -- so there's a lot of different threads that run in parallel at all times.

When you have a production process like you describe, how much work ends up getting done that doesn't end up getting used?

PB: Sometimes, quite a lot. But in this project, actually less than I thought. I think it's because people were so focused, and they knew exactly what they wanted to build. Of course, you always end up throwing something away and there's like, "Oh, we built these things wrong -- and now we need to rebuild them from scratch again!" People get really fed up with that, of course.

But I think one very important part of building games is avoiding waste, because if you can avoid waste, you will keep people inspired. And if you lose your inspiration, then you won't do a good job. So keeping people inspired at all times is, to me, key. Because once you lose the spark, you won't do a good job.

How do you avoid waste?

PB: It's, first of all, having everyone understand what they're supposed to do. And "supposed to do" meaning, "How does it fit to the other stuff in the game?" Not only, "Just build it -- shut up and build it." That will never work, because then we definitely create waste.

Because if you just build something based on what someone told you to do, you will misinterpret it. You will maybe get an order that was actually wrong. And then you build it, and it doesn't fit, because you didn't talk to the person that it fit to, because that was not your order.

Again, if you're inspired to build something, you also make sure that it fits. And if you understand where it fits, you will talk to these people, and you will make sure that you don't create waste. And if you create waste it's because -- it could be any reason, but the waste will be minimal, compared to if you got an order to build something.

So I think that having people understanding how their work fits to other people's work, and thus being inspired, minimizes waste automatically. In my world, you don't need a process to do that; you need heart. Because that will automatically minimize waste.

And does that work on all the way up and down the hierarchy?

PB: Yes.

You say you don't really have one, but obviously there's some people building props, and some people…

PB: Yes. If everyone understands why they're doing what they're doing, and that they want to do, it and they want to make it great, then you will minimize waste in all levels of the hierarchy.

How long was this game in development?

PB: It's really hard to say, because the engine has been in development for a longer than the actual game, and some parts of the game have been in development for a very, very long time. So, some design things actually started back in 2006, and other things have been built later than that, so there's no clear date when the project kind of started.

I guess as a studio, you had it in your minds. You knew this was the big goal, and that you'd get there.

PB: Yeah.

Is that kind of how to look at it?

PB: Yeah. We knew that we wanted to build Battlefield 3 since we shipped Battlefield 2, of course. It's just a question of, "If you want to make that leap, what is it?" How do you avoid getting feature creep, how do you avoid getting some kind of "let's build something that we don't understand"?

You need to find a very clear vision, a very clear goal, and say "this is what we're building," and then build it. But that's actually harder than you might think, because there are always people that want to build something more, but they don't know what it is.

How did you avoid looking at the competition? A lot of games, that's very much what they do. They look at the competition either for "How did they solve this problem?" or look at the competition for "Well, this is what everyone else who has played our game has already played, so they're going to expect this."

PB: I think that's the biggest challenge we have. How do you get inspired, but not stealing, or borrowing too much, from other sources? And it's not only other games -- it's like movies, and books, and whatever media you might consume.

I think the important part there is to have a vision of where you want to be in two years, five years, rather than looking at, "What did we do last year, and how can we improve on that?" Because if you only look at what you did, then you will only get a small kind of version plus point one. It's hard to create something that makes you feel like, "Wow, this is something new, that I haven't seen before."

But by doing that, you also put yourself at risk. Because then you're building something. Us building a new engine to build this game -- if you look at it from a monetary perspective, it's stupid, and why would you do that? We could have built this game on the Bad Company 2 engine.

But then again you wouldn't get this. You would get something that felt more like Bad Company 2, maybe, and I think that wouldn't be beneficial for anyone. So I don't know, it's really hard. You want to be inspired by other things, yet you want to create something unique. But unique doesn't equal good, so you need to do both.

Unique doesn't equal good. It's a fair point.

PB: Yeah, everyone wants unique. But when they get it, they don't like it, because it's different. (laughs)

What's your perception of what gamers want? Original? Not original? And did that feed into your plans?

PB: Yeah, absolutely. Consumers -- I'm a consumer, so I know what I want. I want the same, but different. It's the classic "same, same but different" mentality. It needs to be similar to what I had, but it needs to be unique at the same time. And the question is only, "what is the same?" and "what is unique?" How daring do you need to go?

Because if you only did consumer research, you would only get feedback saying, "I want it like it was, but better." Yeah, but if you do it like it was, and better, it would be the same, more or less. It's not a new game. So our job is to create a new vision for something, that the consumer can say, "Oh, I get it! But it actually feels quite different. It's brand new."

And especially in the shooter genre. If you create a military shooter that is in modern day, and you use this environment, they might feel very much the same. So what do you do to make it feel different? And we focus a lot on the physicality, the presence in the world, the animations, getting it to look and play in a more physical way than we've ever seen before. And again, to do that, we need to create technology to support that, etcetera, etcetera, etcetera.

So you could see it as, "Oh, it's just a couple of steps forward," but to do that, you have to go back to the foundation of what you're building, and rebuild it from scratch. Because what we knew when we started the project was that you couldn't just add another building block on top of it, because it wouldn't feel new and fresh. So, to us, unique is being daring -- and just take down the whole house, build a better foundation, and build a higher building.

And that's why you wanted to work with a new engine?

PB: Absolutely. The vision for the game was bigger than we could have built with the old engine, and so we just have to accept our faith and start building a new engine from scratch.

And engine development preceded, but was concurrent with, game development?

PB: Yeah, absolutely, yeah. This is the first game that is released with the Frostbite 2 engine, which means that the engine is more or less done when the game is done. And that's never a good way of building games. Because if you look, again, from a more monetary perspective, you want the safe bet. But building an engine from scratch is not the safe bet. But then again, if you build a new engine and you get out on the market with a game that actually makes a difference, then you're years ahead.

From a production standpoint, did you reach a point where as you're building the engine, there are things that you couldn't work on, or you had to wait for? How did you manage that?

PB: Oh, yeah. Yes, absolutely. That's the biggest challenge with building a game at the same time as the engine. You have loads of memory issues, you have performance issues. The engine is not optimized yet. You can't optimize an engine that is not complete. You need to complete it, optimize it, build more stuff, and then optimize. So we had to, in some cases, fumble in the dark a bit. We didn't know if we could build it -- so let's build it anyway, and hope that our tech guys can get it together.

And again, you need to know your team, and I know our tech guys are super eager to create something that is truly magnificent. And just looking at the game running on a console that is five or six years old, I'm quite amazed to see that you can do these things with 24 players, vehicles, big open spaces, destruction. So if you compare this to, for instance, our last game, Battlefield Bad Company 2, this is way, way more "next-gen", so to speak, than what we did before.