10/17/14 Episode 166: Design and Development

All podcast content by Mark Rosewater

I’m pulling out of my driveway! We all know what that means! It’s time for another Drive to Work.

Okay. So, I decided to do a bunch of podcasts about Onslaught, and that went for a long time. So I wanted to definitely break it up. And so today, a little breather, something a little different. To break up the Onslaught podcasts. So today, I’m going to answer a question I get asked all the time. Which I’ve answered numerous different places, but never in a 30-minute increment. So we’re going to try it today and see if I can maybe talk about some stuff that I haven’t before.

So the question is, what is the difference between design and development? So one of the things—well, here’s what I want to do. First off, I want to explain kind of what design and development does, and then I could talk about the differences between them. And then talk about how we work together, and how what design does is fundamentally different than what development does. But on some level, that we’re doing a lot of the same job.

Okay. So one of the things is, the whole concept of design and development is something that Wizards, to the best of my knowledge, we sort of created. It’s possible that other people do this and I was unaware. But when I talk to people in the game industry, the way we structure things is a little differently than most. And so today I’m going to walk through that and sort of explain what’s going on.

So the idea was, when Magic first started, that there was—that Magic was all done out-of-house. And what I mean by that is, the early days of Magic, the people making the sets didn’t work at Wizards.

So for example, we talk about Legends, or Ice Age, or Mirage, or Homelands, or even Antiquities, a lot of those early sets were made by people external to the building. Now, some of those people external to the building would later not be external to the building, and work at the building. And in a few cases, like Homelands, they were people that worked at Wizards, they just weren’t R&D people. They were from other sections of the company.

And so what happened early on was, somebody would make the set. Would design it. And then, R&D would do a pass on it. Because like someone made it, now we’re going to do a pass on it. And the reason that R&D had to do a pass on it is, there’s a bunch of factors that it’s very, very hard for the outsiders to know.

Outsiders can come up with cool neat things, but they might not understand the metagame, or what’s powerful right now that you have to watch out for. Internal R&D very much sort of had a, keep an eye on sort of how the cards fit into the bigger picture.

So anyway, we flash forward to Tempest. So, Tempest was the first set in which we designed it in-house. In fact, this is my set. I was the one who led this. But we had kind of had this process where the designers, people who first sort of created the set, were separate from the R&D pass that we’d done to make sure everything worked all right.

And so we decided, with Tempest, let’s just keep this. It’s working well for us. That the reason design and development kind of started originally was, one of it was the team outside the building, one of it was the team inside the building. But even when the design went inside the building, we decided we’d keep the process separate.

So let me talk a little bit about what design does and what development does, and—I mean on some level, really what’s going on is it’s two sets of eyes. Right? If you want to think of it this way, you could think of design and development are just, design is sort of the early aspect of design, and development’s the late aspect of design.

That what is going on is, one of the problems is, when you make something, when you creatively make something, you invest yourself in it. You get very emotionally invested. And so at some level you lose some objectivity. Just because as you get very close to your creative work, it’s tough to sort of sometimes see things. Because you’re too close to it.

In fact, in the writing world, in the publishing world, you have an author, and the author has an editor. Well, why does the author have an editor? Well, one is the editor is there to catch simple copyediting-type mistakes. “Oh, you misspelled a word.” But bigger than that, the editor is there to be a second opinion on what’s being written.

And that a good editor will comment to the writer, say, “You know what? I think this chapter, I’m confused.” Or “I’m not sure whether this subplot is really pulling its weight.” The editor gives actual critical information to the writer to help the writer.

And—I mean, it varies from [editor] to editor. But a good editor is somebody who is being the second set of eyes. Not just for copyediting, but also to sort of make the author understand things. Sometimes when they get real close they won’t see.

So in this parallel, I believe that design and development—a decent metaphor is a writer/[editor] relationship, in which the [editor] is very aggressive in which they’re willing to do. I don’t mean in the sense of they just copyedit, I mean they’re willing to move chapters around, they’re willing to do major stuff to improve the book in a way that’s pretty substantial.

Okay. So here is what design doesDesign’s job is to figure out—design starts with a blank piece of paper. And they have to take a blank piece of paper, and turn it into something. So design’s job is to sort of figure out, “What are we doing? What is this set about?”

Now,  normally there’s a jumping-off point that people agree with. The way we work on the 7-year plan now is that a bunch of people all sign off on the general area for the design. So for example, Khans of Tarkir came out not too long ago. And that started because we had signed off on an interesting block strategy. A block structure that we liked. And then said, “We’re going to build off that.” That’s where we started.

And so what happened was, design just figures out where they want to start, and then has to make something. So I’m going to use Khans of Tarkir just because it’s the most recent, to sort of talk about how design functions.

So design said, “Okay. We need a jumping-off point. We’re going to take this interesting block structure. This drafting structure that we’ve never done before.” And so, we had to look at—we said, “Okay, assuming this is our jumping-off point, this is what we’re doing, what does that mean?” And then design has to sort of flesh out stuff.

And so a lot of what design is doing is figuring out the structure of the set. What is the foundation? What are we building off of? So for Khans of Tarkir, as an example, we said, okay. We started with the idea that we wanted a certain draft structure. And so the next step was, how could we justify that draft structure? And after looking at a whole bunch of different thing, we came up with the idea of doing a time-travel story.

That became the germ of what we built around. Like sort of—the draft structure was the initial idea, and then we came up with an idea that followed that. And then that started giving us some definition. Then design, understanding that was the block structure, then started building the block to match that.

Eventually, I was the lead designer for Khans of Tarkir. So then, once I understood what the block was doing, I had to understand what the set was doing. And then once I understood what the set was doing, I had to start creating structure for it.

So we knew for example that it was going to be—we had gone to the creative team, told them we needed a flawed world. They came back with Tarkir, which was Sarkhan’s home world. Filled with warring clans run by these warlords known as “khans.”

And so from there, we said, “Okay, well if we want to show warring clans, well that leads to factioning. We want to have a bunch of different groups.” We went to the creative team, we said, “How many groups are there going to be?” They originally came back with four. We built a thing around four. Then they said, “Wait, we think there’s a fifth one.” So we ended up building around five.

Once we were at five, because Magic is divided into color, five is a very important number in Magic. So once we got to five, I knew that we had to involve the color wheel. That it would be too hard to do five and not involve the color wheel. You’d be fighting inertia.

And from there, that led us to the idea of people had been wanting us to do wedge, oh, maybe this would make sense as a wedge set. That this is something that people had really been wanting. And from there, we took all the different components and design put them together.

So what design was responsible for is saying, okay. Take the first stab at what the mechanics are. What’s the structure? How are things put together? So Khans of Tarkir said, okay. It’s a faction structure. There are five factions. They are wedge-aligned. We’re the ones that figured out where to center the color.

And like I said, there’s a lot of choices. But the block isn’t all out yet, as the hearing of this, so I can’t quite explain everything yet. But there were a lot of choices made to match what we were doing with the block structure.

But design’s responsibility is to figure out what the structure is, what the elements are, how it’s put together, what mechanics we think will make it work, so what design is doing is design is building all of the understructuring of it. And then taking a first stab at what we think will answer things.

And an important thing is, when design hands off the document to development, what we do is we explain our processes. We explain our thought process. We explain what we’re up to.

So when I hand off the file, you know, Khans of Tarkir to Erik Lauer, who is the lead developer, I’m explaining what I’m doing. What I’m up to. Here are the clans. Here’s what the clans represent. It was design that came up with the idea that the clans represent draconic aspects of the clans. And then we worked with the creative team.

So design works very closely with the creative team to make sure that we are creating something that can be supported by what the creative team does. So for example, using Khans as an example, is we knew we needed a world. We went to the creative team and said, “Here’s our parameters for the world. We need a flawed world. A world in trouble.” And then they came back.

Then, we said, “Okay. We need factions.” And they said, “Well, in the world we want to do, here’s where we want to go for the factions.” Okay, we compromised on how many factions there were. And then we built each one. And we had to go back and make sure that the colors will match.

And one of the things we did is we said, oh, well, this is these colors, and maybe it skews the clan a little bit. And so each of the clans adjusted to make sure they made sense with the colors they were in.

Then, design—so morph has to do with the larger block structure. It’s hard for me to talk about it now. But morph was playing a role in something bigger than the clans. And then the clans each had to have their own mechanic. And so it’s design’s job to find a mechanic for each of the clans.

Now, be aware that design is the first half of this process. What design is doing was doing the initial work. It’s saying, “What do we think are the cool ideas?” The other metaphor I’ll use between design and development is design are deck-builders, and development are deck-fine-tuners. That design says, “Here’s a wacky idea for a deck. Let’s do this.” And development says, “Okay. If you want to accomplish that, here’s what we need to do with the deck to make it happen.”

Okay. So now we’re shifting from design to development. So design comes up with a bunch of ideas. When we handed over the file of Khans of Tarkir, we had five clans that were wedge, that had particular mechanics. That had morph and morph was used in a certain way. Now, all along the way we have check-ins with development. To make sure that development is happy with where we’re going.

It used to be that when design handed off to development it’s like, design and development didn’t talk until the hand-off happened. Then, we created this process we called “devign.” D-E-V-I-G-N, for those that care, because it’s half-development and half design. Which was better than “development.” Or “deselopment,” I guess.

So what happened was, we created devign. What devign was is development started a month or two months before a large set, where design ended. So that development could start looking analytically at the set being designed, give notes in time for design to adapt to those notes.

So what happens—so that’s how we started. Now we do check-ins even earlier. We now do exploratory design, which means that we’re looking at ideas even before we get to the design. At the end of exploratory design, we talk to development and we say, “Here’s ideas that are going in—here’s ideas that design’s going to just start playing around with, just to see if there’s any areas that development has concerns with.”

Then, design is chopped into three sections. At the end of each section, there’s kind of a check-in with development to see how they’re feeling. And so that the important part is, we want to make sure that development is happy with where design is going.

Then, once the set is handed over to development, design, the lead designer at least, keeps their head poked in, and just keeps watching what’s going on. Often the lead developer will come back to the lead designer saying, “Here are some changes I want to make. Do you have any issues with these changes?” So that there’s a—the two vision-holders are sort of sharing information.

Okay. So design sets things up. Design says, “Here’s the structure, here’s a good (???) mechanics, here’s the vision, here’s what we’re aiming at to do.” A big part of what I do in design is making sure there’s an emotional—some emotional response you’re trying to get out of the audience. I always try to explain that to development. Here’s what I’m going for, here’s what I’m trying to get the audience to feel when we play.

Okay. So that all gets taken and given to development. So development’s job is to be that second set of eyes. So the first thing they do—design does not really worry about costing. We have a development member on the team, what we call the development representative, or the dev-rep, and their job is to make sure that the costing of the cards is playable.

Because in design, our goal is, we want everything to be playable so we can test it. So we can see where the fun is. A lot of what design is trying to do is explore possibilities. So in order to do that, we just want to play a lot of the different cards.

So we do what we call costing flat, which means that every card is costed such that eh, probably if you wanted to you could play it in Limited. And the idea is, when you playtest in design, you’re not trying to make the best deck. You’re trying to play things you have not played before.

So let’s say the last playtest you played black/blue, maybe next playtest you play red/green. Your black/blue might be better than your red/green. You might make a better deck with black/blue. But the goal of design is not to test—you’re not stress-testing yet. Because you’re not doing environmental stuff. That will come during development.

So what happens is, when it first gets in development, the first thing they do is they start to sort of get a sense of where they want to push power. Meaning what do they want to be aggressive on costing, what do they want to be less aggressive? So they start doing a little more fine-tuning of the costs. And as development moves along, and as they get a better and better understanding of what they want, the costs get more and more fine-tuned to the point where they’re crafting an environment.

Development, remember. The early part of design is all about sort of figuring out possibilities. We want to give a whole bunch of tools and options to the development team, who then slowly narrow down what they’re doing.

So in some ways, design is very open, and development is very closed, in that design is looking to find what can get added, and development is looking at sort of what’s carrying its weight. Now, the role of development is to figure out if something’s working or not working. To go back to my editor metaphor, if there is a chapter that’s not holding its own weight, the editor could take the chapter out. Or make the author rewrite the chapter. That’s kind of what devign would be.

So a good example I use, and I’ve talked about this before, is like in Innistrad, we wanted to have the vampires—they were red and black, so we bled them into red as well. We wanted that tribe to be the aggressive tribe.

The problem is, red/black, left to its own devices, tends to be a little more controlling than aggressive. Because black and red have the best creature removal, usually the best strategy in a red/black deck is kind of removes threats and then attack as you can. It’s not necessarily trying to be fast, as it’s trying to be efficient.

So when we said to the development team, “This is our aggressive deck,” they’re like, “Oh. Well, we need to change some things.” And what we had done really wasn’t making them as aggressive as they needed to be. So they changed it around.

So for example, they added the slith mechanic. It’s a mechanic that said, vampires feed on the opponent. So every time they do damage, they get a +1/+1 counter. They get stronger.” And that was a mechanic that said, “Hey, attack.” You want to attack and attack quickly. You want to play this cheaply and you want to attack right away.

So they put into it some stuff that made the players play the way that design envisioned it. But that’s an important distinction here, is that design’s job was to sort of figure out the feel they wanted, and we took a first stab at it, we tried to sort of get where we wanted, but development makes sure that the set is doing what needs to get done.

And once again, because design isn’t adjusting costing, isn’t really adjusting the environment as a whole, (???) require—like, once you start choosing what to cost and what to push, you very much control how people play the environment. And because we know that it’s not what we do in design, that development’s going to do it, we do—the role of design is to set development up for success. The role of design is to make all the tools necessary that development is able to do their job.

And the trick is, development is very good at using tools to fine-tune. What they are not good at is making the tools. And that a lot of what happens is—development is very, very good at, if you have a mechanic of saying, “Oh, we need another card with this mechanic, we understand the mechanic. oh, well let’s make a new effect that’s in the mechanic.” They can do that very easily. They can extrapolate.

I sometimes call it development design, which means—development is very, very good at taking a known thing, and extrapolating within known areas. That’s something they excel at. “Oh, well there’s a new mechanic, and we need a direct damage spell.” They can make that. They can figure out numbers. They can adjust it. It’s not a problem.

Where development has problems is, “Oh. This isn’t working at all, we need something new.” That’s a lot harder. That’s not playing to their strengths. Design strengths is sort of coming up with—from blank piece of page to something. Where development is taking the something and fine-tuning it and making it worthwhile.

Now. Development has an entire other thing going on, by the way, which is that Magic has a constructed component where people play decks. Standard being the most popular format. Well, development is in charge of making sure that that system doesn’t break. And part of that is figuring out what to push. What’s being played. What are the decks that prior to this coming out are good decks?

And what they’re trying to do is make sure that they are mixing up the metagame, getting new things, not adding too much strength to the deck that’s already the best deck, and making sure that there’s new things to do.

Another thing design does is design introduces new fun toys, development’s job is to make sure those fun toys can be played. Especially in Constructed. Now, not every mechanic is necessarily about Constructed. There’s mechanics that are fun for Limited that really don’t have huge Constructed play. And development has to figure out what to push where.

And one of the big things between design and development is, design has to make sure that we make enough mechanics that development can push. And a lot of times, a lot of our notes from development is, “This mechanic we can’t push.” Or, “This mechanic is going to be really hard to get into Constructed. Or into Standard.” Or, “This mechanic’s perfect, do more of this.”

Or sometimes it’s like, “We need more knobs.” So what knobs are is, when you do a card, there’s things that you can adjust. So a mana cost is a knob. An activation cost is a knob. Power/toughness is a knob.

So every card has some knobs. Some mechanics have more knobs. So for example, if you have a mechanic like kicker, where not only do I have a spell, but I can pay a different cost to have a different—I essentially have two different versions of the card. Well, there’s a lot of knobs there. And that at some level, the knobbier we make our cards, the more we allow development to have some tools to adjust them.

But anyway, there’s a lot of balance going on. The other big thing that design spends a lot of time thinking about is overall complexity. Because development has the ability to ratchet things in some, but if we’re too far off on the complexity, there’s only so much development can do to rein it in. And so a lot of design is also doing is matching that complexity to set up development to put it to the right amount.

In a lot of ways, design and development work very closely together, because our jobs are each dependent on the other one. It’s a very symbiotic relationship. Design is dependent upon development to fine-tune, but development’s dependent on design to craft the initial things to work with.

So for example, I’m Head Designer, Erik Lauer’s Head Developer. We both happen to be the lead designer and lead developer on Khans of Tarkir. But our jobs, for example, are a bit different. My job as Head Designer is, I’m in charge of each year figuring out where we’re going, what the general feel is, the emotional beats. I’m trying to craft, what’s this world? How will it resonate? How will this feel fun and different?

And that Erik’s job as Head Developer is to make sure that each set is fun, it’s playing well, it’s balanced, that it is making exciting and cool Magic, and that it’s doing it in a way that his team can support.

So, where are the overlaps? Well, here are the big overlaps. It is design’s job and it is development’s job to make the game enjoyable. Now, the areas we look at are a little bit different. For example, I spend a lot more time and energy on the feel. That when I’m making Innistrad, or Theros, or even Ravnica or Khans of Tarkir, I’m very conscious on what am I trying to do? What is the feel I’m going for? What is the general gist? What is the emotional beats I’m trying to get? How do I want the audience—I’m trying to make it fun because I want it to resonate with the player.

Erik’s trying to make it fun to make sure that you have the tools you need to do what you want to do. A lot of Erik’s job is to make sure that oh, this—here’s the balance of that. This deck is becoming unfun without a counterbalance. Let’s make sure to have the counterbalance. Or oh, the card flow isn’t working well enough, we need to a little bit of card flow, or this is dangerous so let’s make sure we cost it so that it doesn’t show up quite at the level where it would become annoying to people. And that both of us are very much trying to make a fun game, but the aspects we’re looking at are a bit different.

The other thing that we’re very much looking into is, there is a theme we are trying to hit. There’s a goal we’re trying to hit. Now, it’s design’s job to sort of set up the bulls-eye if you will, but it’s development’s job sometimes to move the bulls-eye. To shift the bulls-eye. Usually design figures out what we want to do, and then development says, “Okay…” Design sometimes has some lofty goals, and as development gets their hands on it, they’re like, “Oh, well some of the stuff you want, I don't know that we can deliver, but we can deliver something similar to what you wanted.”

And that’s a very common discussion I’ll have where Erik will come over and talk to me. Usually when he’s lead developer on something I’m lead designer, where he’s like, “Okay, I see what you were going for, but as we’re playing, this is happening.”

Like, one of the things that doesn’t really happen in development is, in design, we have flat power level, we are just trying to figure out where the fun lies. In a raw sense. Once development gets their hands on it, they cost things correctly. Now, all of a sudden they are stress-testing the environment.

And what we find sometimes is, when they stress-test, they’re like, oh. Now that players can do whatever they want, now that they’re led by winning, now they’re like, oh, what’s the best thing I can do here? Sometimes it drafts away from the fun.

Now, I’ve talked about this a lot, and this is really, really important. And this is something design and development have to work together to do. Which is, the thing that your game makes your players do, the players will try to win most of the time, and that the game will encourage them to do certain things, because those certain things is what will lead to them winning.

If those things aren’t fun, they will do them and then blame you the designer for it not being fun. So the job of designer and development is to make sure that what your set encourages you to do is where the fun is. And so one of the things that development does a lot is, sometimes design comes up with a masterful fun plan. Here’s the neat thing. And when we’re playing with it, we’re going where the fun is because we have nothing to tell us otherwise.

Where development, once they start costing things, once it’s like, “Okay. Now I’m trying to win. Now I’m going to do whatever it takes.” You’ll find that, oh, well the actual correct strategy to win is this. That’s not the fun strategy.

And what Erik’s team has to do is try to figure out how to get it back to the fun. How to de-emphasize things that, like, work but aren’t fun, and emphasize things that are fun, and make those things work. And so a lot of development is understanding the vision of design, but then aligning it with the realities of what you need to do.

Now remember, they’re also dealing with Constructed, where a lot of it’s already locked down. In design, a lot of what design is working, is we’re doing Limited, we’re doing a lot of sort of casual Constructed. We’re looking at a world where people are looking at this pool of stuff.

Mostly because at the time we’re working, we don’t know exactly what the things are going to go on in the outside world. Development’s the ones that spend a lot more time and energy on that. And we are so much more far ahead it’s hard to gauge. They’re a lot closer to it. We’re a year to two years ahead of where development’s at. And so it’s not worth us to try to figure that out. We don’t know. It’s too early.

And so, a lot of what development is doing is looking at what is locked and saying, “This can’t change. How does this new stuff affect that?” And sometimes the new stuff has to change to adapt to what is already out there.

And one of the most frustrating things is, sometimes you’ll do something that seems innocent. Like, I remember we made Ratchet Bomb. And it wasn’t until—I mean, Ratchet Bomb was in the environment when we were doing Innistrad, and we’re like, “Oh, wait a minute, the backside of werewolves don’t have mana costs, which mean they die to Ratchet Bomb. Aagh!” We would not have done it that way if we had thought if it ahead of time. But you don’t always realize things.

And development has to work on the fly and adapt with things. Development very much has to adapt with what is going on. But the key here is that design and development are two symbiotic groups working together with the same outcome, which is we want to make an awesome set.

And that, like I said, on some levels, design’s job is to do everything possible to enable development to make an awesome set. And that is create vision, create structure, create mechanics, create cool cards. And then, hand that all off to development, working with them along the way, so that development can take the clay and mold it into the final product.

And be aware that one of the things that I really think makes Magic excel, and one of the things that I really think is special about R&D department is, the fact that we’ve really taken the design process and broken it into two very distinct parts allows us to A. get more specialist, meaning my designers really design, the developers really develop. That there clearly are some overlapping skills that go on, there’s a reason that designers serve on development teams and development serves on design teams, but that it’s more about that we really are able to fine-tune what—how to make that work.

Anyway, I hope this was illuminating, and has really taught you guys what we are up to. And that, my friends, is the difference between design and development. But I have just parked my car. Which means, guys, that this is the end of my Drive to Work. Hope today was informative. I’ll talk to you soon.