The Devil's Workshop: An Interview with Diablo III's Jay Wilson

Prior to working at Blizzard, Jay Wilson worked on some big games, including Company of Heroes and Warhammer 40,000: Dawn of War while he was at Relic. But none of his previous games were as widely-anticipated -- and garnered as high expectations -- as his latest work: Diablo III, launching this week for PC and Mac.

As director on Diablo III, Wilson had to digest everything that the 16-year-old Diablo franchise is known for, lead a team to determine what this latest entry should be, and how the Diablo team could achieve that vision. Reaching goals, said Wilson, meant crunching for quality, intense polishing, and listening -- as well as not listening -- to player feedback.

Diablo III is the first game that he headed up at Blizzard. Even though he was familiar with the high quality bar at the company, he told Gamasutra in this interview, "It just took a lot longer [to reach that standard] than I had anticipated."

I just read the Diablo II postmortem on Gamasutra, and about the crunch at the end of its development. How did you handle the final stretch for Diablo III? Was there just some massive crunch, like there was with Diablo II?

JW: Oh, yeah. We had a pretty big crunch. I wasn't there for Diablo II, so I can't really speak to it exactly, but as a company, I think we've gotten better in how we handle crunch. It's a little bit more phased, and we're able to take down certain [development] groups and give them rests. Not everybody really finishes at the same time.

There's the ability to keep people busy without keeping them in crunch when, really, their work is done. So a lot of it really is not just because of the time they put in; it's really the stress of trying to make the right decisions, and having so many balls in the air at once. Projects are really big now, and there's a lot of logistics to finishing them.

One of the first things we try to do is we limit how much time people actually work. We actually send people home so that they don't overwork. Our crunch was long, so what we try to do is make it long but not hard. We'd have weeks where we would just tell people they couldn't crunch at all.

Part of that was if we had a group that we felt was ahead, we'd tell them, "You guys are ahead. Don't crunch for a few weeks." Other groups, they weren't ahead, but they were tired, so we would give them a week off from crunch.

So we do things like that. We also just had groups that finished earlier than others. Mostly on the art side. The art finished early, which was a good thing -- you kind of want art to finish first.

So we have more capabilities now, when we have a group finish [their work]. In previous games I've worked on, you don't want anybody to finish early, because then what do you do with them? They're just sitting around. Nothing good happens from people sitting around. "Idle hands" is really a true statement. [Ed. Note: the full idiom is the "idle hands are the devil's workshop".]

And so we have a lot better management now, so we're able to do things like training courses, and help out some of the other teams. So we have a lot more capabilities to say, "Okay. It's okay for us to finish, to have this other group working, and have these other groups stop." So [we have] just a little bit more sophisticated ability to manage people.

How do you define crunch?

JW: For me, crunch is when people are generally working over 50 to 60 hours a week. That much or more. Essentially, if they're working more than 40, then I consider it crunch -- but for an extended period of time.

I think we always say -- one of the things that I try to push to the team -- is that while game development cycles have a tendency to crunch towards the end, usually for a few reasons, at Blizzard, it's actually driven by quality.

But most companies you work for, it's not actually quality that makes you crunch. It's usually bad planning, and a lack of focus. So if you can, for the majority of your project, be really focused -- and do like little mini crunches. Like once a month you have one week where you work a little extra to try and hit a goal, you can actually alleviate a lot of the end crunch.

And you've got to couple that with an appropriate level of ambition. I would actually say on Diablo III, we were overambitious in a lot of ways. I, as a game director, kind of underestimated the amount of time it would take us to get to the Blizzard quality level. I hadn't made a Blizzard game before, so now I know better, and I think we can do an even better job on it.

You came from Relic, just prior?

JW: Yep. And I worked on a game called Impossible Creatures, where we crunched like crazy, and then I worked on a game called Dawn of War, which was a lot less time and money than Impossible Creatures, and yet we made a better game and we actually didn't hardly crunch at all. And it was because I had really good understanding of the capability of the team, and what would be an appropriate ambition level for them.

It was a very ambitious project, but everybody was very focused on what the game was supposed to be, and how it should work. We all worked together before, too, which is a huge advantage. Because if you have a team that has put something out together, I wouldn't say their quality necessarily goes up, but their efficiency goes way up.

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.

That's incredible.

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.

How do you handle fan feedback? Of course, there was the art controversy a few years ago. Were there any aspects of the game that fans criticized, and you thought, "Hey, these guys have a point"?

JW: Well I actually can honestly say that I don't think I've made a decision on this project, or the team has made a decision on this project, that hasn't been criticized by someone.

So you learn very quickly to listen, and decide whether you agree. And that's critical. And that's one of the things that I think, when we do get criticized sometimes by some people in the audience, saying that we're not listening -- it's really more that we're not agreeing.

Listening and agreeing are two totally different things. And if we listened to everyone complain and try to solve all their problems, we would have a mishmash mediocre mess of a game. I can't even get two groups to agree, a lot of the time, about exactly how they disagree about something. You have to listen, but you still have to make your own judgment call.

And so a lot of the times we've had a lot of negative responses to the skill system [from fans]. We looked at the complaints that we had, and a lot of the complaints were, "Okay, that's not reflected in what we see internally." The problems that they're running into, the things that they're complaining about, we're not seeing. That's not what we're seeing internally when we have people test the game, when we look at our own developers playing the game, and listen to their responses. Is [the complaint] invalid? No, but is it a downside that we can accept? Yeah.

And that's usually what it comes down to. I think people think that a perfectly designed game has no downsides, has no cons to it. I think a well-designed game has lots of downsides and cons, because if the developer made an interesting and well-designed game, it means they made really strong choices. But strong choices always have downsides.

Design is a real, real gray area. So I think it's better to make a strong, bold choice for a more interesting game. I think if you look at any of the games that people really, really love, there's some very, very strong choices there. I really love Skyrim, but there's a whole different design paradigm at work in a game like that than in a Blizzard game.

You never see a game like [Bethesda's] Skyrim come out of Blizzard -- just because. And it doesn't mean [Bethesda is] wrong. Their design philosophy has been extremely successful for them, but it's a very different one, and it has its own pros and cons. And it's the fact that they focused on it is what made them successful, and we're the same way.

For us, good design has a lot of depth and is very approachable. That's always our first priority. And the problem that you run into is we attract a very hardcore audience, and hardcore audiences don't like things to be approachable. They like their hardcore game. They like their elitism. And that's just not what Blizzard's ever been about.

It's not that we're not about our hardcore audience. If anything, we think we're more about our hardcore audience, because our goal is to make more people become them. But we don't do that by making our games obtuse and hard to get into.

It's funny that you say that. In this Diablo II postmortem, [former Blizzard North VP] Erich Schaefer described the "mom test." Is that still used at Blizzard? It was the same idea; you just get a mom to understand how to play the game.

JW: Yeah. Oh, my wife and daughter -- more my wife, she's not a gamer, but my daughter has no choice, because she's my daughter. [laughs] My wife is one of my main testers. I love just to watch her play the game, and I've totally done several tests where I've watched her play. We brought in people externally, and we basically do the mom test. We do it more formally, now.

As I said earlier, I don't believe in focus groups for telling you how to design your game. I do believe in focus groups for telling you what's wrong with your game, where it's confusing, where it's too hard, what players can't grasp or understand. Those things, I think, are super valuable to bring people in, essentially, and do what Erich calls the "mom test" -- which I think is a great way to put it. Valve, I think, calls it a tissue test, or something like that. Yeah, it's the same basic philosophy, and I definitely think it's a great way to go.

Did Diablo III have an official design document?

JW: No, not really. I certainly had a PowerPoint that I put together, which described high-level pillars of the project, and was seven things that we considered to be the core of the game.

Do you remember what those were?

JW: Those seven things were: approachable, powerful heroes, highly customizable, great item game, endlessly replayable, strong setting, and cooperative multiplayer.

We basically said these are the pillars we have to live by. Each one has a description of what they mean. And any time that we have a question about what the game should be, we just look back at those pillars. And that was our goal. That was how we set the project up.

We had some others, too, that were more [about] what we're adding to the project. And they were more feature-based, so for example, the PvP mode was one. The bigger focus on RPG elements was one, because we wanted it to be a more story-based game, without getting in the way of the action. So there were a few more like that.

But we didn't have a formal design document. I don't believe in the big design bible. I've done it before, and nobody reads it. I think the only purpose for having a design bible like that is for the guy who wrote it. If you, as a designer, you write a bible to get your head around your vision and your idea, write your bible. But don't ever expect anyone to read it. Don't even show it to anybody. Nobody reads that.

A lot of people are saying that; it's not just you. I think that a lot of people in interviews like this, with the industry press, talk about that. Or you see them at GDC, and they give a presentation; it's definitely not just you that's saying "screw design documents." They're talking about getting the actual feel down, iterating and iterating. How do you even start with that?

JW: Well, so what we did was we wrote those pillars. I think those pillars are really important. Because they're also things that everybody can hold in their head really easily.

There's a presentation. You don't hand a document to people. People won't read. That's the key. People do not read; doesn't matter what. Nobody wants to read a document, and if they do read, reading a document doesn't get them excited. And game development's all about getting people excited. Games are cool. Reading a document's not cool.

Reading a book is cool. [laughs] I don't want to put the message out there that reading is not good. But what I mean is, if I want to read, I want to read something cool. And a design document for a game, no matter how you spruce it up, ain't cool.

But I can sit here and tell you about a game, and I can get you excited about it. And that's what it should be. It should be about the team talking to one another, and should be about core ideas that everyone works to realize.

And maybe just pick content to build. The best thing you could do to make a game is to start making it. Don't worry about the high-level. Worry about the barbarian. That was the first thing we did. It went something like, "Okay, we're going to make Diablo. What's our first plot?" Okay, barbarian. What's one skill we can make that can sell the idea of what we want the barbarian to be?

And I was like, "Well I want the barbarian to be more powerful. I want him to be like The Hulk. I want him to shake the ground. I want him to be able to cause earthquakes with his fists." Okay, well, that's our first skill, then. We're going to have him hit the ground and make an earthquake. Okay, cool.

And then once we had that skill, and that skill was awesome, it was so fun that people could just play the game for hours just using that one skill. I didn't need to do a document about what the barbarian was. Everybody knew. They looked at that skill and they understood him. And that was way cooler than a document.

And yeah, I had documents on the barbarian, and I had some stuff that I wrote out, and things like that, but none of them were nearly as valuable as that -- as that one skill.

Usually what I use documents for is I do technical documentation for coders, so that they can implement features, or to write down large collections of data. So for example, we have documentation on categories of monsters, because we have all these different kinds of monsters that we're going to put in the game, and there's stuff to challenge the players in different ways, and be unlocked at different points. So I have documentation for that.

And the kind of key theme for anything that we document is: it's all functional. It's not about intent. I actually tell my designers if they don't want to put things in their documentation, I'm fine with that. You write out what you want your feature to be, and don't justify the feature. Don't say, "This is why we're doing this feature." If somebody wants to know, they'll ask.

They'll ask why -- or you should tell them why. A designer can sell the idea behind a feature way better than a document can. It's time-consuming to make documents.

They'll go out of date, and then nobody trusts them. All it takes is one document out of date, and then, all of a sudden, nobody trusts any documentation, and it all becomes a big waste of time.

I played the beta when you were doing those stress tests, and I used the barbarian. That was the first time I had played Diablo III; it just feels good. One of my friends who is a game designer describes it as "crunchiness."

How do you hone something like that? You were talking about making the barbarian feel like The Hulk, and making him feel powerful when he hits the ground. What's the mindset trying to accomplish that in terms of a good feel for the gamer?

JW: Well I think first thing you have to do is, you have to be able to paint a picture for your development team. A very, very clear, powerful image of what you want. And you have to not be afraid -- we call it the "come to Jesus" moment.

Every one of our processes have had that moment, where we officially come back and say, "You know what? Not good enough. We're going to rework a lot of this stuff. We're going to make some new skills. We're not hitting it." And you've got to be willing, at those moments, to shake things up quite a bit.

The witch doctor was actually one of the ones I had the biggest moment with. We all loved this idea of this witch doctor, but we never really doubled down on what he was supposed to be, you know? We didn't really have a clear image, and that was when we got together.

We had him doing abilities similar to some of the abilities that the sorceress and necromancer did in D2; a wall of fire was one of his abilities. One of our guys was like, "Screw that, I don't want a wall of fire. I want a wall of zombies." And everyone was like, "Are you crazy?" But some of us were like, "Yeah, crazy like a fox. A wall of zombies sounds awesome!"

We had no idea how we were going to make it, but we knew it sounded great, and you have to have those moments. And then you have to double down on them, and really sell them.

That's a lot of ephemeral-speak -- it's not solid. Somebody is going to read this interview and go, "But he doesn't really tell me how to do that." And the problem is it's not an easy thing to tell people how to do.

The core of it comes from being honest with yourself about when it's not hitting it, because a lot of people, I think, they reach the point where they don't reach that crunchy point -- which I think is a great way to put it -- because they're not honest with themselves in that they haven't reached it yet. As soon as you're willing to look at your current work and say, "It's not good enough, redo it," or even have the capability to do that, that's when you can start getting to those moments.

Does Blizzard still have this "bring your ideas to lunch" type attitude, where you're just exchanging ideas in the hallways? Where it doesn't matter what discipline you are -- somebody in programming has an interesting design idea, a designer says, "That's a good idea," and the idea becomes reality?

JW: Yeah. That's what we aspire to. I think at times we can fall into the trap of being too separated by discipline, and it's actually something on the Diablo III team that we're working, right now, to make much better. I'd always been of the belief that a designer's job is not to come up with all the awesome ideas -- that there's no end of awesome ideas that can come from any source on the team.

A designer's job can make sure that the right awesome ideas get into the game. Because we do a brainstorm for a new class, we get anywhere from 400 to 700 skill ideas. And there's a whole bunch of them that are awesome, but they either aren't right for the class, or they aren't right for the game. That's the designer's job: to know the difference. It's not an artist or producer's job to know that. It's the designer's job to know that.

Builders are supposed to know the mechanics of the game; they're the ones who are supposed to know the overall vision of the character, they're the ones who are supposed to help define that.

And so a lot of the times I think you see people get into design because they have a lot of ideas and they think, "If I'm the designer, then everybody just has to do my ideas." And I would say if that's your reason to get into design, please don't go into design. That's a terrible direction to come from.

If you are a designer on a game, you will get your ideas in, by the sheer fact that you will be implementing a lot of things. By the sheer fact that there's a lot of areas of games that people don't have any ideas about, and don't want to. So don't worry about whether all the ideas are yours.

If anything, your goal as a designer should be, "I can't wait to get somebody else's ideas into this game," because you're not going to be the one making it. Your art team and your programming team are going to do a ton of the hands-on work. You're not even going to be able to work until they do their job.

And if their ideas aren't there, and they're not excited, then the tools and things that you're going to get actually implemented are going to be weaker, and your work's not going to be as good.

So you have to make it about the team. You have to make it about the ideas that come from everyone, while at the same time accepting you're going to have strong opinions about it. There are big, passionate ideas on the project that I shot down because I didn't think they were right for the game. I still have people who think we really should have done that, and I'm like, "Nope, we shouldn't have."

How do you manage to balance milestones, the expectations of Blizzard and Activision Blizzard, and the attitude of "it's done when it's done"?

JW: The thing I always try to explain to people about the "it's done when it's done" thing is the reason we don't announce dates is not because there isn't one. The reason we don't announce dates is because we often don't know, until we're fairly close to the date, whether or not we can hit it or not.

So to the team, we say "this is the date," and the team shoots for that date, and they do their best to hit it. And then that quality is not something you can always put a date on.

We can know we're going to be done with X amount of work by this date -- we know that. What we don't know is the intangibles -- we thought this system worked, and then we played deep into the game in a way that we haven't been able to before, because content didn't exist, and the system falls apart. So we have to rework that system. So quality is what you can't account for.

And since you can't account for that, and it's not a compromise element for us, that's why we will move a date. We don't give dates because we don't like to promise things. It's very important to us. And so for us -- we don't like to lie. This lie where, if we give a date and then we don't hit it, we consider that lying.

Now, there are other things where we'll have a system in and we'll change the system. We don't consider that lying, because we tell people all the time this isn't final, and it could change dramatically before the end of the game.

But we found in recent years that we like that dialogue with the audience. We like them to see our development process. We used to be a lot more secretive, but now we see a lot of value in them seeingthe process that we go through. But they don't need to be yanked around with dates. And so we don't like to put them out there for that reason. But there's always a date.

There's always a goal, and a deadline that we're going for. If anything, I want us to have more dates, and more deadlines. I think deadlines drive team efficiency and performance. I think there's always a dream of the endless timeline for creativity, but nobody actually wants that. Creative people think they want it, but when they get it, they don't know what to do with it, and the truth is they don't finish things. And nothing makes creative people happier than finishing things.

How did the idea for the auction house come about? That didn't come from the design department, did it?

JW: Yes, it did. It came from the design department. So here's one of the things that I will say -- that no one in forums will believe me -- but we never make business decisions outside of the game development team. We always make them based on what we think is right for the game.

We have a saying internally, which is we always want to be the guys in the white hats. Which means, we want to make money because making money means we get to make more games, and we get to make bigger games. And everybody wants to be successful. I don't think it's a bad thing to want to make money. I think it's a bad thing to want to make money off things that are not a good service or product for your customer, and that's our inherent belief, is that it's okay to make money on a service we provide for our customers that we think is a good service worth paying for.

And that is how we feel. We looked at the auction house and we said yeah, this is a good service worth paying for that we can provide to people. Do we want to make money off it? Of course we do, because we want to continue to make games, and we want to be successful. But we also think it's a good service. We think it's a thing players want, and want to do, and they want to be able to do it securely and easily, and they want to be able to make some cash off of it if they want. They want to be able to recycle that back into getting more items.

The whole trade economy of Diablo II was a really interesting element of the game, but the game didn't support it hardly at all. And so we looked at that and said that's a real failing, and something we need to fix.

Are you still experimenting and exploring the console version of Diablo III?

JW: Yeah. We haven't officially announced it, because we're not "experimenting." We tell people that basically we're experimenting, because it helps us hire people. The better people we hire, the better chance we have to actually make it. That's why we haven't kept it super secret, but we also haven't confirmed it, because we're not sure yet whether we think it will work, and whether we think we have the resources to do it.