Magic: The Gathering Drive to Work Podcast - Drive to Work #138 - Playtesting

Episode Date: July 11, 2014

Mark talks all about what goes into playtesting during design (and a little bit during development).

I'm pulling him in the driveway. We all know what that means. It's time for another drive to work. Okay, so as of this recording, I've already finished a five-part series on Rise of the Abrazi. But I like to break them up a little bit, and so I've recorded this after, but it's appearing before I finish. So I just like to have a little breather. So today I'm going to talk about something that people have requested I talk about, playtesting. Now be aware, I'm a designer, so I'm going to talk more about playtesting on the design side. I'll talk a little bit about what it means on the development side, but that's not something I do. I have less insight. I guess I have some insight, but I have less insight. Okay, so let's talk about playtesting. Why is playtesting so important?

Well, the answer is that there's only so much theoretical work one can do. For example, let's say you're building a car. Well, you can think about the car and look at pictures of the car, but at some point, if you really want to figure out whether or not your car works, you've got to drive the car. And the same is true for a game, that no matter what you do, no matter what you think about, no matter what you compare it to, in the end, nothing is going to tell you whether it works other than just playing it. So a big part of design and development is playtesting.

So I'm going to walk through today sort of different things we do in playtesting and talk about how we playtest. Okay, so for those that have read my nuts and bolts columns, so basically what happens is you start with comments. And so the first thing you do in a design file is you make your comments. commons. And so the first thing you do in a design file is you make your commons. And the reason, for those that haven't heard me explain this real quickly, is that the commons are going to make up two-thirds of every pack. That they're going to be the brunt of what people open up. And so if common can't convey what you need to convey, then usually there's a problem.

That if the essence of your set cannot be conveyed through common, my quote is, you know, if your theme isn't in common, it's not your theme. And what that means is, it's interesting, people attribute it to be a little off from what I mean. What I mean from that is, you have to make sure that whatever the environment you want, that common reinforces that environment. And that if what you're doing is too complex or for some reason can't live at common, it just makes it hard for your common, you know, the common cards are going to dictate your environment. And so make sure that they play into the theme that you want to play into.

So anyway, when we start playtesting, the first thing we playtest is an all-common playtest. Okay, so let me answer some basic questions people always seem to have about playtesting. How do we playtest? Well, the way we do is we make stickered cards. We make stickers and put them on actual magic cards. And so if it's a red card, it gets stickered on a red card. And the stickers are a little bit smaller than a magic card, so on the left and right,

there's a little bit of the card peeks out from underneath. And so that way, if it's a red card, and you put it on red, you'll see. Now, we have a guy named Dan, and Dan is the man. Dan is the person who takes care of all the different business that needs to get done. And if I want to do playtesting, I tell Dan

whether I want to do a sealed playtest or a draft playtest, and I'll get into drafting a little bit. And then Dan will that morning drop off a little box at your table and you are good to go. Now, this wasn't always the case. But it used to be, actually, back in the day, I used to do all my stickering.

In fact, I figured out that at some point, I have stickered some crazy number of cards. Because back in the day, you used to do your own stickering. And in playtesting, you're constantly changing. I'll get into that. But you're doing a lot of stickering. And so now I've got Dan. Dan makes my life much easier.

But back in the day, I was Dan. I was doing my own stickering. So the question is, what do we sticker on? Well, the answer is old Magic cards. Well, which old Magic cards? And the answer is, we have cards. Whenever a new set comes out we get a certain number of every card

and it's an equal number it's not based on anything other than okay we want so many copies really what happens is they print so many sheets so we get more copies of things that appear on the sheet more but for everything but Mythic Rare we get the same number basically

we get a little less of Mythic Rare. So what happens is, we put those in cabinets, and we can use them for playtesting. Development doesn't playtest, or design only playtests with stickers. Our cards are in a known quantity. Where development,

some of their playtesting is with stickers, but some of them is with real cards. Because they are also playtesting. Some of their playtesting is, half the cards of them is with real cards. Because they are also playtesting. Some of their playtesting is half the cards that they need to play in standard, future standard, exist in real standard, and so they can have the real cards. Anyway,

so those cards get used, and at some point, they're no longer in standard, and the cards that are still relevant, we keep. But there are a lot of cards that really are meant for limited, or meant for standard, but not for larger formats. So there's a lot of cards that we could sticker on because we don't need them anymore. And it's a very weird feeling, sticking on cards, especially when, for our purposes, cards are cards, so the rarity doesn't really matter.

If the card isn't going to be used anymore, we'll sticker on it. So stickering on a rare, or mythic rare, you know, make some common sticker, might seem weird at first, but essentially, look,

it's just cards that we have, that we need to sticker. But, for example, like, one of my rules is, I never sticker it on a morrow. There's times when I,

I would, the next, the next card, we, we take the cards we have for sticker stock, we call sticker stock, and we put it in a little box, and so you'll just pull them out, and there's like five slots or six slots,

one for each color and artifacts. And pretty much you just learn to sticker whatever you got. But I drew a line at Morrow. I would not sticker over a Morrow. But anyway, so we sticker the cards, and then if it's a sealed playtest, we mimic sealed. If it's a draft, we mimic a draft, you know, make up boosters. And then we playtest.

So you start with an all-common playtest. And the reason, like I said, is you want to see if the essence of your set is there. Now, there's a lot of things about playing all-commons. Commons, for example, we don't do a lot of two-for-ones in common. We don't do board sweepers in common. We don't do a lot of what you would call comeback cards. So one other thing in a common playtest is it's much, much

easier for one side to get ahead and stay ahead because the things that turn the game around, not a lot of them sit at common because you don't want cards that are constantly doing that. Those tend to be higher rarity cards. But in an all-common playtest, you don't have those cards. So what will happen is we'll mock up the cards. We'll sticker them.

Usually we start with sealed. Draft comes later. I'll get to draft. But usually when you're first playtesting, the goal is that you want to play with a lot of different cards. So let me talk about how we do that. One is when we figure out what they cost, I have a developer on all my design teams, what we call the development representative or the dev rep, and it's their job to cost the cards. The instructions I always give to my dev rep is I want every card costed

such that in limited it could be played. Now be aware, cards are a conjunction with one another. No matter what you do, cards are a conjunction with one another. No matter what you do, certain cards might be better than others. But my goal in playtesting is I just want people to play a lot of cards. In fact, one of the rules in design playtests is, unless there's an exception, and from time to time we make mechanics where you want to let people play with more than two of a copy.

But the rule is you can only play with two copies of a card. If you get a third copy or a fourth copy, you can trade them in for other random cards of that color. But I say only play two copies of a card. And the reason I do that is a lot of design playtests is not about the environment early on. It's about seeing the cards. A lot of design playtests is not about the environment early on. It's about seeing the cards. And what I mean by that is there comes a point where you're carefully crafting the environment.

Are white and black and blue and red and green all balanced? And is there a good mix? And are the archetypes? You try to make the whole environment work. Design starts going in that direction. But really, it's development that does most of that. We don't balance cards. We don't, you know, costing is not what we do in design. So a lot

of design is about seeing things and feeling things and getting a sense of what's working and what's fun. And so in design playtests, I want a lot of variety. In fact, one of the things that I do in design is not only do I limit people to two copies of a card, but I also will do things like say, okay, do not play the colors you played last time. Or sometimes I'll assign colors to people and go, today you're playing

these colors. And the reason is I want to mix things up and I want people to get a sense of what there is to play with. And once again, because we're not shooting for balance or just trying to make it even, there definitely will be things, like, one of the problems of having, one of the things you have to be aware of when you have a flat power level, and this is the reason why Magic doesn't have a flat power level, is that it makes everything possible to do, and it causes a lot of, one of the things you do when you finally actually balance cards is you want things to be, you want to, you don't want everything to be an obvious choice. If everything's playable,

then what's drafting becomes all but synergy and very less of a power level. And the way I describe that is, imagine if you're drafting and every card's a playable card. Well, the worst player's going to have not that worse a deck than the best player, because every card is playable. Now the best player will have to have not that worse a deck than the best player, because every card is playable. Now, the best player will have synergies and understand archetypes, and, you know, will craft a slightly better deck, but not nearly as well. And then one other thing you want is, we want skill builds into the game, and that we want, like, this card is good, this card is bad,

or this card is good in situations, and that you kind of have to learn as you play. So remember, one of the most important things about Magic is it's a game of exploration. And what we want is we want people, when they come and play, we want them to explore. We want them to figure out stuff. And so by having a lot of different things, you need to figure out sort of where things are positioned and what things you want to do.

And that, unfortunately, when everything's at an even power level, it doesn't allow as much... It would sound like it would allow more exploration, but the answer is it doesn't. It allows less crafting of the environment. Part of crafting the environment is making a balance so that you can do different things. But when power levels

are all equal, it tends to weight toward one or two things. And that in design playtests, we can say, hey, play different things. We say to our playtesters that it's not about playing for power, it's about playing for experience and about exploration. And that's why we'll switch colors up or limit how many cards they can play of something. And even so, one of the problems we run into is, even with, like, when I have developers especially play in design playtests, they're more used to trying to make the best deck they can make.

And a lot of design playtesting is about experimentation. And so it's like, well, yeah, you can play all the best cards. They're all priced so they all can go on the same deck. But that's really not what we're testing right now. We're not testing the environment. We haven't balanced the environment yet. So anyway, we have an all-common playtest. And the way it works in a play test is, um, usually there's somebody taking notes.

If on most sets, the lead designer is the one taking notes. Usually on my sets, I have what we call a strong second. Um, one of the ways that I, I train, um, designers is I have them work on my sets in which they get control of the file, meaning, well, I'm in charge of the file. I'm in charge of the set, but I have them be in charge of the file. And it's their job to put in changes and monitor the set and make sure that they're like, oh, we're missing a blue uncommon. And the reason is, usually when you leave a set, you have to run the file.

And so it's kind of like jumping out of an airplane with a tandem parachute. It's like, well, I'm here. I'm overseeing the file. And so it's kind of like jumping out of an airplane with a tandem, you know, parachute. It's like, well, I'm here, I'm overseeing the set. I'm letting you sort of look at the set and have control of it. But because I'm here helping and I'm, you know, overseeing everything, it's a nice safe way to sort of learn how to control file where you're not completely responsible for the file. But one of the things about learning to do design is you need to see the changes as they happen you need to understand well why do we change this and why do we change that and I find that if you're actually controlling the file and making all the changes that there's a lot of learning that comes

physically from putting it in and the reason I don't put it anymore I used to obviously is it just takes a lot of time and that one of the things that's happened is as we keep doing more and more stuff and getting farther and farther ahead, I have more and more responsibilities. And so one of the things I was looking into was finding a way for me to do less things that I don't have to do. And so taking care of the files,

like, oh, it was like killing two birds with one stone. It's like, oh, it's a good teaching opportunity and it lessens my work. In fact, the funny thing is it started as a way to lessen my work and I realized it ended up being a a good teaching opportunity, and it lessens my work. In fact, the funny thing is it started as a way to lessen my work, and I realized it ended up being a really good teaching opportunity, so it worked out well. Okay, so you do a playtest, you take notes.

And notes can be all sorts of things. It could be, this card doesn't work as written, or sometimes, for example, you read the card like, oh, we made a mistake on it, the power of toughness got left off or there's some template on it that was pasted from before but is wrong so part of it is updating cards they don't say what they're supposed to do

or sometimes they have a name and then we change what the card did but we left the name and the name now is distracting because it conveys something that's not true so sometimes it's just like change the name sometimes we play test and go, oh, this is too powerful. We had to change it.

Like I said, the developer's always there. We can recast things. Sometimes it's, oh, it's broken. We thought it would work, but it doesn't work, or it's clunky, or in any way, it just didn't work in the playtesting, or it didn't do what we meant for it to do. Or people thought it did something. They liked that. It was like't do what we meant for it to do. Or people thought

it did something, they liked that, and said, oh, you know, it should do that. Sometimes it's a matter of two cards are just too close together that you didn't realize that until you see the cards in the same deck. You're like, wow, these cards are really similar. So we make all these notes. Playtests, we take lots of notes. The best playtests are the one in which you generate a lot of notes. It's not necessarily a playtest in which the games were all awesome. That's not a bad playtest either,

but usually playtesting is about learning things. And so if we walk from a playtest where we have lots of notes, in fact, we get a playtest where the games all went horribly wrong and no one had fun and we have eight pages of notes, it's actually a good playtest where the game's all been horribly wrong, and no one had fun, and we have eight pages of notes. It's actually a good playtest.

And remember, I know it sounds glorious to go, what do you do for your job? Well, I play Magic all the time. But one of the things people have to remember is, we are not playing finished Magic. You guys get the luxury of playing the finished, you know. We spend two years, two to three years, like, fine-tuning a perfect product. That's what you guys get the luxury of playing the finished, you know, we spent two years, two to three years, like, fine tuning a perfect product. That's what you guys get to play with. Our job, I mean, we have a job. I mean, I'm not saying playtesting isn't fun.

I'm not saying, you know, that I don't get enjoyment out of it, but I do. But we are playtesting the early version. You know, we are playtesting the faulty version. A lot of playtests, we do things to go, wow, that wasn't fun. And the reason that we have a lot of unfun playtests is so you guys have fun games and that we have to try things out and we have to experiment. And part of design is that you're not going to know things sometimes until you try them. And so there are playtests we do in which I, in my heart of hearts, I know it probably isn't going to work, but

I don't know definitivelyly is not going to work. And sometimes when you do something, it's a stepping stone to learn other things. A lot of times I've had a horrible playtest, but the horrible playtest has given me a good idea maybe how to do it better. And that idea has worked wonderfully. And we might never have gotten to that good idea without the stepping stone of the bad idea. And in playtesting, that's another important thing. One is remember that feedback is important. A good playtest

is a playtest with lots of feedback. Another thing that I, this is a little different for us, but one of the things in R&D is we work really hard to be very blunt in our feedback, meaning that it does nobody for our purposes

because we are all, you know, we're employees, you know, R&D, like, we're trying to make the best game we can. We are very honest with each other, kind of bluntly so, which is a little tough at first, you know what I'm saying? Like, when the great designer search happens and the judges are giving notes and people are like, man, you guys are harsh. And I'm like, you have no idea. We are being pretty kind on the GDS.

We're not being nearly as harsh as we are internally. Because internally, like, you might work on a mechanic for several months and sit down and somebody else plays it and they go, that is horrible. That is a horrible mechanic. You know, there's no sugarcoating. It's like, yeah, that's not fun. You should change that. And so one of the things that we learn is, I mean, we try to be constructive. We don't try to be destructive. But it's sort of like, oh, that isn't fun. And the big thing about playtesting is trying to say, here's why it isn't fun. Here's the problem I had with it.

Solutions are good. And if you have a solution, that is fine. But remember that playtesting isn't necessarily about finding the solutions, but about discovering the problem. I often say that about exploratory design, but we not call it advanced design, is that a lot of exploratory design is playtesting ideas to test out where the problems are. Playtesting is similar. We want to figure out where the problems are. Usually in meetings is where we solve the problems,

and playtesting is where we discover the problems. Okay, so if you're going to play test, my advice to people play testing is this. R&D is a bunch of professionals. Normally when you play test, what I recommend is you want to play test with people at some point who are not invested in your emotional well-being, which means friends make bad play testers eventually because in their heart of hearts, they know you poured your heart and soul in this and they want you know, if they give you

negative stuff they feel like they're hurting your feelings and so one of the reasons to have play tefters that aren't invested strangers a lot of times game players from a store that you're not super friends with because they're going to give you the honest feedback you need they're going to call your baby ugly.

If your baby's ugly, you need playtesters that will call it ugly. And that is hard. Your friends don't want to call your baby ugly. Your friends want to say, well, you know, your baby has cute hands, or whatever. Whatever they need to say to feel like they're not hurting your feelings. Well, I'm not sure. I'm not sure. Saying your baby has hands are probably the correct ones.

Anyway. Okay. So you take lots of notes. So then what happens is you go back. So design, any creative endeavor is what we call an iterative process, iteration, where you do something, you work on it, you get feedback, and then you improve upon it. So after every playtesttest we have a meeting and the way playtesting works is early in design

we playtest 173 or 4 weeks and by the time we get to divine, which is the end of design we're playtesting every week so what happens is as the file gets more involved we playtest more often because what happens early on is you're making broad changes

and at the end you're making broad changes, and at the end you're making minute changes, and minute changes require a level of playtesting to find. The larger thing, you can have one or two playtests and learn a lot and spend a lot of time fixing problems. And that's why early on you actually don't playtest as much is one playtest, and sometimes you'll do one or two playtests in a row. I find that normally we tend to do two playtests early on, just so everybody

has a chance to experience a bunch of different things, try different colors. So usually we'll do two playtests back to back. The way it works for design is we meet twice a week for two hours a week. And so our playtesting is done during our design meetings. So anyway, you playtest, you get notes,

you come back, you talk, you make changes. One of the things to be careful about is not to make too many changes. Having done this a long time, I probably make changes fast. Like, I'm going to give you some advice about things to do that R&D doesn't necessarily do

that way, only because with experience, you get better at doing it. And so my example is you don't want to change too much when you play tests because you want to make sure you understand what you're changing. Having done this a long time and having a lot of experience with it,

I can much quicker understand what's wrong and have a much better sense of what I can change to fix my problems such that I will find three problems, make three changes, big changes all at once. That is not something I hardly recommend if you're playtesting at home. I think make one big change at a time and then playtest. It'll help you understand better the implications of your changes. Not quite the way we do in Narnity or not the way I do in Narnity.

And there's a lot of stuff that I shortcut that I don't anymore. For example, I don't really make use of the design skeleton anymore, although if you're designing for the first time, it's a really strong tool that I would use. I just internalize a lot of stuff. And like I said, I'm on my I think I just handed over my 20th design, so I've been doing this a while. Okay, so, you now have your second playtest. So, normally what we do is, I'll have one or two playtests with the commons.

Normally, by the time we're fixing the commons up, I'll start having the team make uncommons. Now, the funny thing is, when I have the team make commons, a lot of the cards that end up going in uncommon were turned in for commons. And not that they were turned in as uncommons. A very common thing is when you ask people for cards, they will give you rarities higher than what you ask for because it is hard to be simple. People always ask me, what's the hardest rarity to design for? And the answer is common. And the reason is, well, at higher rarities, you just have more words and more space, and you're allowed to do more things. At lower rarities, you really have to figure out the simplest, most elegant way to do something, and elegance does not come easy. One of the things you'll find about playtesting is, there's a saying about, sorry, if I had more time, I would have written you a shorter letter.

And what that means is, you know, when you get a rewrite, you make things tighter. That in writing, normally you write something and rewriting shrinks it. In most creative endeavors, the editing process refines things and simplifies them. And that's very, very true of game design, and badge design in particular, which is your early versions of things are the raw version, and as you slowly work through them, you get to the right version. Part of that is just try something that doesn't work, you try something different, and little by little you start, and then you start realizing synergies, and you start sort of getting things to their core, and that's one of the things you guys

get to see is we haven't boiled down to the simplest version we can do. Early playtesting things a little wordier, there's a little more going on. Oh, another important thing that we do in design is, let's say we want to try something. So for example, I'm doing Zendikar, and I got some land mechanics I want to try. One of the things you'll do early in design is you'll throw a little of everything in. Oh, we have a whole bunch of land designs? Well, let's try a little of this and a little of that. And you'll throw a lot of designs in.

For example, I think when we first started playing Zendikar, we had like 40 designs. We didn't put them all in one, but let's say I put 10 designs in. And then at the end of that playtest, we would wrinkle the mechanics. Okay, was this worth looking at some more? Do we want to keep it in as is? Do we want to tweak it? Or do we want to take it out? Those are usually the things you ask about cards.

Keep it as is. Tweak it. Take it out. Keeping it as is means it really was working. You don't want to mess with it. Tweaking means I like something about it, but it's not where it needs to be. Take it out is I don't believe we can tweak this. I believe this is a fundamental. It's failing. to mess with it. Tweaking means I like something about it, but it's not where it needs to be. Take it out is, I don't believe we can tweak this. I believe this is a fundamental.

It's failing. Let's remove it. So what happened is I would put ten mechanics in. We'd play tests. I would rank them, you know, one, two, three. And then anything that was three came out. Anything that was two, we'd tweak. Anything that was one stayed as is.

And then we freed up a little more room. We threw in a few new mechanics. And we kept doing that until we got down to the mechanics we liked. And once again, that's an example where design is not always trying to do the environment, it's trying to let you playtest and experiment things, and that's early design. Okay, so you take your notes, you make changes, you bring them back, and then you playtest again. So one of the things is, there's a couple different levels of playtesting. The reason there's, you can look at playtesting as any one playtest.

In this playtest, what am I learning? And then there's playtests over time. And so one of the things you have to look at is you've got to look at mechanics over time to say, okay, how is this functioning? And things change around it. What am I, am I enjoying this more or less? And one of the things you have to learn is you take notes about mechanics over time

and then you have to take all those notes together to judge mechanics. So things you have to be careful of when playtesting is what we call random bias, which means let's say that I'm trying to make something appear at a certain amount, what we call ASVAN, which I've described many times, I will not describe here, but I'm looking at what percentage something shows up.

And so I do a play test, I go, wow, this thing really didn't seem to show up. Well, I've got to be careful, because it's possible that it's at the right number, but just we had a bad collation, if you will. In actual magic, collation means we're careful about what order we put things on the sheets to make sure that there's a mix when you get your cards. We want to make sure that there's a... We want every pack to have a similar power roll, not identical, but similar.

Not have major, major swings in which this pack's unplayable and this pack has all the good cards in it. So, when you're doing playtesting, I mean, the only collation that happens is you're doing playtesting, I mean, the only correlation that happens is you're making sure you match your rarities. So, when we playtest, we have the right number of commons, uncommons, rares, and mythic rares. But other than that, there's no correlation.

So, you have to be careful because sometimes it might be, oh, this factor didn't show up. But the reality is, oh, you just got a bad mix. You're mixed with low. So, one of the things you have to be careful of is making sure that that is true. Also, as things change around it, you have to take into account what is happening as things change, and that's important to take into account. Like, it's very important not to go, oh, this was a bad playtest, let's kick everything out. Sometimes things are working in a bad playtest, but the thing that's making a bad playtest, let's kick everything out. Sometimes things are working in a bad playtest,

but the thing is making a bad playtest, you have to fine-tune what isn't working. So often after a playtest, we will go through the playtesting itself, make notes. Sometimes we go through the whole file. Sometimes we just go through, if there's enough changes to make, we might just go through the mechanics and things that are the big picture issues.

And then you make the next playtest. At some point, uncommon starts to go in. And At some point, Uncommon starts to go in, and at some point, Mythic Raiders go in. And as you start playing along, you have more involved playtests. Now eventually, we start doing draft playtests. The reason we don't do draft playtests early is,

when you're experimenting, drafts are all about trying to put together themes and decks, and that if you draft too early, you are just, there's not enough to build on to do drafts. So one of design's jobs is, eventually in the design, we have to make sure all the archetypes for the different color combinations are there, that there's different things to draft and different things to do, and that later on in design, we want to make sure those things are there. Oh, well, here's what we want the red-blue deck to do.

Is that coming out when people draft? Are they seeing this? And so later on in design, we will do draft playtests, although we tend to mix between seals and draft. Even later in design, seals let you see different things in draft. Draft points up synergies

and points up how things go together well, but seals sometimes just does a slightly better sense of showing you As-Fan and showing you... Because remember, in Draft, because you can choose what you want to draft, a much lower As-Fan can work in Draft than can work in Seal. And so Seal does a little bit of a job of showing you a general sense of As-Fan. But anyway, both Sealed and Draft have different things that they show you, and so you want to sort of be careful to mix them up so

you get a chance to see both things. Okay, I'm almost to work, so finally we'll get to Development. So Development has something they call the FFL, or the Future Future League. The way the Future Future League came about is once upon a time, we had a Future League that was six months into the future. And came about is once upon a time we had a future league that was

six months into the future and what we found with the future league was it was in a really awkward spot there's enough in the future that we could see problems coming but not enough in the future that we could change cards to stop that future from happening so we decided to push back another six months and be a year ahead and so instead of the future league it was called the future future league or FFL for short. I think because it sounds like NFL, people liked it. Anyway, we called it the FFL, and so what happens

is development is always playtesting a year into the future. Now development does playtests when they get handed over the set. They're doing playtests because they need to cost things and balance them, and so they're doing developmental playtests, which just means we're trying to fix this file, we're trying to think about limiting it them. And so they're doing developmental playtests, which just means we're trying to fix this file,

we're trying to think about limited for this set, we're trying to play this set in isolation to figure out what's going on. And then eventually, when they are confident, they add that set into the FFL. And then, now they're playing standard in which the new set is involved, and that's where they're trying to figure out more constructed things. So remember that limited and constructed are very different animals and development has to do different playtests to be able to look at different things.

That if you want a cost for limited, well you need to do some limited playtests and look at how cards are doing in limited. If you want to understand constructed, well you have to play the set in a larger constructed environment to understand what role it plays in constructed. So people often ask, well they playtest standard, how much playtesting of other formats are there? And the answer is, not a lot. If we know there's going to be

a pro-tour on block constructed, sometimes there's a little bit of block constructed played. If there's a particular worry about some of the larger formats like Modern or Legacy or something, every once in a while there's some playtesting

within that format just to test something. But really, one of the problems is there's just a lot to playtest. There's millions and millions of players, and we have a handful of people. Oh, another thing that's important to understand about playtesting is what development wants to do is make an environment that they think is going to be fun. They can't solve it. If development managed to make an environment that they understand, the public would figure out that environment in.4 seconds. Like I said, there's millions of people playing, and there is a network of the internet interconnecting

everybody, so information is shared, that any knowledge learned is learned quickly. And so what development has to do is they have to make an environment with potential to do different things, but one complex enough that they can't understand. That's one of the reasons that development is so hard is they can't make a definitive answer because they don't want it to be solvable easily.

And if they solve it, anybody can solve it, or the group at whole will solve it. The difference between design and development playtests... Design playtests, for example, we... If you draw a bad hand, you just draw seven new cards. In development, there's mulliganing. And the reason that's true is design, there's no balance. You're just trying to play, and that...

There's no reason... The game has built into it ebb and flow of mana and that's, I think, very important for the game. But we are limited in the amount of time and space we have to playtest. And that

we know games will result in mana screw and stuff like that. But we need to skip it because playtesting a game in which oh, we learned that if you don't get a lot of land, you often lose. Doesn't allow us to play the cards and see whether they work. We're not really learning anything new.

And because playtest time is so valuable and because design is all about, not environment, but exploration, that we just draw a new hand. Development, they need to do the mulligans because they're testing the environment that you guys are playing in.

And they want to make sure that people aren't abusing the system. And so they do need to do normal mulligans. So, anyway, that is all I have to say about playtesting. So anyway, people keep asking me about my closing thing. And so someone made the point that I always begin by saying,

you know, I'll put my driveway. You know what that means? It's time for a drive-thru. So I'm going to try to see if I can do one in which I'm going to just end each time. I tend to do my ending, and then I talk for another minute, and that doesn't seem really good. So what I'm going to do now is I'm going to try to end this much like I began it and see how people think of it. So

thank you guys for joining me today for playtesting and learning all about that and I hope today was informational and next week we'll get back to doing more Rise of the Odrazi and so guys, I'm pulling in the parking lot. It's time for me to be making magic. Talk to you next time.