What Is Advanced Design?
I have spent a lot of time in my column explaining the evolution of Magic design. The evolution takes two forms. First, with time, we keep pulling back the scope of what we look at. We started card-focused, then mechanic-focused, then block-focused, then theme-focused, then block-structure-focused, then intra-block focused, and so on. The second thing we've done over time is get further and further ahead in our planning. In the beginning, design was always focused on the set at hand. Then we started taking the whole block into account. Then the next block. Then two blocks. Then five blocks. And now we look seven years ahead. Advanced planning is an innovation in this second camp.
For years, here's how design worked. As head designer, I would sit down with the director of Magic R&D (my boss) and a few other high-level Magic folk and pitch the rough overview of the next batch of blocks. Mostly we agreed to a theme or a top-down approach or a mechanical direction that the design would start with. Then when design started, the lead designer and his or her team would take the jumping-off point and flesh it out. This part of design usually took up the first three or four months. The idea of advanced design is that we now have a team separate from the design team begin working on a block before it gets to the design team. Yes, before design begins, we now do advanced design.
What exactly is the role of this advanced planning team? I had to write it up for the Magic R&D wiki (a tool we use to document all the things we're up to) and I used the following explanation: The primary role of the advanced planning team isn't to answer questions but learn what the questions are. The metaphor I like to use is that advanced planning are the scouts of the adventure party that go out and check out ahead what's ahead before the party gets there.
As an example, let's look at Theros. As I'll explain below, Theros didn't use advanced design but Born of the Gods did. The original plan for Theros block was that the only enchantment creatures would be the Gods. I asked the advanced design team (note that, in the beginning, it wasn't assigned by product but was a standing team that worked on all advanced design work—that has since changed and I'll talk about that below) to explore enchantment creatures. I was very curious what design space the team had available.
My caveat was that I wanted enchantment creatures to feel like both enchantment and creature. While figuring out what that meant, Billy Moreno came up with the idea of bestow, enchantment creatures that were also Auras. Billy stumbled upon the idea because the team was trying to figure out all the different ways enchantment creatures could work.
I guess it's important at this point to explain something key to how the team is set up. I am the overseer of the group but I do not do any of the work. The team (which varies from month to month—I'll also get to this) meets with me and I give it a project dealing with the block we are working on. The team members work on it together in meetings I don't attend and then once a week they report back to me and show me what they've done. I critique their work and then create a new assignment based on that work. This process goes back and forth for the length of the time we have for advanced design. We then write up all we've learned so that everyone in R&D can see it and respond to it before design begins.
As we get to sets that used advanced design, I'll include what happened in them during my story of the set's design. Theros didn't use advanced design (although it did borrow bestow from Born of the Gods advanced design) so today's column is more of an introduction to the process.
Before I explain how exactly advanced design has changed how we design, I need to first explain how it came to be.
Once Upon a Time
Our story begins directly after the end of the second Great Designer Search. Ethan Fleischer won the event and was awarded a six-month design internship. Shawn Main came in 2nd and managed to get another internship, this one with the Magic Digital R&D team (the ones responsible for overseeing things like Magic and Duels of the Planeswalkers ).
The second Great Designer Search was run a little differently than the first because I was looking for a different type of designer. One of my jobs as head designer is to do a lot of holistic, "big picture" design. We felt we were low on visionary-style designers so we set out to find some with the second GDS. That is why we focused more on worldbuilding and had the designers work on crafting their worlds during all of the final challenges.
Ethan and Shawn had been brought on because I saw potential in them to learn how to build blocks, an important and underserved skill set. I had six months to further evaluate them and I was eager to see if this potential panned out. After thinking about how best to both teach and evaluate this skill, I decided to do something a little radical.
While design was working on Theros, I started a weekly meeting where Ethan and Shawn, with a little guidance from me, were going to start working on "Huey" (2014's large October set). The idea was that we would work on something a year ahead of time. This would allow us the freedom to work on a project that wasn't time sensitive. If Ethan and Shawn failed, we would still have our normal design time, but if they succeeded we could use their work once Huey design began.
You have to understand that I hadn't ever done anything like this. I was improvising so I could work on vision with my two new designers. Little did I know, we were about to stumble onto something revolutionary
Flying the Friendly Blue Skies
My goal was to test what Ethan and Shawn could do. That meant it was important to me that I didn't do the work but that they did. It was also important, though, that I could help teach them through the process. How exactly could I do that? I decided to start by talking through with them where Huey stood. When I laid out the seven-year plan to Aaron several years before, I had sold Huey on a unique block structure. I explained to them what this block structure was and then I asked them to figure out a block where this structure made sense.
Ethan and Shawn decided it would work best if they set up some meetings of their own to work on the project I had given them. Along the way, they pulled in other members of R&D to help them. Once a week, they would come in and share what they had learned, often by bringing decks they had made to demonstrate the previous week's worth of work. I would play with the cards and/or talk through their new ideas and then I would explain what did and didn't work for me. I then would craft a new assignment at the end of the meeting.
I've talked a lot in this column about how design is an iterative process. You make changes, you playtest, you make changes based on the playtest, you playtest some more, and on and on. During this process you learn a lot and you slowly move your design toward its end state. What I found with advanced planning was that we were doing the same thing ,but instead of doing it on the micro level worrying about card files, we were doing it on the macro level worrying about the core structure of the block design.
To best understand the shift advanced planning has had on design, let's take a look at before and after.
Design starts. Usually we have some big-picture idea of what we're doing but that's all we knew on Day One of design. For example, Zendikar started as a set with a focus on land. We didn't know what that meant or even how exactly lands were going to matter. The idea of having an adventure world wouldn't happen for months.
Under this old system, figuring out the set and the block happened while we were trying to make the card file work. This meant that we were processing two different things at once. As lead designer of the fall set, I was figuring out what mechanics we were using and how each color was playing out, while as head designer, I was exploring how this first set would fit into the block and how the block wanted to evolve. Because both processes were happening at the same time, it had four impacts.
One, my resources were pinched. Everything I did had to do double duty, which meant that I wasn't maximizing either process.
Two, advancement of the set would begin to limit options for the block. You see, the set design couldn't stand still so as it started making decisions to make the set the best it could be, it continually added new restrictions to the block design. Yes, restrictions breed creativity, but it was creating an odd system where the structure of the set, the smaller item, was dictating the structure of the block, the larger item.
Three, I was often boxing in what development could do. By the time I could explain how I wanted the block to work, the first set was far enough along that it became hard to change if development found a flaw in my block plan.
Four, the system created a pressure cooker where the block planning was always on the clock. There was seldom time to reflect because we didn't have the luxury of time.
Long before design starts (Huey's advanced design, for example, started a year before), advanced design begins. We are not concerning ourselves with a file so we get to spend time focusing on what the block needs. We have time to think things through and experiment. The block plan has room to breathe because it has our total focus.
Also, because the work is done before design begins, we have time to loop in the development and creative teams. Things that might be controversial can be talked through. If there are problems, we have the time to fix them, because the march of the design file hasn't started.
Having worked under the old system for so long, I got used to it. It was a bit of a grind, but that was just the way the process worked. Once I experienced advanced design, I realized that our old system forced us to make constant compromises. Advanced planning allowed everything to breathe and added a new level of clarity. The most interesting thing about it was that we stumbled upon it. Ironically, the process started as a way for me to teach Ethan and Shawn how we design blocks but ended up completely changing how we make them.
"Assemble a Team"
Along the way, not only have we shifted how we do design, we've also shifted how advanced design itself works. Here is the current system. Each set has four members. Note, as I'm the sounding board, that I am not one of these people.
The team consists of the following:
Team Member #1: The team lead—Each block gets its own advanced design lead. Currently, the advanced planning teams are led by either Ethan or Shawn, as they are the two who were hired with this skill set in mind.
Team Member #2: A core designer—This is one of the members of the design team (I am referring to the team of Magic designers I oversee and is managed by Mark Gottlieb). This slot is filled by Ken Nagle, Ethan Fleischer, Shawn Main, Dan Emmons, or Mark Gottlieb. Either Ethan or Shawn are leading the team, but the other can fill this slot.
Team Member #3: A core developer—This is one of the members of the development team (the team of Magic developers overseen by Erik Lauer and managed by Dave Humpherys). This slot is filled by Erik Lauer, Dave Humpherys, Sam Stoddard, Ian Dukes, Ben Hayes, or any of the current development interns.
Team Member #4: A miscellaneous team member—This fourth slot can be filled by anyone but usually leans toward the needs of the team at the time. For example, it is very common for a member of the creative team to fill this slot in early advanced design as we tend to start by understating the world the set is taking place in.
The next big innovation has to do with how the slots are filled. To keep a constant flow of fresh blood and new ideas, as well as to involve as many people as possible in the advanced planning process, the roster is constantly rotating. The lower down of the list you are, the faster the rotation. The team lead is on the team for the duration of the project. The core designer tends to be on for two to three months. The core developer is on for one to two months, while the miscellaneous member rotates every month.
This Is Just the Beginning
We have now been doing advanced planning for over two years and I'm excited to tell you about all the stuff that's come out of it. Unfortunately, only the bestow mechanic has yet to become public. (That's how far ahead we're working now.) Fortunately, the next thing to come out of advanced design was a mechanic we'll be previewing soon for Born of the Gods .
I hope you all enjoyed learning about this new aspect of design. I can't wait to start telling you all sorts of stories about it in the upcoming years. As always, I'm eager to hear your thoughts on today's column. You can email me through the link at the bottom of this column, respond to this article's thread, or contact me through any of my social media (Twitter, Tumblr, Google+).
Join me next week when Born of the Gods previews begin.
Until then, may you get a jump on the thing you're planning to do next.
While I've been on vacation, there has continued to be two Drive to Work podcasts each week. That means for those who don't follow me on social media, you get eight whopping episodes of Drive to Work.
"Drive to Work #78—PT1 Video"
This podcast I tell the crazy tale of the making of the video for the very first Pro Tour.
"Drive to Work #79—Green"
This is the final podcast in my series on color philosophy. I save the most misunderstood color for last.
"Drive to Work #80—Theros, Part 1"
"Drive to Work #81—Theros, Part 2"
"Drive to Work #82—Theros, Part 3"
This is the first three parts of an epic eight-part series on the design of Theros.
"Drive to Work #83—Rarities"
I take a break from Theros design to talk about how R&D decides what rarity a card is.
"Drive to Work #84—Theros, Part 4"
"Drive to Work #85—Theros, Part 5"
- Episode 85 : Theros, Part 5 (13.3 MB)
- Episode 84 : Theros, Part 4 (13.5 MB)
- Episode 83 : Rarities (24.9 MB)
- Episode 82 : Theros, Part 3 (13.8 MB)
- Episode 81 : Theros, Part 2 (17.5 MB)
- Episode 80 : Theros, Part 1 (14.4 MB)
- Episode 79 : Green (16.8 MB)
- Episode 78 : PT1 Video (15.1 MB)
- Complete Drive To Work Podcast Archive