Magic: The Gathering Drive to Work Podcast - Drive to Work #66 - Development

Episode Date: November 1, 2013

Mark spotlights the development side of Magic.

Okay, I'm pulling on 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 section in 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 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 interesting way that we function. And I want to talk a little bit about what development does. 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 could use. But my favorite metaphor is a magic metaphor,

which is talking about deck building. That the designers are the deck creators, meaning they come up with the wacky ideas for what the deck's going to do. And I don't mean to say wacky, but this deck is going to do this thing, and this deck is going to do that thing. They create a vision. 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. Enchantments would be the feel of the gods on the world. And then I wanted mechanics for the heroes. I made heroic and 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 it in bestow. And then devotion was there, because we needed to represent the people's feel for the gods.

So anyway, we created a vision for what we wanted. And so, in my mind, what happens is, at the end of the design, design goes on for about a year, I make a document for development. So I made, like, a 10- a year, I make a document for development. So I made like a 10-page document where I explained to Eric, Eric Lauer, who was the lead developer of Theros. And I said to Eric, look, here's my vision. We're 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 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 Eric.

Okay? Now, Eric's job, so if I'm the deck creator, Eric is the deck tuner, which means that 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're the second set of eyes. They're the ones who say, okay, we come in fresh.

We have not been there in design, so we're not attached to things. There's not things that we've just grown fond of. 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, Eric's the one who said, oh, well, this set, it's missing something. We want you to have all these combinations work.

We want heroic to work and bestow to work. 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 Eric figured out that we needed a mechanic that helped just make cards go a little easier. That just more often made it 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 Eric wanted to use a returning mechanic just because it'd 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 portents and omens and seeing the future.

So Scry felt like a pretty nice fit for a Greek mythological world. And it did exactly what Eric wanted it to do. And then Eric took the bow and ran with it. And if you see the set, there's a lot of scry in the set, because Eric knows in order to make the rest of the set that I wanted, that he needed to have the flux of the cards. He needed the card flow. Now, the other thing, for example, let's talk about the ordeals.

So the ordeals, the flavor of the ordeals, always has 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 ore on them and that every turn they attack, they get bigger. They get a plus one, plus one counter. But once they have three plus one, plus one counter, but once they have three plus one, plus one counter, they get an additional bonus. So they kind of

accomplish the task. What Eric 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 car 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 Eric said, well, what if it grows up to three like you had planned, and then it gets sacrificed and the effect goes off? So you still get your reward, they still build up, but once they hit the quest, it stops building them up. And I said, oh, that sounds very good. So one of the relationships that design and development have, Eric 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 on the technical side than the managerial side.

That, you know, freeing up me more time to do technical meant, well, take some duties that somebody else could do. And so, both design and development, 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, 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 Eric and I interact and the way that design and development interacts is I set vision.

My job is to say what's important. But then Eric tries to make what is important actually work. So here's another good example. what is important to actually work. So here's another good example. In Innistrad, which also is me handing off to Eric, 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 that 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 need, because in Innistrad, zombies needed to be slow in plotting. They were the slowly overrun you tried, 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 necessarily going to be the fastest because we needed them to be defensive against the monsters. And the spirits had a strategy of invasion through flying, but once again, we didn't want that to be the aggro deck. So basically by press elimination, I said, okay, I need the vampires. 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 when I turned over, what Eric said is, oh, you want an aggressive deck, but you've not made cards. The best way to play the cards you've made is not aggressively. So Eric said, okay, well let's give the vampire some mechanical identity that's flavorful for vampires, but says, hey, let's be aggressive. So Eric came up with using the Slith ability,

which is actually originally from Whirling Dervish, but the ability already comes with the Slith ability, means every time I hit you with combat damage, I get a plus one, plus one 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 Eric came up with. So, the idea essentially, if development is doing their job, and like I said, development is very good. I mean, Eric 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 draft 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're making changes as well. So, I mean, 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. Eric has been amazing, is amazing. And that, it's funny, because let me talk a little about Eric Lauer. Uh, so Eric Lauer is smart. And not just smart, like really, really, really, really, like, genius level smart. Um, and the funny thing is dealing with Eric is that he sees everything almost through like a math field. That he's

very logical and that he likes to kind of process things as logically as he can. And the funny thing is I come from a more of a psychological aspect. I'm all about perception and I'm 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 Eric is very logical. So it's sort of like a little odd couple, if you will. And that's going to make my sitcom about R&D.

You know, it's a nice dynamic where I really have this sort of sense of I feel things and I have intuition and I make gut calls on things where everything Eric does is because he's processed how it works and he understands the system. And Eric'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 is a place to put down ideas and things. We have what we call a wiki, the Magic Wiki, which is R&D is 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 Eric 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 through logic. And it was very, very funny, because it was like him trying to do an illogical subject matter through logic. And the funny thing for me is my background is comedy, right?

I understand comedy, and 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 are 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 on design is trying to have a nice interplay. Because here's one of the things that is 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 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're getting in the way of development trying to do their job. Now, the flip side 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. Development needs a push, but 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 mapping out how the house will be built. But then the development has to build the house. And sometimes, in order to build the house, you're like, oh, well, this room's in the wrong place. 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 is a bearing wall, you can't just easily move it. 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 a designer, you have to figure out if a particular card or mechanic or something, 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've got pretty good, I haven't been doing this a long time, is figuring out what matters. And what I've learned is I don't fight for things that don't matter. If development wants to change something, even if, oh, in an individual case, I'm like, well, I like the other thing better. If what they're doing makes sense and fulfills 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 and every detail, you know, and that individual details, I'm like, look, I gotta, I gotta stay hands off if that detail isn't important.

But, if that detail is important, if that detail adds something,. But, if that detail is important, if that detail adds something, so for example, sometimes they'll try to do something, they're like, no, no, no, here's the point of what the set's trying to do, this undercuts that. Or they're 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 design resources. Whenever I make something that's awesome, but it can only go in one set, I fight a little bit harder to make sure if we can. I mean, if there's developmental problems, it goes. But if it's 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, do a card we can do somewhere

else, now you 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. 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 get 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, I mean, in solitary art form where you are the artist and you're the only one interacting, you kind of got to you know, get rid of your own darlings, if you will. But the thing about this is sometimes one of the nice things

about our 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, and 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 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 ago, so it's a myth, it's my fault. I used to say that design makes a set fun and development makes a 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 it with a flat power level, which means everything's roughly playable and limited. And the reason we do that is, in play testing, 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 that we priced really poorly,

and then, oh, we never realized, oh, this is an awesome card. 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 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. So that's the first myth. The second myth is that all the developers do is tweak numbers.

That's what development is. Development is about tweaking numbers. You know, the design fits everything in, and development just says, 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 that the designs aren't out of bounds. The designs aren't 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 it's trying to figure out. 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 40 times, 50 times, 60 times. That we want, that

draft is a way a lot of people play with 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 that design does a lot. Design spends a lot more time on limited and casual constructed,

where development spends a lot more time on constructed. I mean, they spend a lot of time on draft and they spend a lot of time on constructed. And the reason they spend time on constructed is, A, they spent a lot of time on Draft and they spent a lot of time on Constructed. And the reason they spent time on Constructed is A, they're the experts in the metagame

and knowing what's going on and B, so much 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. 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 divine, 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 will peek my head in, or Eric will come talk to me and say, like, before he had a scry in his head,

he came to me and talked to me and said, is this okay? You know, and I said, yeah, okay, that makes sense. And scry makes sense in the world and I get what you're doing and it's not fighting other aspects. And so there is a very important symbiotic relationship behind 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 part has their strengths. Design's job is taking a blank page and adding something to it. And then development's job 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 I'll 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 would be cards that all make sense and are playable

and you definitely could create an environment where you know it was draftable, but it would be missing, it would be missing sort of the, you know, 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,

wanted a certain sense of feel. But if design made a set and didn't have any development, it'd be broken. It wouldn't work. The focus would be off. 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.

So the funny thing is development without design is you'd have a set that plays but wouldn't have any heart and design without development you have a set that was full of heart but wouldn't play you know wouldn't have

cohesiveness to it and that's why I said that's why I think the relationship is a very important one where you know that each side

has its strength and plays well and the fact that everything we do has two complete different owners, essentially. The first half of the set, let's talk about Theros. I was the owner of Theros.

I was in charge of Theros. And the second half of the set, Eric 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've worked a lot of companies. I've mostly worked at Wizards, but the little that I've seen 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. But like I said,

it requires a lot. You know, the fact that there's no single owner throughout the process means that, for example, it's on my shoulders to make sure that my cares are, I have to watch to make sure that things I care about are not missed. And usually not on purpose. And like I said, Eric 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 the white represented the humans. So I had sort of monster cycles, if you will, things that represented the monster sign. 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 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 Eric. I didn't explain this whole, you know, I wrote a whole document, but I didn't explain the idea of the monster cycles.

And what happened was, Eric just changed some stuff around, and there was no green curse. Now, if Eric 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 design, what I was trying to do, the essence I was trying to get with that, you know, is a little bit of design, but it was lost. The second green does it, I'm accursed. You don't see it as being a monster thing. And just, it's a lot of little subtle things, but it falls apart, you know?

And here's something that I was trying to, this little subtle thing I was trying to build in, and then just lack of communication. And once again, this was on my show. This is not Eric's show. There's, you know, because one of the things that's also tricky is when you're designing, there's a lot going the things that's also tricky is when you're in design

there's a lot going on there's a lot of little subtle things going on and it's 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 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 Eric isn't bothering me constantly like there's someone sitting in the room when they make decisions they go oh yeah yeah we did this for this reason who understands the vision from design. So Eric isn't bothering me constantly. There's someone sitting in the room when they make decisions, they go, oh, yeah, yeah, we did this for this reason.

And then that person is a bridge between the design and development teams. And like I said, it's also important, and another sort of myth, if you will, is design is not always right. The design might make a decision to do something,

but when it gets to development, development goes, yeah, I understand why you wanted this, but it's having consequences that I don't think you want, you know, and that they'll come back and talk to us and you know, sometimes you do something and you're like, oh wow, that's not having

the impact 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 sort of having the right feel, development shines in just understanding functionality

of just practically what this card will do to the environment. And that design doesn't mess with that a lot because we're not at the point where all that is happening. But development, that's their bailiwick. That's what they're doing. And that's where they're experts.

You know, they'll say, oh, 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, it's talking about the gods in Theros. Which was, we originally handed over something that even Aaron had said,

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 Eric, okay, Eric, 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. I think the design's in a good place, but 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 summon a god,

it would just go to Nyx. You're making the god aware of you. 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 game. But they're sitting in Nyx,

so your opponent can't even deal with them because they're in Nyx. And then we have 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 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, if they got some more devotion, they could bring him back. That was their original idea.

And the flavor was pretty cool, this idea that the gods and Nyx, and you can bring them and this and that, but the development said, oh, well, it's confusing, you're making a new zone. You know, it's really hard to get rid of these creatures. You know, there's a lot of sort of functionality.

But what they 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 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 Eric

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 god is the 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, the idea of the gods having a form and then they take mortal form if there's enough devotion. That was a very cool concept. But how we executed it, if that's 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 a lot. And they made a lot of changes. They finished gods... Now, also note that what effects the gods had and what effects the gods had in development were very different. Because we had made the gods' equipment... Not equipment.

The artifacts. The enchantment artifacts. But development was the one... In fact, we had a mini-team that I was on with Eric where we said, okay, now that we've made the gods, and what are the gods doing, what are the equipment doing, make sure that each god's equipment

synergizes with that god, so if we play them together, it's kind of cool. And that's another thing that the 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.

They liked the idea of you send the mission and you grow up, but then they changed the ordeal cycle. You know, they liked the idea of you send the mission and you grow up, but then they changed what the effects were at the end. Because early on, we had effects that affected the creature and they turned them into spell effects. Or sometimes it's even subtle in 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 key for that keyword. And that, a lot of development's job is to say, oh, we like the idea, but yeah, in the environment we're building, this is the wrong effect. And sometimes it's not like design just picked

a bad effect. It's, oh, 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 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. And as did the creative team, which is a whole different podcast.

But, I mean, the, like, a well-designed set that is poorly developed will be perceived as a very, very bad set. And, you know, 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're going to make my set better. set better. When I turn over my design to a development team, I know 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 that is the true part of a collaborative process is having faith that 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. We're the ones that put the stake in the ground and everyone follows what we do. And so I really have a nice vantage point of I do my work, I step 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 the vast majority of both of their work happens when we're done. Anyway, 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, it's because development did amazing work. So thank you, developer. Anyway, I'm of the process. And if you love a magic set, you know, it's because development did amazing work. So thank you, developer. Anyway, I'm 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 next week, guys.