7/11/14 Episode 138: Playtesting

All podcast content by Mark Rosewater

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

Okay. So as of this recording, I have already finished a five-part series on Rise of the Eldrazi. 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 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 as that’s not something I do, I’ve 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 could think about the car, and look at pictures of the car, but at some point, if you really want to figure out if 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, basically what happens is you start with commons. And so the first thing you do in the 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 2/3 of every pack. That they’re going to make the brunt of what people open up.

And so if commons 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, “If your theme isn’t at 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. And 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, that it just makes it hard for your common—your 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. 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 peeking out from underneath. And that way, if it’s a red card and you put it on red, you’ll see it.

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. I’ll get into drafting in 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. 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 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 are printed 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. Design only playtests with stickers. Our cards aren’t a known quantity. Where Development—some of their playtesting is stickers, but some of them is real cards. Because they are also playtesting—some of their playtesting is—half the cards that they’d 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 the 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, stickering on cards. Especially when for our purposes, cards are cards, so the rarity doesn’t really matter. If a card isn’t going to be used anymore, we’ll sticker on it. So stickering on a rare or a mythic rare, like some common sticker, might seem weird at first. But essentially it’s just cards that we have and we need to sticker.

But for example, like one of my rules is I never stickered on a Maro. There’s times when the next card—we take the cards, we have our sticker stock, what we call sticker stock, and we put it in a little box. We just pull them out, and there’s like five slots or six slots, one for each color and artifact. And pretty much you just learn to sticker whatever you got. But Maro, I drew the line at Maro, I would not sticker over a Maro.

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. We 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 at common, we don’t do board sweepers at common, we don’t do a lot of what you would call comeback cards.

So one of the things 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 are going to be high-rarity cards. But in all-common playtest, you don’t have those cards.

So what will happen is, we’ll mock up a card, we’ll sticker them, usually we start with sealed. Draft comes later, I’ll get to draft. 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. Called 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 in conjunction with one another, no matter what you do, certain cards might be better than others, but my goal is, in playtesting is, I just want people to play a lot of cards. In fact, one of the rules of design playtests is, unless there’s an exception, and from time to time we make ripple or we make mechanics where you want to let people play 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 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 playtest 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 different. 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. 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. “Today, you’re playing these colors.” And the reason is, I want to mix things up. And I want to get people to get a sense of what there is to play with.

And once again, because we’re not shooting for balance or to try to make it even, there definitely will be things like 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 don’t want everything to be an obvious choice. If everything’s playable, then drafting becomes all about synergy and very less about 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 synergies and understand archetypes and will craft a slightly better deck. But not nearly as well. And one of the things you want is, you want skill built into the game. In that we want, like “This card is good, this card is bad,” or “This card is good in certain situations.” 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 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—it sounds like it would allow more exploration. But the answer is, it doesn’t. It allows less crafting of the environment. That part of crafting the environment is making a balance so that you can do different things. But when power level’s all equal, it tends to weight toward one or two different things.

And that in design playtests, we can say, “Hey, play different things,” or 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 I limit how many cards they can play of something.

And even so, one of the problems you run into is, even with—like, when I have developers especially that are playing in design playtests, they’re more used to trying to make the best deck they can make. And a lot of design playtest is about experimentation, and so it’s like, “Well, yeah, you can play all the best cards that are all priced so they all can go in the same deck, but that’s really not what we’re testing right now. We’re not testing the environment.” Because we haven’t balanced the environment yet.

So anyway, we have an all-common playtest. The way it works in a playtest is, usually there’s somebody taking notes. On most sets, the lead designer’s the one taking notes. Usually on my sets I have what I call a strong second. One of the ways that I train designers is, I have them work on my sets in which they get control of the file, meaning 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 like, “Oh, we’re missing a blue uncommon.”

And the reason is, usually when you lead 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 set, I’m letting you sort of look at the set, have control of it, but because I’m here helping, I’m overseeing everything.” It’s a nice safe way to sort of learn how to control a 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? 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 that I don’t put it in 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 file, it’s 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.” But the funny thing is, it started as a way to lessen my work, and I realized that it ended up being a really good teaching opportunity. So it worked out well.

Okay. So you’re doing playtests, 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 and you’re like, “Oh, I made a mistake on it. The power/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 changed the card 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 changing the name. Sometimes we playtest it and go, “Oh, this is too powerful. We’ve got to change it.” Developer’s always there, recost things. Sometimes it’s, “Oh, this is 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 didn’t do what we meant for it to do.

Or people thought it did something, they liked that, we 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. Like, “Wow, these cards are really similar.” So we make all these notes. We playtest, we take lots of notes.

The best playtests are the ones 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’s about learning things. And so we want some playtests where we have lots of notes. In fact, we do a playtest where all the games went horribly wrong, and no one had fun, and we have eight pages of notes, 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—we spent two to three years like fine-tuning a perfect product. That’s what you guys get to play with.

Our job—we have a job. I’m not saying playtesting isn’t fun, I’m not saying that I don’t get enjoyment out of it. Because I do. But we are playtesting the early version. We are playtesting the faulty version. A lot of playtesting, we do things and go, “Wow, that wasn’t fun.” And the reason that we have a lot of unfun playtests is so that you guys have fun games. And that we have to try things out. We have to experiment.

And part of design is that you’re not going to know thing sometimes until you try them. And so there are playtests you do in which I, in my heart of hearts, I know it probably isn’t going to work, but I don’t know definitely it’s 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 worked wonderfully. And we never would have gotten to the 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, 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 employees, and R&D is 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? When the Great Designer Search happens, and rejections or giving notes, people are like, “Man, you guys are harsh.” And I’m like, “You have no idea. We are being pretty kind on GDS. We’re not being nearly as harsh as we are internally.” Because internally, like you might work on a mechanic for several months, sit down, somebody else plays it, and they go, “That is horrible. That is a horrible mechanic.” 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, it’s fine. But remember that playtesting isn’t necessarily about finding the solution, but about discovering the problem.

I often say that about Exploratory Design, what we now call Advance Design. Is that a lot of Exploratory Design is playtesting ideas to test out where the problems are. Playtesting is simpler. We want to figure out where the problems are. Usually meetings is where we solve the problems. And playtesting’s where we discover the problems.

Okay. So, if you’re going to playtest, my advice for people playtesting is this: R&D is a bunch of professionals. Normally when you playtest, what I recommend is, you want to playtest with people at some point who are not invested in your emotional well-being. Which means friends make bad playtesters eventually.

Because in their heart of hearts, they know you poured your heart and soul into this, and they want—if they give you negative stuff, they feel like they’re hurting your feelings. And so one of the reasons to have playtesters that aren’t invested, strangers a lot of times, or 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. “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 they need to say to feel like they’re not hurting your feelings. I’m not sure if saying your baby’s hands is probably the correct…

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 on it. So that for every playtest, we have a meeting. And the way playtesting works is, early in design we playtest once every three or four weeks. And by the time we get to devign, which is the end of design, we are playtesting every week.

So what happens is, as the file gets more evolved we playtest more often. Because what happens early on is you’re making broad changes, and near the end you’re making minute changes. And minute changes require a lot more playtesting to find. The larger things, you can have one or two playtests and learn a lot and spend a lot 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 when we tend to do two playtests in the early on, just 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.

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 playtest 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 and make three big changes all at once.

That is not something I heartily recommend if you’re playtesting at home. I think you 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 it in R&D, or not the way I do it in R&D.

And there’s a lot of stuff that I shortcut that I don’t do anymore. For example, I don’t really make use of design skeletons anymore, although if you’re designing for the first time, it’s a really strong tool that I would use. I just internalized lots of stuff. And like I said, I think I just handed over my 20^th 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 I’ll be 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 at 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 a card, they will give you rarities higher than what you asked for. Because it is hard to be simple. People always ask me, “What is 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… “If I had more time, I would have written you a shorter letter.”

And what that means is, when you get a rewrite you make things tighter. That in writing, normally you write something and rewriting shrinks it. Most creative endeavors, the editing process refines things. And simplifies them. And that’s very, very true with game design, Magic 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 and it doesn’t work, you try something different. And little by little you start realizing synergies, and you start sort of getting things to their core. And that one of the things you guys get to see is, we have them boiled down to the simplest version we can do. Early playtesting, it’s 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’ve got some land mechanics that I want to try. One of the things you’ll do early in design is, you’ll throw a little bit 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 I ended up playtesting, you rank all 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. Let’s remove it.”

So what will happen is, I will put 10 mechanics in, we playtest, I rank them, one two three, and anything that’s a three came out, anything that’s a two we tweaked, anything that’s one stayed as is, and then we freed up a little more room, throw 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 with things. That’s early design.

Okay. So you take your notes, you make changes, you bring it back. And then we playtest again. So one of the things is, there’s a couple levels of playtesting. The reason—you could 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 if things change around it, 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 take all those notes together to judge mechanics.

So things you have to be careful about when playtesting is what we call “Random bias,” which means let’s say that I’m trying to make something appear a certain amount. What we’ll call “as-fan,” which I’ve described many times, I will not describe it here, but I’m looking at what percent something shows up. And so when I do playtests, 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 between your cards. You want to make sure that there’s—we want every pack to have a similar power level. Not identical, but similar. Not having 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 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 collation, so you’ve got to be careful, because sometimes it might be, “Oh, this factor didn’t show up,” but the reality is, “Oh, we just got a bad mix. Your mix was 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, well let’s kick everything out.” Sometimes things are working in a bad playtest, but the thing that’s 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 we maybe might just go through the mechanics and things that are the big-picture issues. And then you make the next playtest. At some point, uncommons start to go in. At some point, rares and mythic rares go in. And as you start playing along, you have more evolved playtests.

Now eventually, we start doing draft playtests. The reason we don’t do draft playtests early is, when you’re experimenting—draft is all about trying to put together themes and decks. In that if you draft to early, there is 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, 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 sealed and draft. Even in later design, sealed lets you see different things than draft. Draft points up synergies, it points up how things go together well. But sealed sometimes just gives a slightly better sense of showing you as-fan and showing you… because remember, in the draft, because you can choose what you want to draft, a much lower as-fan can work in draft than can work in sealed. And so sealed does a little better 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 I finally will get to Development. So Development has something they call the “FFL,” or “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 what we found with the Future League was, it was in a really awkward spot. It was 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 call 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 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 to cost for Limited, well, you need to do some Limited playtests and look what our 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 of Block Constructed, sometimes a little bit of Block Constructed gets 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 playtesting within that format. Just to test something. But really, one of the problems is, there’s just a lot to playtest. And 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 manages to make an environment that they understand, the public would figure out that environment in point four seconds.

Like I said, there’s millions of people playing, and there is a network of the internet interconnecting everybody, like 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, if you draw a bad hand you just draw seven new cards. In Development, there’s muliganning. 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 how they work. We’re not really learning anything new. And because playtest time’s 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 are testing the environment that you guys are playing in. And that they want to makes 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, “I’m pulling out of my driveway, you know what that means. It’s time for Drive to Work.”

So I’m going to try to do one in which I’m going to see if I can just end each time. I tend to do my ending, and then I talk for another minute, and that doesn’t seem to really do it. So what I’m going to do now is, I’m going to try to end this much like I begin it, and see what people think of it.

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