I’m pulling out of my driveway! We all know what that means!
It’s time for another Drive to Work.
Okay. So today, I’m going to talk about an important concept
of design. Iteration. So creative, creative things are what they call an
iterative process. So I’m going to talk today about what exactly that means,
and then how to make your design better through using iteration properly.
Okay. So what iteration is, is the idea that every act of
creation is lots of small acts of creation that you go through a process of
improving things. So here’s how iteration works, and this is true of almost any
creative endeavor, is you start and you do something, and then you sort of
learn from that, and then you do a little more. And that you keep sort of
advancing the thing you’re doing, improving it along the way.
That it’s not like, you sit down to write a book, and the
first draft is the book. No, you write a draft. And then you go through and you
rewrite the draft. And you rewrite. And you rewrite. Or if you’re an artist,
you don’t start just by painting the painting, you first figure it out and you
sketch it, and you spend time and energy slowly figuring out. And with each
iteration you get better.
Now, it depends on the medium how much iteration there is.
In game design, especially in Magic
design, there’s a lot of iteration. So what that means is, and I’ve talked
about this before on my podcast, but today I’ll go a little more in depth.
So essentially the way it works is, in design you come up
with cards. I mean, you come up with ideas. You then have to come up with cards
to represent the ideas. Meaning that one of the things—people often ask about
the difference between exploratory design and design.
In exploratory design, our job is to figure out sort of the
questions at hand. What is the design team going to have to solve? What are the
questions to solve? And so the only reason that we make cards in exploratory
design is to test out theories of what we’re doing. To see if new mechanics
show any promise.
In design, you have to build a file. That the act of design
is built around creating file. Now understand that the file of cards you make
is not really what you’re making. What you’re making is a strong concept and
environment that you are passing along to development to understand what you’re
doing.
Now, you’re trying to make as many cards as possible to
execute on that, and a lot of what you’re trying to do through design is create
a card set that embodies the things that you want. But more important
necessarily than every correct choice is getting the essence of what you’re
trying to do.
But anyway, you are trying—the way design works is, design
is broken into three parts. We call it the vision phase, the integration phase,
and the refinement phase. And each section does different things. And when you
iterate, you are doing different things during the course of each of those
three sections. So I’m going to walk you through the iteration process as it
applies to each of the three phases of Magic
design.
Okay. So the vision phase. The vision phase is you trying to
figure out what your set’s about. What is going on, what do we care about? And
it’s during the first phase that you have to figure out—you tend to figure out
your mechanics, you figure out the major themes.
Now, exploratory design walking into this did a lot to sort
of—usually when we start design nowadays, because of exploratory design, we
have a leg up on exactly what our theme is, and we have a good sense of
mechanics maybe we might be interested in. Because what exploratory design does
is makes a smattering of different mechanics for design to consider.
We changed a little bit of how exploratory design works.
What we do now is, we go shallow on a lot of things rather than going very deep
on a few things. Because the idea is, let’s create a palette of paints for
design to paint with, and let them figure out what one’s the most useful,
rather than going, “I think you’re using red. Here. We’ve mapped out red for
you.”
So what happens when you start design is, you have a lot of
the exploratory design team, of which I’m always part of, has done a lot of
work mapping out kind of the essence of what you’re trying to do. So for
example, when we started Khans of Tarkir,
the block that’s currently out.
When we started Khans
of Tarkir, we knew that we were telling a time travel story. We had started
with the idea of a block structure that we wanted to have
you—large/small/large, and drafting the middle set with both sets. And from
that, we had come up with the idea of a time travel story. That that was the
model that matched what we need to do to have the cards function correctly in a
way that made sense.
And then, once we knew we were doing a time travel story, we
went to the creative team, and they helped shape what the world was going to
be. And that helped illuminate us on the story. And from there, we
understood—so let me walk you through, I’m jumping ahead here.
So early on in design, we knew “time travel story,” and we
knew—we had gone to the creative team and they gave us warlord world which
transforms into another world, and if you know the name of the third set you
can probably figure it out.
So we were going from warlords to dragons. I guess I’m not
giving anything away because it is called Dragons
of Tarkir. And so the idea is that we wanted to transition. And so what
that meant was, design early on had to figure out how to communicate a lack of
dragons in a way that made dragons have a presence without dragons being there.
That led us down the path to the clans, obviously.
So what happens early on in design is, we say, okay. We have
this idea, and so we start designing to it. So pretty early on we had the idea
of clans. For those that don’t know the history of the set, we started with
four and it quickly got to five.
But the idea was, okay. Once we understood some sort of
structure, we then had to make design to fit that. So for example, whenever you
do a faction design, what that means is, you want to have equal—whatever number
of factions you have, you want an equal number of cards roughly in each
faction.
So you want to sort of get a feeling of—because part of
factions is having choices, and feeling like there’s an equal representation of
each of the factions. Imagine if we had done Ravnica, but Dimir had twice as many cards as everybody else. That
would feel off.
So in the vision phase, you’re trying to get a sense of what
you’re trying to do. So during our vision phase of Khans of Tarkir, we said, okay, I got it. We’re doing a clan set.
Originally we didn’t even know wedge yet, because when we started there was
four. We would get there eventually. But early on I’m like, “Okay, we’re doing
the clans, that’s a faction thing. What does that mean?”
Well, a faction means there’s equal numbers. Originally we
were doing four. So when we started design there were four factions, so, okay.
That means we’re going to divvy up the set so there’s four equal factions. And
what we learned, and Ravnica really
hammered this home, although we’ve learned this in other places as well, is if
you’re about faction play, you really need to give one mechanic to each faction
if you want to communicate what that is. That if you’re trying to use your
mechanics to really hammer home factions, one of your important natures of it
is to make sure that you divvy up your mechanics between the factions.
Now remember, we also had done some work with exploratory
design team with the idea of, we were doing a time travel set, so we needed to
have something demonstrate the present, the past, and the alternate present.
And so we wanted to have a mechanic capable of doing that. And so morph was the
mechanic we wanted to do that with. Obviously you guys haven’t seen Dragons of Tarkir yet, but morph was
going to show up, then manifest was going to show up, and then something else.
And so we had a mechanic to sort of mirror what was going on
with the time travel. So we had a morph component, we had factions, we wanted
to make sure each faction—so the trick was, we wanted to make sure each faction
both—because this was a three—at the time, before we got to the wedge part, it
was some were two color and some were three color. And eventually, pretty soon,
still during the vision phase, we got to five. Let me just jump there because
it makes it a little easier to explain this.
So when we had five factions and we had a wedge, what that
said to us was, “Okay. Each of the factions has three colors.” So what that
means is, there’s a lot of overlap. When you are playing with a single faction,
you will have access to all five mechanics. Because every mechanic’s in three
colors, and any one faction plays three colors, that means you have the
potential in any faction to have all the mechanics. So that meant not only did
we have to have five mechanics that represented each of the clans, but the
mechanics had to have synergy with one another because you were going to play
them together.
Okay. So during the vision phase, it’s like, “Okay. We are
trying to understand the different qualities of what’s going on.” Now, usually
in vision, one of the things about the iterative process is you start small and
you build your way up. So the first playtest you have, which is usually an
all-common playtest, what you are looking for is not big picture things, but
actually individual card things. What you’re looking for when you first start
playing in an iterative process is the small things.
So very first playtest, all commons. It’s not (???) do the
commons all play together well yet. You’re not even to that point yet. What
you’re trying to do originally is to say, okay. We want to test the
grounds. We want to figure out, are
there individual fun things? Are there fun cards? Are there things that you
play and go, “Ooh, this is fun, I enjoy this?”
And the answer is, if you can find a few fun cards, you can
turn a few fun cards into a lot of fun cards. Really what you’re doing is
you’re sampling your themes in early playtest. And you’re trying to figure out
what you have that works.
Now, early on, in Khans
for example, we did know we were doing some sort of faction play. So early on
we were trying to figure out how to make the clans feel different. And we had
attributes. When we first figured out the clans, we figured out really quickly
that in order to feel as if they were part of the dragon world, that the clans
would each admire the dragons and have some attribute of the dragons they would
care about.
And so early on we were looking for mechanics, and we knew
the essence of—so remember, early on, the attributes we did, we modeled after… D&D has
attributes, for those that know, so D&D has six attributes. Let’s see if I
remember this correctly. It’s strength, dexterity, intelligence, wisdom,
charisma, and constitution.
And so originally when we had four, we had chosen strength,
dexterity—I thnk we called it speed at the time, dexterity’s speed. We had
constitution, and we had intelligence. So the idea was, there was a smart clan
there was a fast clan, there was a strong clan, and there was a tough clan. And
then when the fifth one got added in, we called it charisma. The fifth clan was
the clan that wanted to win without actually having to fight. And so whatever
they needed to do to win that didn’t require them actually having to fight. And
that ended up becoming Sultai, obviously. And we changed words later on to sort
of match the dragons a little more, we got to “ruthless” and “savage” and stuff
like that.
But anyway, early on we’re of, okay. This clan wins through
being the biggest, the strongest. This clan wins through being the fastest. And
so we had attributes that we’re trying to mirror, we’re trying to get
mechanics. But early on in playtesting, you are at the card level. You are just
looking at the cards. And what happens is, when you play in your earliest
playtest, you’re saying, “Is this card good, is this card bad?”
And what you intend to do in the iterative process is cards
fall into a couple categories. Category number one, which is, “This is awesome,
make more cards like this.” And that is an important one. You want—having a lot
of those means you have a great playtest.
Number two is—I’m not putting these in sequential order, I’m
putting them in the order to talk about them. Number two is, “This is bad, get
rid of it.” Those are also important in a playtest. The first two are very
illuminating. “Yes, this is awesome, use this, make more of this,” “No, this is
horrible, get rid of it.” And usually “this is horrible, get rid of it,” is
like, not only is this card bad, but often it’s representative of a larger
theme that’s bad. Sometimes it’s just the card, just this card isn’t fun.
But the first category is to look at, I open up my avenues
where to look, second one explains to me what isn’t working so I know what to
get rid of. And by the way. You want to have cards that aren’t working. That’s
actually a valuable lesson, that one of the things about the set is, you go
very wide when you first start iterating. That when you first start making cards,
you don’t narrow in yet. Just you try a lot of things.
And so, one of the things I say if you’re a beginner is that
usually in an iterative process, you want to introduce a few things at once, so
you can sort of figure out what’s going on. Very, very, very early in the
iterative process it’s okay to have a bunch of different things just to sample
and see what you like. But pretty quickly, you’ve got to figure out what you
like and what you don’t like.
Okay. So category one is, you like it, make more of it.
Category two is, you hate it, get rid of it. Category three is, it shows
potential, but it’s not there yet. What that means is, well, this wasn’t really
fun, but I think there’s something there. I think with tweaking maybe this
could be fun.
This category is tough. Because when something isn’t
working, your first go is, “Ahh, this isn’t working.” You have to recognize
what isn’t working and won’t work from what isn’t working but might work. And I
think this category is where experience comes into play. It is very easy to go,
“This is working, I should make more of it,” “This is not working, I should
make less of it.” Those are relatively easy. I mean, it’s all hard in the big
picture. But comparatively they’re much easier. Knowing that something isn’t working
but could work requires a deft touch.
The other thing, the final one, which is tricky, is it is
working, but something about it isn’t right. And that’s the hardest one because
when it is working, you’re like, “Oh, this is working.” And to know that
something is working but something about it, even though it is working, is
problematic, is the toughest of all to recognize. I mean, it’s very, very
tricky to recognize.
So what happens is, you playtest, you figure out what is
working and what’s not working. Then you take things that—let’s go through each
of the categories. Number one. Things that are successful. Make more cards like
it. Figure out why. Talk in your group. Talk in your design team, why does this
work? Why is this kicking ass? Why is this card good? And figure out, can I
extrapolate from that? Is there other cards that we can do that will help do
that?
Okay. Next, this card is bad. Get rid of them. And like I
said, if something really isn’t working, and we’ll get to those (???)
categories, if it really isn’t working, it is not doing any service to keep it
around. Part of the iterative process is to find things that are working and
make more of it, find things that aren’t working and make less of it.
And the iterative process is a cutthroat one. You have to
really be as critical as you can. And remember that every idea has to serve the
greater good. That no idea in a vacuum, you can’t judge ideas in a vacuum.
Well, I’m getting ahead of myself. When you’re doing early iteration, just is
it working, is it not working? Get rid of stuff that isn’t working.
If it’s not working but you think there’s potential, change
it. What about this card do you think could work? It’s not working now, how
could I change it? If it is working, but there’s something about it, likewise,
you have to figure out what is there. And remove something. Normally if
something is working and something’s not, take something away and leave—like,
let’s say the card has a couple components to it. Well, take one component
away.
That’s a good trick to learning whether that’s the component
that’s causing problems. Right? Is that—let’s say a card has three components
to it. And something’s working, something’s not working. Well, take a component
away. If it doesn’t work as well, that was one of the ones that’s helping. If
it still works just as fine, maybe that’s one of the ones that’s problematic. A
lot of early iteration is trial and error. Is trying and getting a sense of
things. Because like I said. The first few playtests is just about getting the
general sense of what cards are working.
Okay. Then, the next part, and this still happens during
vision, is as you start to find things that are working, you then start looking
for two-card interactions. Do I have moments in where, wow. This card and this
card are doing neat things. That’s where you’re starting to look for synergy.
Okay. Now, this is all still during vision. You’re trying to
find your initial synergies. And the way you do that is, just looking for
interesting two-card interactions. And then saying to yourself, “Wow, why do
these two cards interact well?” And looking at themes. Because sometimes the
theme is going, oh… these cards are working well, (???) individual cards and
go, “Oh, no no no, they’re playing into a theme, this does Thing A and this
does Thing B, ooh, there’s a synergy between Theme A and Theme B.”
And one of the things you are looking for in your early
design is to start finding basic synergies. Because you want to make sure as
you’re picking your mechanics that you’re making them work together. So for
example, a good example of that is in Khans,
we wanted to make sure that the mechanics we picked had synergy with what was
around it.
Now, we knew we were doing morph, the new mechanic had to
play nicely with morph. Now, morph is pretty easy. Most mechanics, surprise, I
have this creature, it has a mechanic. You can combine morph with mechanics
pretty easily. Easier than most mechanics to combine with.
But anyway, we were trying to get the general sense of
figuring what we wanted. We knew we were doing warlord world, so that also
pushed me toward making a little more combat-centric design. That I knew—part
of setting your vision is also figuring out what is the overall flavor you’re
trying to get, and as you start piecing things together, you want to start
making the mosaic that’s going to build up what your set is.
Okay. Now by the end of vision, the plan you want is you
want to have—you want your commons and your uncommons, maybe your rares if you
have them, but you don’t need a complete set of rares. But you want a general
sense of what you’re doing. You want a good pass on your mechanics. Not that
you won’t change the mechanics but a good first pass will (???) what the
mechanics are, and a good general sense of your theme so that you can play it
and go, “I got it, I got what the set’s going to do.”
So in some ways this is a sampler. This is where you want to
make sure—because at the end of the vision point, you are going to make sure
that other people in the department have a little peek into what is going on.
And make sure they are happy.
Our peek is sometimes at the end of vision, sometimes at the
middle of integration. It depends. But the key of Magic design is, it’s a group effort. And you want to make sure
when you’re working on a group effort that you create the tools necessary to
allow other around you to share their expertise.
And what I mean by that is, for example, development has to
come in and you have to give enough of a sense of what the set is doing that
development understands your goals and can look at your tool and judge your
tools accordingly.
And say, oh, okay, I think I get what you’re doing, I like
what you’re doing or I don’t like what you’re doing, I think your tools are a little
inadequate. Maybe you want to change this tool this way. Or this tool we’re not
going to be able to develop. So you might want to change that now, because
we’re going to eventually have to change it and we’d rather you change it while
you can, you the design team find a replacement, rather than development have
to find it later. Because design’s going to make it more integrated. That’s the
nature of how design works.
So vision ends, and you’ve presented a picture of what
you’re trying to do. It’s commons, uncommons, maybe some rares. But you want to
have a picture of what’s going to happen. And the iterative process, during the
vision phase, is all about slowly adding to the picture. Of figuring out—of
trying to get a sense of what you want to do. Of getting strong individual
cards that play up your themes, of getting mechanics, of getting synergies.
It’s about doing the building work. To use the metaphor of
building a house, vision phase has a lot to do with the architecture. About
making sure that all the foundations are correct. You know what your bearing
walls are. That you built the house in a way that it is going to be solid, and
you can then build on what you’ve done.
Okay. Next is integration. So integration is the phase where
you are trying to take the ideas you have and solidify them and just make a
solid set. This is where you bring in outside assistance to get people from
other sections to sort of tell us if there’s issues. You go to the development
team, you go to the creative team, at this point sometimes you might even go to
production.
So like in Innistrad,
at this point, during the integration phase I’m like, “Okay, I think we want
double-faced cards.” And that was a pretty big deal. That wasn’t just, “I want
to do it.” That required a lot of buy-in from a lot of other people. That I had
to go to production and say, “Can we do double-faced cards? Can we do what I
need to do?” We had to go to Organized Play, okay, we’re introducing something
new to the system. What kind of stress is that going to do? We had to go to
development, and like what are we doing? Are we doing something that’s
developable?
So there was a lot of different things that happened.
Integration is where you step outside. Vision you’re kind of within your own
thing, you’re just trying to come up with what you’re doing. You’re not worried
about other people seeing it at that point. Because you’re just trying to get a
sense of what you want to do.
Integration, it’s called integration, and the reason is,
you’re starting to integrate not just your components, but outside components
as well. And a big thing to remember in the creative process is, if you’re
making a process in which there are others involved in the creative process,
it’s a team thing, that it does no good to keep your team in the dark.
The goal—one of the things we try to do, and over time we’ve
done more and more is, design is not meant to be a black box. It’s not like,
“We’ll do our work and when we’re done, we’ll hand you something.” That we want
to use the expertise of the people around us and work with the people around us
to create something that reinforces what we are doing. Now, design has the role
of setting vision, but it is important that we are working with everybody
around us to make sure that we create a vision that can be achieved.
So the iterative process during the integration process is
about sort of taking feedback externally, and like vision is about sort of
internal feedback. And it’s not that internal feedback doesn’t continue during
integration. But integration, you’re starting to take outside feedback. That
might be just having other people playtest, it might be getting notes from
other departments or sections of R&D.
But it’s about getting more critical analysis of—like, the
vision phase, you come up with an idea, and you sort of said, okay. Here’s what
we’re going to do. We’re going to do this thing. We are doing a horror world.
We’re doing a Greek mythology world. We’re revisiting a world, be it Ravnica or
Mirrodin or whatever.
And so, the idea is that integration is, it’s the same
iterative process, but you are now taking outside feedback in addition to your
own internal feedback. And that is very important, because there’s a lot of
things that might—like when you’re in your little bubble, that might seem good,
that when you bring outside forces that are like…
Because one of the neat things is, when somebody looks at
your set, they are going to look to the set in their vantage point. Now your
job as the lead designer is you’re inside and looking all around. But it’s very
important you get other vantage points, because they’re just going to see
something that you don’t see.
So I used this analogy before, about how when you’re a
director—I wrote and directed plays in college. That it was a very, very
important tool that my actors, my actors—I had to think about all the
characters and how they all interacted. But my characters had to think about
one character. So they spent a lot of time and energy trying to understand that
character. And they would ask questions that I had not thought of because they
were digging down deep. All they were focusing on is that one character.
And that’s very true of when you get outside—development’s
going to come and they’re going to give you development concerns. They don’t
have design concerns. They don’t have creative concerns. They’re going to have
development concerns.
Likewise, creative, they’re not going to have development
concerns, they’re going to have creative concerns. And that each one that comes
to your thing is going to give something that has to do with their vantage
point. Which is very important. Because what you’re trying to do is make sure
that the finished product meets everybody’s needs. And so during integration,
the iterative process during that is taking in the outside feedback and
adapting to it.
So one of the things, by the way, I didn’t explain this
before, iterative process tends to speed up over time. So the iterative process
during the first—vision, note it’s about a year long, and so divided into
three. So it’s about three months and change. I’m sorry, four months. Four
months for each of these phases.
So the first one, you do a playtest during the vision phase
every three to four weeks. Maybe two weeks near the end if you’re really
starting to pick up some steam. During the second phase, you are doing a
playtest about every two weeks. It’s like, you’re getting feedback, fixing things,
and then every other week you’re fixing things, every other week you’re
playing.
Early on, during the vision phase—during integration, you
are much farther along. During the vision phase, you spend a lot more time
talking and building and crafting because you’re making more of the bulk of the
cards. You’re talking more to the themes.
So you get to the middle phase, what you want to do is have
a lot of feedback, make changes, and then go back to the people that you got
the feedback from. If development is saying, “We have an issue with this,” make
changes based on the feedback. And then, return to them to make sure that they
understand. Okay. Which brings us to the third phase.
So once—the first two phases, like you’re in your bubble,
you’re looking external, we get to the last phase. The refinement phase. So at
the end of design, on a large set, for example, the last two months, what we
call “devign.” Which is where development is giving really—I mean, you have
them look and give notes earlier, but this is, like, the team is started up.
When devign begins, the development team begins. And they’re looking at your set
very critically, and playing it, and giving very more intensive notes.
So the refinement phase is—so by the time you walk into the
refinement phase, you want to have all the cards—there’s something in every
single slot. Every single slot has something in it. And refinement is about, “Do
you have the right things in every slot?”
And refinement is about trying to get the final sort of like—so
if we’re using our house analogy, phase one is the architecture. You’re making
sure it’s got a good foundation. Phase two is you are doing the plumbing and
doing the electrical, and you’re doing all the stuff that’s going to make
everything come together. And you’re putting up the walls, you’re doing all the
actual structural getting the house built and making sure that it’s functioning
well. The third phase is kind of the decorative phase. Where you’re coming in, you’re
maybe adding some decorative elements, you’re painting. You’re putting down
carpet.
You’re really turning it from—like, I don’t know if anyone’s
ever built a house, but there are different phases in the house. And the first
phase is kind of like, you’re looking at plans, and then they’re mapping it out
and they’re digging a hole, and then you come in one day and your house is made
out of wood beams. And then they start putting things inside the beams. And
then they make walls. And then they start adding the windows.
And at some point they come in and they start painting, and
they add in the cabinetry and the carpeting. Like, the refinement phase is that
last thing, where they’re putting things in and it’s starting to look like a
house. You can see what is coming from it. And that’s the refinement phase. The
refinement phase is the finishing touches.
Now, in the first phase, in vision, like I said, you have a
playtest about every third week. And in integration, you have a [playtest]
about every second week. And refinement, you have a playtest about every week. Usually
what I like to do during the refinement phase is, we meet twice a week, we meet
once a week and take notes on our previous playtests and make some changes, and
then we playtest on the second day.
Now, one of the reasons why as you move along during the
iterative process, that it gets shorter, is you are making smaller and smaller
changes. Part of what happens is, early on in the iterative process, you’re
making huge sweeping changes.
Like in vision, you might be swapping out mechanics. Like, “Let’s
try this mechanic!” “No, let’s try this mechanic.” “No, how about this
mechanic?” “Ehh, maybe.” “Well, let’s keep this mechanic and change this other
thing.” Or, “Let’s radically change how we do this mechanic.” “This mechanic is
open-ended, but maybe we want a little less open-ended.” Or “Maybe the mechanic
needs to take place at a certain time,” or maybe we’re… the point is, early on,
when you’re doing the iterative process, you’re making huge sweeping changes.
It is quite possible, by the way, between Playtest A and Playtest
B in the vision phase, a third of the file could change. A lot of the file
could change. And then as you move along in integration, there’s still the
possibility for bigger changes. But in general, the changes you’re making tend
to be a little bit smaller than they were during vision. And then refinement,
oh, refinement. You’re making very—you know, much more careful, small changes.
Now, be aware. That doesn’t mean during the course of the
process, things can’t happen. It’s not like vision, I make the big choices and
we’re done. Maybe during integration, development’s like, “We can’t make that
mechanic work.” Like, okay, I have definitely swapped things out during both
integration and during refinement.
Sometimes during devign we put the pedal to the metal and
test something out, really stress test it, development’s like, “Aah, it’s just
not working.” And then I’ve had to change things in devign. I mean, things get changed
in development sometimes. And that’s not ideal. Hopefully you get the mechanic
you want before you get to development. But the idea in general for the
iterative process is that you want to be making smaller and smaller changes.
That the iterative process gets quicker, but the changes are smaller. And that’s
why it can be quicker, because you have smaller changes.
Okay. Let me talk about a couple strategies about how to use
the iterative process. Number one, which is—and this is sort of using science
to your help. One of the things about understanding change is, you need to make
sure that you have some constants and some variables. What I mean by that is,
you can’t change everything. If you change everything, it is too disorienting
and it’s hard to learn. It is hard to understand the differences.
So what you want to do is every time you are doing iterative
change, make sure that you keep something the same. In fact, you want to keep
most of it the same. That you don’t want to change things too much. What I say
is, for beginners that aren’t used to this process, you might want to only
change one thing. That you want to make sure you understand, you have a
grounding in what you’re doing so that you understand what the changes are.
Now, I’ve been doing this a long time. Like I said, it’s my twentieth
year. I tend to go much faster through it. I’m more willing to throw more
different things in at once. But that just has to do with the fact that I have
a lot more experience doing it. And I think that when I have a newer designer,
what I say is, “Make sure you understand what the changes are when you make the
changes.” If you iterate too much too quickly, sometimes, you can lose special
things that you have.
Another important lesson of iteration is—and the reason why
iteration is so important is, there is this desire to what we call “theorycraft,”
which is to understand things by talking them through and comparing them to
other things in Magic. If you are
doing your job—I talked about this in both
of my playtesting podcasts [NLH—I don’t
remember a second.]—if you’re doing your job, you need to be actually playing
with the cards. It’s how they’re going to be perceived by the public. You need
to understand, and you need to put them through their paces in the way they’re
going to be used. Which is through play.
And just like I talked about with the actor, that it’s one
thing to think about a card and another to use a card. And when you use a card,
you actually get the issues that come up. “Oh, I hadn’t thought about that
issue, but now that I’m playing with it, oh, that is something important we
have to think about.”
And so the reason for all the iterations in general is that
if you want to appreciate what you’re doing, you need to walk through and
experience it. That when you’re writing a book, there comes a point at which
you have to read it with a critical eye as a book. You have to read it. Stop
thinking about it as a structure and just read it and go, “Is this an enjoyable
book?” And then test things as you go through. And playtesting’s the same way.
You want to play with your things and get a sense of it.
And one of the neat things about iteration is that if you do
enough iteration, you can see things as they improve. Which from a morale
standpoint is important. That if you have a horrible playtest, it’s a little
discouraging. But if you walk away from it understanding why the playtest was
bad—and one of the things I say is, a horrible playtest is a very valuable
tool.
The most frustrating to me actually is a very mediocre
playtest. Nothing was great but nothing was horrible—those are the hardest. A
playtest in which it was horrible, things stunk, you will learn from that and
you will make changes and you will make it better.
But like I said, the reason the iteration is important is,
you want to build on something, figure out what you’re doing correct, maintain
that, and then adjust things while you’re—part of iteration essentially is, it’s
a building process. What you really are doing is you’re building your set, and
each time, you sort of evaluate your latest changes and say, “Am I going in the
right direction? Is this build what I need?”
And then, what happens is, you take the thing that are
working and you keep them, you take the things that aren’t working, and some of
those might be older things, because as you change things, things that once
worked might not work. And then you remove them.
So in some ways, I like to think metaphorically that you are
chiseling a statue. And that each time, as you find new things that you’re sure
on, you get to keep those things, and then you get to whittle around at the
things that aren’t right.
And there is—one of the things that also, I try to think, people
always talk about how much fun it is, because I get to play at my job all the
time! And it is fun. But one of the things that I always like to say is, we
play a lot of bad Magic so that you
don’t have to. That we try a lot of things and we go, “Ugh, that was horrible!
We would never want to inflict that on the players.”
Now, you guys have the luxury, and it’s awesome, and you
should, of getting to play what we intend. Of being the best of the best. That
this is what we want you to see. And that when we’re playtesting, we do a lot of
things that do not work. That are disasters. We’ll playtest with cards, we’re
like, “Oh, that’s crazy broken!” Or “This isn’t fun!” Or there’s all sorts of
reasons why just you can have a playtest and go, “Ohh, I hated that.”
And like I said, the key to iteration is that you are
building over time. And that when you’re writing a book, it’s like, not every
sentence of every book gets written right off the bat. And that’s the same with
card design which is, if you went through the set and picked out the gems, what
are the standouts? Sometimes some of those cards came early in the process.
Sometimes they came late. Sometimes they came in the middle. That your moments
of awesomeness happen along the way because you create so many opportunities
for that. And that the iterative process allows you a lot of attempts.
I talked about this before, which is, we make a lot of cards
that never see the light of day. For every card that you actually see,
somewhere between fifty and a hundred. R&D always argues about what’s the
ratio of cards made vs. cards printed. And it’s a whopping ratio. Even if it’s
fifty. I think it’s closer to a hundred. But even fifty to one. There’s a lot
of cards that get made that never get seen. And the reason is because you try
things and you always want to figure out the best way to do them.
And what I see in new designers, and the reason I really
stress iteration, I think it’s important is, there is this myth about creation
that like one day you don’t have it, and then thunder strikes your brain, and
poof! And now you have it. And it is complete. And you now have a wonderful
thing.
And there’s this idea that the generation that creativity is
this like thunderbolt from the sky moment, where like it’s just this magical
moment. And the reality is, no, it’s a lot of work. Maybe the initial idea, and
even then. It’s not like your idea comes at once. You work and work and work
and work at it, and finally craft what the right thing is. That very little design—not
that I don’t have moments where—I mean I literally had a moment where I woke up
in my sleep and had an idea. But that’s few and far between.
Usually what happens is, now take Khans of Tarkir for example. We started with the idea of a time travel—we
started with the idea of a weird drafting block. And then we came up with the
idea of a time travel thing. And from that we got warlord world and dragon
world. And then from that we got the idea of doing the clans, and from the clans
we got the idea of aspects of the dragon.
And each thing came along the way. It wasn’t like we just
sat down one day and go, “I got it! Dragon clan!” Like, that was not where the
process came from. It was a small, iterative thing where we kept making small
changes. And that that is what the creative process is. It is a lot of work. It
is not moments of thunderbolts in the brain, surrounded by twiddling your thumbs.
No, it’s a lot of hard work. The reason that a Magic set is as good as it is is because a lot of people put a lot
of energy and a lot of time through a lot of iteration to make it good.
And that part of today is, you’ve got to put in the time.
You are not going to get something brilliant just by sort of sitting around and
talking about it. You’ve got to do it, you’ve got try it, you’ve got to
experiment it, you’ve got to take feedback, you’ve got to adapt to feedback.
And that the way you make something truly awesome is putting in the time to try
every version that isn’t awesome.
In fact, that’s one of the ways I like to joke about “How do
we make a good Magic set?” “By
making all the bad Magic sets and
then getting rid of them.” The iterative process is like, “This is a bad Magic set, let’s try again.” “This is a
bad Magic set, let’s try again.” “This
is a bad Magic set, let’s try again.”
“Ooh, this one’s pretty good. Maybe we should keep this one.”
That in some ways, what we do and what the creative process
is, is slowly working. Just like the act of physically building something.
Building something creatively takes time and energy and care. And that the
reason I talk about iterative process today is, that’s just one of the tools to
be able to build something creative.
And understand the expectation that it’s going to happen
slowly over time, not all at once. And that you will have individual moments of
cool things where you come up with something, but really, the true genius of a
creative work comes from the fact that lots and lots of tiny, tiny awesome
ideas. Not one big awesome idea, but lots of tiny awesome ideas.
And that when you are putting it together, you need to
create the moments of possibility to discover the small things, and to enjoy
the small things. That every small victory needs to have its moment in the sun,
because the small victories lead to other victories. And that is how you make something
truly awesome.
So anyway, I am in my parking space. And so we all know what
that means, that means this is the end of my drive to work. So instead of
talking Magic, it’s time for me to
be making Magic. I’ll talk to you
guys next time. (???)
No comments:
Post a Comment