Karl Magnus Troedsson, general manager at DICE in Stockholm, has been with the company for 11 years now. He began as a producer on the RalliSport Challenge racing series, which was work-for-hire, published by Microsoft prior to the studio's acquisition by EA. His first Battlefield title was the original Bad Company.
In this extensive interview, Troedsson speaks about what the team has learned over the years of creating the successful Battlefield franchise and how that then is fed from the creative core of the studio out to other developers. He also speaks about how the company views its staff -- both from the standpoint of how to best utilize them on game projects to the culture of the company and why that's so crucial.
Troedsson tackles the topic of innovation, saying that "sometimes, I think we get too much crap for not being innovative." He explains how the studio fosters innovation, where new ideas come from, and how best to integrate them into an overarching, popular franchise like Battlefield.
In your GDC Europe talk, you talked about the "everything and the kitchen sink" approach that Battlefield originally had. How did you make a determination, as a studio, to move to focusing directly on what was important for the series?
Karl Magnus Troedsson: Well, one thing is it comes out of having a long-lasting franchise like Battlefield. Once you've done the first push to get everything into the kitchen sink, you actually have it in the sink, and then you can continue building on it. So the first iteration was actually the hardest.
And then, if you're smart about it, you always take what you have and then you add something new, you polish some, and some of it you actually just keep the way it is. So you always evolve the actual game from the one to the next one.
So from this point on, I would just say that it's come from the fact that we've realized that quality isn't always the same as just pushing everything we have into the game. And quality is not the same as just having super innovative features; quality needs to come from both.
You need to have innovation in the form of new features, or something you have changed that is really innovative -- but also just spending time on polishing it or, like, owning it. Because otherwise, you can have the best feature that is new or cool or whatever, but if it's buggy, or it doesn't work as intended or whatever, then it doesn't matter.
So it's a balance of everything, in the end.
When you say, "spend time polishing it", how do you plan for that in the production cycle?
KMT: Well, the old production cycles like, "oh, we hit alpha", and then you start polishing -- that doesn't work anymore. Because first of all, alpha is a very fluid state, I would say. Every piece of content should be in the game, and you should actually be able to ship it; that's how some people define it.
But what we do inside the studio is that we set hard deadlines before the alpha -- sometimes we call it a "pre-alpha", and that is when the whole game is complete with everything in it, where we say, "every piece of content, every feature," etcetera.
And that's part of the development phase that we just call "polish". And it's hard, because usually you just want more in there all the time. So at that time you just go, "Oh, we'll push it a little further." We cram that polishing phase, and make it smaller and smaller, but that's when you shoot yourself in the foot. And if you keep a serious amount of time where you just polish the game, that's when you can get it up to quality.
Does it vary from project to project, or is there a rule of thumb in terms of how long you think you need?
KMT: It's a bit varying, but at the end -- where all pipelines, all engines, all technology, everything is working perfect, you have the entire game -- you can look at it, you can play it, you can feel it, you can sense it, listen to it, look at it. Then you can do a lot of progress in just a week.
But we're talking months, here. On a big project like Battlefield 3 or something, you want like maybe one to two months to really polish the game, and that's before you start fixing the bugs. So then you hit some kind of an alpha, or whatever, and then you start crunching all the bugs as well.
Are we talking about things like modifying like timings of, say, shots or damage? What are we talking about?
KMT: Well, it depends quite a bit, actually, when it comes to comparing multiplayer and single player. Because multiplayer, which is in our DNA mostly, it's been an iterative process all the time. From day one, we are playtesting the game. Every day there's a new playtest, a new mode, or a new map or something. People give feedback, the multiplayer team goes back in, and they change and update. And that could be, like you said, updating the weapons or ranges -- the small nitty-gritty details, these kinds of things. So that happens all the time, just like an iterative feedback loop, almost.
But another example is on the single player side, where it's more like, build the whole thing and then you take a serious look at, "Okay, so I'm on this field right now, I can see troops running down there -- how can we make this more spectacular?" or "Is it actually too much going on right now? Should we just remove the troops from there, so you have a quiet moment, so you can actually assess the situation and be a bit more tactical? And then we throw everything we have at you when you get down the hill," or something like that.
So you actually move things around -- you change the scripting of the mission, you change where you place your AI, and where you want like, "Oh, the cutscene shouldn't kick in here, let's put it further away," or something. Or even down to, a lot on the polishing on the art side is like, "Oh, we want the sun over there instead, so you get the flare through the trees," or whatever. It might be, "We want more bushes here, more foliage," etcetera.