11/1/2013 Episode 66: Development

All podcast content by Mark Rosewater

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

Okay. Today, I thought I would talk about an important part of R&D. So I’m the Head Designer, and so I talk about design all the time, because that’s what I do. But there’s another depart—there’s another section of R&D called Development. And from time to time I mention Development, but I figured, you know, they deserve an entire podcast where I talk about what—what does Development do? Because it’s a very important part of the process.

In fact, I believe that the design/development structure of Wizards of the Coast R&D is one of the most defining things about our company, in that I think it’s a very—it’s a very interesting way that we function, and I’m going to talk a little bit about what Development does. But I think that Development—in fact, the split between Design and Development is not well-understood. So today, I’m going to try to explain it.

Okay, so basically, there’s lots of metaphors that I can use. But my favorite metaphor is a Magic metaphor, which is talking about deckbuilding. That the designers are the deck creators, meaning they come up with the wacky ideas for what the deck’s going to do. I mean, not necessarily wacky, but, you know, “This deck is going to do this thing.” Or, “This deck is going to do that thing.” But they—they create a vision. That Design—the major role of Design is to come up with a vision, and then to try to execute on that vision.

So for example, I will use Theros, because Theros is a recent set, as my example. So for Theros, I, as the Head Designer, walked away saying “Okay, I want to make a Greek-mythological-inspired set.” And I wanted enchantments to be a component of it.

And so I figured out from that, you know, gods, heroes and monsters, and enchantments would be the feel of the gods on the world, and then I wanted mechanics for the heroes, I made heroic, and then a mechanic for the monsters, made monstrosity, and I wanted to, you know, have auras matter, but I needed it to work, so we put in bestow. And then devotion was there because we needed to represent the people’s (???) for the gods, and… so anyway, we created a vision for what we wanted.

And so in my mind, what happens is, at the end of design, design goes on for about a year, I make a document for Development. So I made like a ten-page document where I explained to Erik, Erik Lauer, who’s the—he was the lead developer of Theros. And I said to Erik, “Look. Here’s my vision. We are capturing Greek mythology, but more than just that, the feeling we’re going for is I’m trying to get a sense of accomplishment. I’m trying to—that I’m trying to follow the stories of Greek mythology in which, you know, you take the role of a hero and you watch him come from a young, you know, a young nothing up into a mighty and great hero.”

And that the myth of the epic hero, which is one of the great storytelling structures, comes from Greek mythology. And that I really wanted to create a set where it was about building and creating and that there was evolution to the game. To the gameplay.

And so I passed along this vision to Erik. Okay. Now, Erik’s job—so if I’m the deck creator, Erik is the deck tuner. Which means that I—I have this neat idea, but my first execution might not really be the optimal way to execute it. And that is what development’s job is, is they are the second set of eyes. They are the ones who say “Okay, we come in fresh, you know, we—we have not been there in design, so we are not attached to things. There’s not things that we’ve just grown fond of.”

That they come in with a fresh set of eyes, and they can say “Okay. Here’s what Mark says he wants to do. Is he doing that?” So for example, Erik’s the one who said, “Oh, well, this set—it’s missing something. You know, we want you to have all these combinations work. We want heroic to work and bestow to work, and—but in order to do that, there needs to be a little bit more card flow.” The card flow wasn’t quite as much.

And so Erik figured out that we needed a mechanic that helped just make cards go a little easier. That just more often made sure that you had the card you wanted when you wanted it. And so he came to me and said, could he add a mechanic? And I said, “Sure,” I said, “but it just needs to fit in the flavor of what’s going on.” And Erik wanted to use a returning mechanic, just because it would be something he already understood.

And he came up with the idea of scry. And I liked that because scry—Greek mythology is all about, you know, portents and omens and seeing the future. So Scry felt like a pretty nice fit for a Greek mythol—mythological world. And it did exactly what Erik wanted it to do. 

And then Erik took that ball and ran with it. And if you see the set, there’s a lot of scry in the set, because Erik knows in order to make the rest of the set that I wanted, that he needed to have that—the flux of the cards. You know, he needed the card flow.

Now, the other thing, for example, let’s talk about the ordeals. The ordeals—the flavor of the ordeals always had been—you know, the gods go down to the heroes, and they say “Hero! You must go on this quest!” And that through going on this quest, the heroes would build up and become more powerful, because they’re getting experience.

So the way we came up with was that you put this aura on them, and that every turn they attack they get bigger, they get a +1/+1 counter, but once they have three+1/+1 counters, they get an additional bonus. They’ve kind of accomplished the task.

What Erik found, though, was the fact that it kept on growing was problematic. It made—that one of the things that Development does all the time is they’ll come back to Design and say, “What do you care about? Oh, well you’ve done this extra thing that’s adding power that we have to cost for. If you don’t want that thing, you know, then we don’t have to—like, we want to cost the card so the thing you want is what people are paying for. And not that we have to pay extra because they’re getting this other thing.”

And the fact that it kept growing was really the most powerful thing about it. So Erik said, “Well what if it grows up to three, like you had planned, and then it gets sacrificed and an effect goes off? So you still get your reward, they still build up, but, you know, once they hit the quest, it stops building them up.”

And I said, “Oh, that sounds very good.” Because—so one of the relationships that Design and Development have, you know Erik—Erik being the guy who sort of runs the technical side of Development, and I’m the guy who runs the technical side of design. Each of us have our managers. So like Mark Gottlieb is the Design Manager, and Dave Humphries is the Development Manager. But what we’ve done is we’ve split the technical side of creating the set from the managerial side of managing the people.

We used to do both—or, I used to do both, but it was a lot of work, and I got a lot to do, and the reality is my strengths lie more in the technical side than the managerial side. That, you know, giving me—freeing up me more time to do technical meant, well, take some duties that somebody else could do. And so both Design and Development all have—and Creative all have managers. So that there’s somebody in charge of the team, but there’s somebody else—somebody in charge of the technical work, but somebody in charge of the team. The people.

And so the way that Erik and I interact, and the way that Design and Development interacts is, I set vision. My job is to say what—what’s important. But then Erik tries to make what is important actually work.

So here’s another good example. In Innistrad, which also is me handing off to Erik, I wanted to have vampires in red and black. And, based on how I wanted the other things to go, I needed the vampires to be the quicker tribe. The aggro tribe.

Now traditionally, red/black is not the aggro colors. Because they have so much control elements, that they’re the two colors best at destroying creatures, the way they play tends not to be a speed deck. Because they have the tools to sort of play a little slower because they have more control.

But I really needed—because in Innistrad, zombies needed to be slow and plodding. They were the slowly overrun you tribe but with time. And, you know, werewolves had this transform mechanic, so we didn’t want them too fast. We wanted there to be some suspense. And humans had a cooperation element, but, you know, they weren’t as—they weren’t necessarily going to be the fastest because we needed them to be defensive against the monsters. And the spirits had a strategy of—of evasion, through flying, and once again we didn’t want that to be the aggro deck.

So basically by process of elimination, I said “Okay, the vampires… we’ll make them—the reason we’re going to put them in red is they’re more bloodlusty than vampires normally are, and so we want them to be more aggressive.”

But what I had turned over—what Erik said is “Oh, you want an aggressive deck but you’ve not made cards—you know, the best way to play the cards you’ve made is not aggressively.” So Erik said, “Okay, well, let’s give the vampires some mechanical identity that’s flavorful for vampires, but says, “Hey, let’s be aggressive.” So Erik came up with using the slith ability, which is actually originally from Whirling Dervish.  .

But the ability of what R&D calls the slith ability, means every time I hit you with combat damage, I get a +1/+1 counter. And so the flavor of vampires sort of feeding on the opponent is pretty cool, and, you know, it makes a lot of sense, and it pushes you to have a more aggro red/black deck. You know, that’s what Erik came up with.

So the idea, essentially, if Development is doing their job, and like I said, Development is very good. I mean, Erik is excellent, and his team is excellent, and one of the reasons I think recent Magic has been so strong has been our development team is getting better and better at understanding how to make Limited work, how to make drafts work, how to make Constructed work. You know. I mean, I feel like Design is also getting technology and we’re improving too and we’re doing advanced design now, and we are making changes as well, so I mean I—I don’t think Design isn’t also upping its game.

But today’s about Development, and I feel that Development has been doing a lot of stuff recently to really rethink how things work. And Erik has been amazing—is amazing. And that—it’s funny, because—let me talk a little bit about Erik Lauer. So Erik Lauer is smart. And not just smart, like really, really, really, really, like genius-level smart.

And the funny thing of dealing with Erik is that he sees everything almost through like a math field. That he’s very logical, and that he—he likes to kind of process things as logically as he can. And the funny thing is, I come from a—from more of a psychological aspect, that I’m all about perception, and I’m all about psychology. And I’m about, like, you know, how do people perceive the things that they want? And so I’m very fuzzy. I’m not logical at all. And Erik is very logical. So it’s sort of like a little Odd Couple, if you will. It’s going to make my sitcom about R&D.

You know, that—it’s a nice dynamic, where I really have this sort of sense of I feel things, and I’m intuition, and I—I make gut calls on things, where everything Erik does is because he’s processed how it works and he understands the system. And Erik’s very good at looking at systems and breaking them down and going, “Okay, pull back, this is this, this is this,” and he can break almost anything down to math.

In fact, one of my favorite things—we have what we call a wiki, the Magic wiki, which is R&D has a place to put down ideas and things, and we just document a lot of stuff so people can read it, and there’s shared information.

So Erik once put together a document where he was talking about—what was it? Humor? How to use humor in Magic or something? It was something in which he took the most subjective possible topic, and then tried to explain it like through logic. And it was very, very funny, because it’s—it was—like, him trying to do an illogical subject matter through logic.

And the funny thing for me is, like my background is comedy, right? And my background—like, I understand comedy. And there is—there are rules to comedy, it’s not like comedy—every single art form has rules to it because there’s structure to it.

Now, one of the great things about art is figuring out when you need to break the structure. Right? Because—just because there’s rules doesn’t mean the rules don’t get broken, but it means the rules get broken on purpose. Anyway. I’m deviating. Probably a topic for another day.

So the big thing about design is trying to have a nice interplay, because here’s one of the things that—for design. If design is too attached to things, if every time something changes, design jumps in and says, “No no, don’t do that,” it causes a problem for development because development isn’t able to sort of do their job.

And in the past, I’m not going to name names, but there have definitely been designers that like try to protect every little thing they’ve done. And that’s a problem. It’s a problem when a designer is too protective, because then there’s just constant fighting, and you know, you—you’re getting in the way of development trying to do their job.

Now the flipside is a designer that has no opinion. “Whatever you want to do, Development,” you know, and doesn’t sort of say “No, no, this is important.” And the problem there is Development doesn’t have enough focus. That Development needs a push, and they need resistance. They need a little bit of pushback if they’re pushing areas that are a problem.

And in the past we’ve had some designers that, you know, handed something off and like “Whatever!” And the developers had a real hard time because they didn’t know what mattered. And so the correct balance for the designer/developer relationship is that the designer understands what I call the “bearing walls.” So if you want to use an architecture metaphor for a second.

The designer is the architect building the house. Or, you know, mapping out how the house will be built. But then the Development has to build the house. And so—and sometimes, in order to build the house, you’re like “Oh, well, this room’s in the wrong place. Let’s—let’s move the walls around or something.”

And what happens is, if the walls are decorative, it doesn’t matter. You can move the walls around. But if the walls are bearing, so in architecture, a bearing wall holds weight. Meaning the wall has a physical function. You know. Like, if you remove this wall, the house collapses because the weight of some portion of the house rests on this wall. Those are called bearing walls.

You can’t move a bearing wall—or, not easily. You know, you have to at least—it’s a lot more work. If a wall’s a bearing wall, you can’t just easily move it. Where if it’s a decorative wall, it can pretty easily be moved. I mean, there’s other reasons, but—for my metaphor here, bearing walls can’t really be moved, or not easily, where decorative walls can be.

So as the designer, you have to figure out if a particular card or mechanic or something is—is it a bearing wall? Does it bear weight of the set? Does the set collapse if you take it out? And so one of the things that I—I’ve got pretty good at, I’ve been doing this a long time. Is figuring out what matters.

And what I’ve learned is, I don’t fight the things that don’t matter. If Development wants to change something, even if—on an individual case, like “Well, I like the other thing better.” If what they’re doing makes sense and fills the vision of the larger set, I’m like “Okay,” you know, “Hey.” You know. “My job as a designer is to set that vision and that—I’m not making every call on every detail. You know. And that individual details, I’m like “Look. I’ve got to—I’ve got to stay hands-off if that detail isn’t important.”

But, if that detail is important, if that detail adds something—so for example, sometimes they’ll try to do something, like “No no no, here’s the point of what the set’s trying to do, this undercuts that.” Or like “Oh, I’m trying to set something up, and I need this to set it up, because later in the block we’re going to pay off on that so you can’t get rid of that.”

Or even sometimes where there’s a card that I think is a really good card but this is the only possible place to do it, where I kind of go to Development and say “Look, I think this is a really good card, and, you know, design resources, like…” Whenever I make something that’s awesome, but it can only go in one set, I fight a little bit harder to make sure we can.

I mean, if there’s developmental problems it goes, but if it was just a matter of opinion, it’s like, “Oh, well I can’t do this card anywhere else. And I would like to save resources.” You know. “If you—instead of doing that card, you do a card we can do somewhere else, now you’ve just—there’s one less thing I can do in the future.” And that I become more and more realizing that one of the things you have to fight for in design is things that are unique to what you’re doing that just have no practical use elsewhere.

Now, that said, I’ve talked a lot about in the creative process that sometimes you’ve got to kill your baby. That’s not the greatest metaphor. Sometimes you have to let your… darling… go? I don’t know how to use this metaphor correctly. But sometimes, that something you really love, but that isn’t advancing your art, needs to go to make the art better. Sometimes you—I mean, in solitary art form, where you are the artist and you’re the only one interacting, you kind of gotta, you know, get rid of your own darlings if you will.

But the thing about this is sometimes one of the nice things about art process is, if I’m kind of attached to something emotionally, I know Development’s going to give a pass on it. So I might leave a few things in that I’m like, “Well, if Development likes it, they’ll leave it, but if they think there’s something better, you know, they’ll approach it and they can remove it. And we do that sometimes.

Now the thing about Development—I think there’s some myths about Development that I’m going to—I’m going to bust right now. On Mythbusters: R&D Edition. So one of the ideas is that R&D is all about—it’s a quote I used to make long go. So it is a myth that’s my fault. I used to say that Design makes the set fun, and Development makes the set fair. And that’s a little inaccurate. It is Development’s job just as much as it’s Design’s job to make something fun. To make it enjoyable. In fact, a lot of what they do is make decisions pushing the gameplay in a certain direction.

For example, when Design designs some things, we design what we call “flat power level.” Which means everything’s roughly playable in Limited. And the reason we do that is, in playtesting, we need to play everything. We need to figure out what’s working and what’s not. And it doesn’t do a lot of value to have high and low power levels in design, because it just means we don’t experience things. Maybe there’s a really fun card priced really poorly, and then “Oh, well we never realized, oh, that’s an awesome card and we really should be more aggressive with this.”

So we have a flat power level. When it gets to Development, they have to skew it. They have to make cards better and worse and they have to sort of make an environment. And at that point, they’re deciding what to push. And the biggest factor of what to push is what is fun? What makes a fun environment? What is enjoyable?

Now some of it also is what is new, and they want to play up—you know, they want to make sure to push what the set has to offer that’s the new thing, because there’s a lot of focus on the new thing. But that’s the first myth.

The second myth is that the developers are solely—that, like, all the developers do is tweak numbers. That’s what development is. Development is about tweaking numbers. You know. That Design fits everything in, and Development just goes, “Oh, this should cost one more.” And the reality is, there’s a developer on every design team that’s doing rough costing and stuff so the designs aren’t out of bounds. The designs are in-bounds. You know. It’s flat, but it’s still all fair stuff that we can talk about and play with.

But Development has all sorts of things they’re trying to figure out. You know. A big thing is drafting is a huge part of Magic, and our goal is to make every set draftable not just three or four times, but forty times. Fifty times. Sixty times. You know. That we want—that draft is a way a lot of people play with Magic, and we want that to be enjoyable.

And usually if you make a good draft environment, it helps you make a good casual constructed environment. That’s something Design does a lot of. Design spends a lot more time on Limited and casual constructed, where Development spends a lot more time on Constructed. They spend a lot of time on Draft, and they spend a lot of time on Constructed.

And the reason they spend a lot of time on Constructed is A. they’re the experts in the metagame and knowing what’s going on, and B. so much of—of making Constructed work has to do with what’s good and what’s not, and that’s all about balancing. So until cards get balanced, you have no idea what’s going on. Until it’s played in the FFL, you don’t know. So Design doesn’t have the resources.

Now, we can pick areas to play around with, you know. One of the big things I tend to say is that Design tends to make big-picture decisions, and Development tends to make smaller-picture decisions. Now, Development is involved in “devign,” which is in between design and development. Design always comes to Development early on. So Development has a hand in during design, to make sure that we’re not doing something crazy that down the road Development can’t deal with.

And Design sticks around during development—like, I—I will peek my head in, or Erik will come talk to me, and say—like before he added scry in the set, he came to me and talked to me and said, “Is this okay?” You know, and I said, “Yeah, that makes sense, and scry makes sense in the world, and I get what you’re doing, and it’s not fighting other aspects.” You know.

And so there is a very important symbiotic relationship behind how Design and Development works, which is Design wants to make sure that they are setting things up correctly for Development, and Development wants to make sure they are following on the vision set by Design.

And that each—each part has their strengths. Design is—Design—Design’s job is taking a blank page and adding something to it. And then Development’s job is—is taking what Design has done, and then optimizing it such that it does what Design wants it to do.

And those are different skill sets. You know. That I think if you took Development and you—let’s put it this way. If you had a set with no design and just development, it would be very obvious. It would not have a lot of sort of—the feel wouldn’t be quite as strong, and it would—you know, it—it would be—cards that all make sense, and are playable, and you definitely could create an environment where, you know, it’s draftable, but it would be missing—it would be missing sort of the—you know, the “Aha, oh, this feels right” sort of quality to it.

Like, one of the things about Theros that’s so important is, that Theros, you know, I wanted a certain sense of feel. But if Design made a set and didn’t have any development, it would be broken. It wouldn’t work. You know. The focus would be off. You know. That we—we’d have—we’d have ideas that were cool, but maybe you’d never play them because the way it’s set up, it’s not the right thing to do. You know.

So the funny thing is, like, development without design, you’d have a set that plays but wouldn’t have any heart. And design without development, you’d have a set that was full of heart but wouldn’t play. You know, wouldn’t have cohesiveness to it. And that’s—like I said. That’s why I think the relationship is a very important one, where, you know, each side has its strengths and plays well.

And the fact that everything we do has two complete different owners, essentially, (???), the first half of the set, you know, let’s talk about Theros. I was the owner of Theros, I was in charge of Theros. In the second half of the set, Erik was in charge of Theros. That it wasn’t one person the whole time in charge of something. That is very unique. That’s not how most companies function. And that Magic is a very collaborative process. Very, very collaborative.

I mean, I haven’t worked at a lot of companies, I’ve mostly worked at Wizards, but the little that I’ve seen of other companies and such, that, you know, when I talk to other people about their companies, they’re always kind of shocked how we function. That what we do is kind of different.

Now, like I said, it requires a lot. You know. The fact that there’s no single owner throughout the process means that, you know, for example it’s on my shoulders to make sure that my—that my cares are—I have to watch to make sure that, you know, things I care about are not missed.

And usually not on purpose, and like I said. Erik will come talk to me about making changes, and—but sometimes—so here’s an example where—communication where I messed up. So one of the things that I had done in Innistrad was I was trying to create a bunch of cycles that were in every color but white. And the idea was that I was trying to show that the monsters had a certain flavor to them, and that white represented the humans, so I had—I had sort of monster cycles if you will. Things that represented the monsters’ side.

So one of those was the curses. I had curses in every color except white. And then in Dark Ascension, white finally got a curse.  Because I was trying to demonstrate that things had gotten so bad that even the white side, the humans themselves are starting to fall to the bad guys. And I was trying to set up this idea of “Things are at their absolute worst.” That the monsters have seeped into white.

The problem was, I didn’t explain this to Erik. I didn’t explain this whole—you know, I wrote a whole document, but I—I didn’t explain the idea of the monster cycles. And what happened was, Erik just changed some stuff around, and there was no green curse.

Now, if Erik had understood what I was doing, he would have made sure there was a green curse. But I didn’t explain it to him, and he didn’t see it. And so come Dark Ascension when I add a white curse, well, it was missing all the—like, what I was trying to do, the essence I was trying to get with that—you know, it was a little bit of the design. But it was lost. The second green doesn’t have a curse, you don’t see it as being a monster thing, and just—a lot of little subtle things, but it falls apart. You know.

And here’s something that I was trying—this little subtle thing I was trying to build in, and then just lack of communication, and once again this was on my shoulders, it’s not Erik’s shoulders. You know. I—because one of the things that’s also tricky is, when you’re doing design there’s a lot going on. There’s a lot of little subtle things going on. And for my job to make sure that when I pass it along, that every little thing I’m doing—that, you know, it can be seen.

Now the other thing we do is we always have a—there’s always a member of the design team that’s on the development team, so that there’s somebody who understands the vision from design. So Erik isn’t bothering me constantly, like there’s someone sitting in the room when they make decisions to go “Oh, yeah yeah, we did this for this reason.” And that that person is a bridge between the design and development teams.

And like I said. It’s also important, another sort of myth if you will, is Design is not always right. That Design might make a decision and do something, but when it gets to Development, Development goes “Yeah, I understand why you think—why you wanted this, but it’s having consequences that I don’t think you want.” And that they’ll come back and talk to us, and, you know—sometimes you do something, and like, “Oh, wow, that’s not—that’s not having the impact that I thought it would have.”

And one of the things that Development is very good at is, they have a really good understanding of if you make a card, the impact it has on an environment. You know. Where Design kind of shines in having the right feel, Development shines in just understanding functionality of—of just practically, what this card will do to the environment. You know. And that Design doesn’t mess with that a lot, because we’re not at a point where all that is happening.

But Development, that’s their bailiwick, that’s what they’re doing. And that that’s where they’re experts. You know. That they’ll say “Oh,” you know, “I see what you want, but what you’re doing isn’t doing what you think it will do.” And that’s a very common thing in Development. You know. Like for—another example is talking about the gods. In Theros.

Which was—we originally handed over something that—even Aaron has said “Eh, I love that there’s gods, these gods aren’t quite the right gods.” And I said, “You’re right, Aaron. The gods have to really be awesome. And these are not awesome enough.”

And so I said to Erik, “Okay Erik,” at the handoff I said, “Look, I know the gods aren’t right yet, I’m going to make a little team and I’m going to present you something—we’re going to fix the gods up.” You know. “I think Design’s a good place, but there’s—the cycle of gods isn’t quite there yet.”

So I took—in fact, the entire design team, and we designed—so the idea we had originally was, you cast the gods, and they went to their own special zone, which we called the Nyx zone. And the idea was, when you first summoned a god, it would just like go to Nyx.

You’re—you’re making the god aware of you. They’re—they’re still in Nyx. But they’re aware of you now. And because they’re aware of you, they would have an enchantment effect that would impact the—the game. But they’re sitting in Nyx. So your opponent can’t even deal with them because they’re in Nyx.

And then we had this idea of, with enough devotion, you actually get the god to come down from Nyx and take mortal form, and now he’s a creature on the battlefield. And what happened in our version was, if you ever—you know, killed the god, he just went back to Nyx.

So the idea was, the best that you could do as an opponent was you could get rid of the creature, but in the end, you know, if they got some more devotion they could bring them back. That was our original idea. And the flavor was pretty cool, this idea of the gods in Nyx and you could bring them and this and that.

But what Development said was “Oh, it’s confusing, you’re making a new zone, you know, it’s really hard to get rid of these creatures.” You know, that there’s a lot of sort of functionality. But what Erik said is “Okay, what’s the essence of what you were trying to go for?” And the essence was, when you summon a god you don’t even get the—the—the tangible god yet. You kind of just get the essence of the god. And that you have to kind of prove to the god that you’re worthy before they’ll come down and help you.

And Erik thought that—the core of what Design had come up with was a neat idea. But the execution was a little off. And in some levels, I think the gods is a perfect description of how Design and Development shine. Because I think the concept of what Design came up with was really, really cool. It was very neat. You know. That—that the idea of the gods having a form, but then they take mortal form if there’s enough devotion, that was a very cool concept.

But how we executed it—if that was how we executed it, it would have been very clunky. And what Development did is came in and said, “We’re going to save the essence of what you’re doing, but we’re going to fine-tune it a lot.” And they made a lot of changes.

The finished gods—now, also note that what effects the gods  had and what effects they got in development were very different. Because we had made—we had made the gods’ equipment—not equipment, the artifacts, you know, the enchantment artifacts. But Development was the one—in fact, we had a mini-team that I was on with Erik, where we like said “Okay. Now that we’ve made the gods and what do the gods do and what do the equipment do, and make sure that each god’s equipment synergizes with that god so if you play them together it’s kind of cool…”

And that’s another thing that Design—sorry, that Development does, is Design will turn in cards, but Development will then go back and tweak things  and say “I like this cycle.” Like for example with the Ordeal cycle. You know, they liked the idea of you set out on a mission, you grow up, but then they—they changed what the effects were at the end.

Because early on, we had effects that affected the creature, and then they turned into spell effects. Or sometimes even subtler than that, where we have something and they’re like “Oh, we generally like what you’re doing, but we’re going to tweak a little bit. We’re going to change this keyword or that keyword,” or, you know. And that a lot of Development’s job is to say “Oh, we like the idea, but yeah, it doesn’t—in the environment we’re building, this is the wrong effect.” You know.

And sometimes—it’s not like Design just picked a bad effect, it’s “Oh, we’ve—we’ve learned this about the environment, and we need this quality, or this thing does something different now that we understand the environment.”

And that the thing that’s funny is, that I feel like Design does a lot of the splashy work, and Development does a lot of the, you know—more unseen work. And so I feel like Design gets a lot of credit where Development does not get enough. And part of my role of doing this podcast today is trying to explain that if you love a Magic set, you know, if you love Theros, that yes, Design had a lot to do with it. But Development also had a lot to do with it. As did the creative team, which—whole different podcast. But—I mean the—the—like, a well-designed set that is poorly developed will be perceived as a very, very bad set.

And, you know, I—one of the things that’s very important is—that I know as a designer is I want Development to do the best work possible. The reason that I want to figure out the bearing walls and get out of the way is they are going to make my set better. You know. When I turn over my design to a development team, I know that—that I am going to be happier when the day is done. That they are going to make the set a better set when all is said and done.

And—I mean, and that—that is the true part of a collaborative process is, having faith that the—your collaborators are making what you do even better. And I believe Development does that, I believe Creative does that. Because Design is the early man.

Like, we’re—we’re the ones that—you know, put the stake in the ground, and then everyone follows what we do. And so I really have a nice vantage point of I do my work, I sit back, and then I watch all the other teams work on it. And they’re all interconnected when they’re working. We’re a little more separate. I mean, Development gives us input and Creative gives us input, but, you know, the vast majority of both of their work happens when we’re done.

Anyway, I—hopefully today, my goal of today is to make you have a little more appreciation for Development, because they are an awesome, awesome part of the process. And if you love a Magic set, you know, it’s because Development did amazing work. So, thank a developer.

Anyway, I am now at work, and I need to go make some more work for developers to do. So it’s time for me to go make some Magic. Talk to you guys next week, guys.