Magic: The Gathering Drive to Work Podcast - Drive to Work #166 - Design and Development

Episode Date: October 17, 2014

Mark talks about the difference between design and development.

I'm pulling on 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, it's a little breather, a little, little, something a little different to break up the Onslaught posts or 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 to 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 I need, well, here's what I want to do.

First, I want to explain kind of the things I need, well, here's what I want to do. First, I want to explain kind of what design development does, and then I can talk about sort of 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.

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 a, 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, you know, we talk about Legends or Ice Age or Mirage or Homelands or, uh, even Antiquities. You know, 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. Um, and in a few cases, like Homelands, they weren't 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, okay, 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'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 to keep an eye on sort of how the cards fit into the bigger picture. So anyway, we flash forward to Tempest. And 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 that everything worked all right. And so we decided with Tempest, let's just keep this.

It's working well for us. The reason design development kind of started originally was one of it was the team outside the building, one was the team inside the building. But even when the design went inside the building, we decided to 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 set of eyes, right?

If you want to think of this way, you could think of design, development, or just design is kind of the early aspect of design and development's the late aspect of design. is kind 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 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 copy editing type mistakes. Oh, you misspelled a word. simple copy editing 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 and 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 writer to editor,

but a good editor is somebody who is being the second set of eyes, not just for copy editing, but also to sort of make the author understand things that sometimes when they get real close, they won't see. So in this parallel, I believe that design development, a decent metaphor is a writer-author relationship in which the author is very aggressive in what they're willing to do.

I don't mean in the sense of they just copy it. I mean they're willing to move chapters around or willing to do major stuff to improve the book in a way that's pretty substantial. Okay, so here is what design does. Design'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? You know, now normally there's a jumping

off point that people agree with. The way we work in the seven-year plan now is that a bunch of people all sign off on the general area for the design. So, for example, Constance Arquire came out not too long ago. And that started because we had signed off on an interesting draft block strategy. A block, uh, a block, um, structure that we liked and then said, you know, we're going to build off of that.

That's where we started. Um, and so what happened was design just figures out where they want to start and then have to make something. So I'm going to use concept art here 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 pick this interesting block structure, this block, this drafting structure that we've never done before. And so we had a look at it and said, okay, well, assuming this is our jumping off point, this is what we're doing, what does that mean? And the 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 the concept here, 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 things, 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 Concert Dark here. So then, once I understood what the block was doing, I had to understand what the set was doing. And then once I knew 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 world, 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 the 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 just inertia. And from there, that led us to the idea of, you know, people have been wanting us to do wedge. Oh, maybe this would make sense as a wedge set that some of the people have 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 a look at the first stab at what the mechanics are.

What's the structure? How are things put together? So Constantine Sarkeri 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. The block isn't all out yet as a hearing of this, so I can't quite explain everything yet. But there are 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 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, kind of start here to Eric Lauer, who was the lead developer, I'm explaining what I'm doing, what we're up to. So when I hand off the file and I kind of start here to Eric Lauer who was 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 the idea that the clans represented draconic aspects of the clans.

And then we work 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 content 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 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 to them and make sure that the colors would match. And one of the things we did is, oh, well, this is these colors, and it maybe skews the clan a little bit. And so, each of the clans adjusted to make sure they made sense of 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 now.

But morph was playing a role. It's something bigger than the clans. And then the clans each had to have their own mechanic. And so 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 is 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 that design are deck builders and development are deck fine tuners. You know, 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 Kha'Zix Ar'Kir, we had five clans that were wedged 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 development, it's like, design development didn't talk until the handoff happened. Then we created this process we called Divine. D-E-V-I-G-N for those that care, because it's half development, half design.

Which was better than development. Or development, I guess. So what happened was we created Devine. What Devine was is development started a month or two months for a large set before 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, 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 is going to start playing around with, just to see if there's any areas that development has concern with.

Then, design is chopped into three sections. And at the end of each section, there's kind of a check-in with development to make sure to see how they're feeling. And so 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 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 the two vision holders are sort of sharing information. Okay.

So design set things up. Design says, here's the structure. Here's a good check of 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 explain that to development. Here's what I'm going for, here's what I'm trying to get the audience to feel when they 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 costing such that 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've not played before. So let's say the last playtest you played black-blue. Maybe the 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 and 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, 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 the sense 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 is working or not working. To go back to my editor metaphor, if there's a chapter that's not holding its own weight, the editor can take the chapter out. Or make the author rewrite the chapter. That's kind of what divine would be. So, a good

example I use, and I've talked about this before, in Innistrad, we wanted to have the vampires, they were red and black, so the vampires are normally black, we blood them into red as well. We wanted that tribe to be the aggressive tribe. The problem is, red-black left to its own devices We wanted that tribe to be the aggressive tribe. The problem is red-black left 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 remove threats and then attack as you can. It's not necessarily trying to be fast, it's trying to be efficient. So when we said to the development team, this is

our aggressive deck, they're like, oh, 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. For example, they added the slith mechanic,

with a mechanic that said, you know, vampires feed on the opponent. So every time they do damage, they get a plus one, plus one 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 the 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, because that requires, 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, the development's going to do it, what 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. 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. You know, they can extrapolate. You know, I sometimes call it development design. Which means, development is very, very good of taking a known thing and extrapolating within known areas. That is 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 that. That'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 the, you know, 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 constructor 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 and introduce 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 a huge constructive 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 is 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 the spell at a different, you know, I essentially have two different versions of the card.

Well, there's a lot of knobs there, you know, 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 in the complexity, there's only so much development can do to rein it in.

And so a lot of what 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 is dependent on design to craft the initial things to work with. So, for example, I'm head designer, Eric Lauer is head developer. We both happen to be the lead designer and developer

on Conceptor here. 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, emotional beats. I'm trying to craft what's this world, how will it resonate, how will this feel fun and different. And that Eric'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 ones. Number one, fun. 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 Kanzi 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's 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. Eric is trying to make it fun to make sure that you have the tools you need to do what you want to do. You know, a lot of Eric's job is to make sure that, oh, this, you know, here's the balance to 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 add 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,

you know, and that, um, both of us are very much trying to make a fun game, but the aspects we're looking at are a bit different. Um, the other thing that we're both 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 bullseye, if you will, but it's development's job sometimes to move the bullseye, to shift the bullseye. Usually design figures out what we want to do, and the development says, okay, you know, sometimes design has some lofty goals, and as development gets their hands on, like, oh, well, some of the stuff you want,

I don't know we can deliver, but we can deliver something similar to what you wanted. And that's a very common discussion I'll have, where Eric will come over and talk to me, usually when he's the lead developer on something, I'm the lead designer, where he's like, okay, 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 a flat power level, we're 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, like, oh, now that players can do whatever they want, now that they're led by winning, and now they're like, what's the best thing I can do here? Sometimes it drifts 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 a neat thing. And when we're playing with it, we're just going where the fun is because we have nothing to tell us otherwise. Where development, once they start costing things, and 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 Eric's team has to do is try to figure out how to get it back to the actual correct strategy to win is this. That's not the fun strategy. And what Eric's team has to do is try to figure out how to get it back to the fun. How to de-emphasize things that 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 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're 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 were like, oh, wait a minute, the backside of werewolves don't have a mana cost, which means they die to Ratchet Bomb.

Ah! We would not have done it that way if we had thought of 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, at some level, 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 the development can take the clay and mold it into the final product. 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 I think is special about our 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 specialists, meaning my designers really design, the developers really develop.

There clearly are some overlapping skills that go on. There's a reason that designers serve on development teams and developers serve on design teams, but that it's more about that we really are able to fine-tune how to make that work. Anyway, hopefully, I hope this was illuminating, and this

really taught you guys kind of what we're up to. And that, my friends, is the difference between design and development. But, I've 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.