The Devil's Workshop: An Interview with Diablo III's Jay Wilson
May 14, 2012 Page 2 of 5
You say that you were surprised by the high standard of quality that Blizzard has, and how that resulted in more hours of work. Can you talk specifically about aspects of the game that were affected by this?
JW: I would clarify. I wasn't surprised by the level of quality; I was surprised by how long it took to reach it. It just took a lot longer than I had anticipated.
It's hard to pinpoint any one particular thing. It's lot of areas where we had to do revision. We had this term in the development of the single player elements -- like the story elements, the scripted events -- that we developed late in the process, that we called "micro-pacing".
And it was all these little tiny things -- the encounter itself would be just fine, but after the captain finished talking, the gate that's supposed to open for you takes about a half-second too long to open. Or, this event doesn't occur quick enough, or spawn out enough, or there's not a transition that happens that draws the player's attention to the next place they're supposed to go.
And it was little things, little in-game events, seemed fine for us. We would play it, and we knew what was supposed to happen. But when we put it in front of other people... ehh. They would not feel good about it.
And at first we just thought the events weren't good. And we really had some support from the other designers, [who'd] come in and say, "No, it's really just these little things. You need a little polishing. If you fix these things then your event will be just fine." So you just underestimate how many of those things there are.
There's a lot of those little things, if you're talking about them in that minuscule level of detail. How long would you say Diablo III has been in polish mode?
JW: Probably two years.
JW: I mean, there's certainly more content being built during that time. It's not like the game was 100 percent done for two years, and then we just polished it. But I would definitely say that that's the time period that we spent where there was a good contingent of the team that was focusing on polish.
One of our sayings internally is "polish as you go." We have a belief that when you put a feature in, you should prototype, but then after you prototype you should do the real thing, and you should polish it to shipping quality.
You shouldn't just go, "Oh, it's good enough for now. We'll finish it later." It's like, "No. There's no later. There's now. Do it now."
Because when you put it in front of other people, if it's not polished, then they're not going to respond well to the feature, and you're going to get misguided, and think that maybe the feature or the content isn't good. But actually it's just fine; it just needs some polish.
It's amazing how game developers are not worried at gauging the quality of work that they're doing. We still do gray box tests, where we would do the environment and we wouldn't include any textures in it, we'd do minimal geometry, just to get a feel for the layout and how it felt to fight the monsters within it. And invariably we were incredibly poor judges of how the environment felt at that stage, because even we have struggled with imagining what the world would be. A lot of people need to see it.
And we certainly have people who can do that, and they tend to be more designers. Designers, I think one of their abilities is to imagine what's not there. But for even a lot of them, it's still a struggle, at a certain level of prototyping. If you don't go to a certain level of quality, it can be very hard to gauge whether your features are actually good.
It seems like with a lot of artistic endeavors, when you are the one working that close to something, whether it's a book, or a painting, maybe it just takes a pair of outside eyes to tell you what's missing.
JW: Absolutely. One of the major processes we have internally, we call the "strike team" process. Now we're doing strike teams on the team -- so we'll probably have to come up with new terms -- but the process is, basically, we put together a group of like a dozen people made up completely of people not on the development team.
So, take Dustin Browder, who is the game director on StarCraft II. He was our strike team leader, and he put together a group of about a dozen people, and they would play our game, and they would send us feedback. And at first, I kind of felt like I'd get the feedback and go, "Okay, I'll act on what I think I should act on in here."
And I quickly learned, nope. You act on everything in there. You find a response to every problem. The response to a few of the issues can be "that is the downside to the upside choice that we made." But most of them, you have to find a solution to. Because we have an enormous amount of faith that our developers understand quality, and understand what our audience wants.
You don't see that in a lot of companies. And a lot of companies, what you get is, you can do focus groups and things like that, and let the audience tell you what they want.
Focus groups are certainly good for some things. I think they're better for usability. It's good to put games in front of the audience so that you can figure out what confuses them and what doesn't work for them. But it's not necessarily good to put it in front and say, "How should the game be more fun?" Really, it's not the audience's job. It's the game developer's job to figure that out.
Page 2 of 5