So why am I introducing myself and talking about things that aren't Magic development? Because Sam asked me if I could step in for him this week to talk about being an outsider. Well, it was more specific than that. He asked me to talk about being a Magic designer on a development team.
Two Teams Diverged
R&D is built on the notion that specialization is necessary, but that crosspollination is critical. This philosophy is apparent in every aspect of our work. For example, the design and development teams each sit together, but are separated by only the low cubicle walls of the Pit, so conversations can flow back and forth.
Design and development (along with creative, editing, and the rest of the company) ultimately have a singular goal: making awesome card sets. The main difference is that we're handling the cards at different stages in their lifecycle, so we put our attention on different areas, and, as a consequence, require slightly different skill sets.
At its essence, design is responsible for vision, development for execution. Mark Rosewater's favorite metaphor is that designers are deck builders and developers are deck tuners. My own background is theater, so I prefer to think of designers as playwrights and developers as stage directors. The first group imagines the story, while the second deals with the realities of bringing those words to life.
As a consequence, design does a great deal of blue-sky thinking—"How might we represent the gods of ancient Greece in Magic terms?" Whereas, development deals with more practicalities—"Does this expression of the gods work? Can we simplify it? What's the right devotion threshold for two-color Gods?"
But while each team has a different focus, each needs to consider the work of the other. Design teams always have a developer responsible for tasks like card costing and preventing challenges down the road by considering questions like, "Is this mechanic developable?" And similarly, development teams always contain a designer. The majority of the designer's work is simply being part of the team, participating in playtests, and giving feedback about what is and isn't working, but the designer does have three specific responsibilities.
1. Keep the Design Vision in Mind
Late in design, the lead will create a handoff document, detailing the set's vision. This document explains the goals for the set and what's been done to achieve those goals—themes, mechanics, major card cycles. The handoff document is an important guide because the card set will change heavily during development and the vision should be maintained even as individual cards come and go.
The designer on the team has the responsibility of ensuring that this document is observed. For example, during Theros development, one of my important tasks was protecting flavorful designs that looked out of place. Akroan Horse didn't particularly connect to Limited archetypes and the card looked strange stripped of context, so there was a temptation to remove the card to free up space, but individual flavorful designs were critical to establishing the Greek-inspired world of Theros.
2. Provide a Different Viewpoint
Outside of work, I regularly draft and play Commander, Planechase, and Momir Basic. I made up a Constructed format called Gatherer-Terrible, where you're restricted to cards rated less than 2 on Gatherer. I just finished putting together FlavorCube, built from the most flavorful cards in the history of the game. And one of my favorite things is teaching the game to brand-new players. That is to say: the ways I'm excited to play Magic often look pretty different from those of the average developer.
Developers are drawn from the crème de la crème of professional Magic players. This gives them a deep insight into the mindset of competitive players, which is absolutely critical. But there are many different types of Magic players in the world, playing the game in myriad ways, and we need to make the game for all of them.
While some designers have tournament credentials (Ken Nagle played on the Pro Tour, Dan Emmons was a JSS finalist), designers are often better at representing the kitchen table experience. And it becomes the designer's responsibility to simply provide a different point of view, particularly keeping in mind how less-experienced players might interact with cards.
During Modern Masters development, we wanted draft archetypes that echoed popular Constructed decks like Faeries and Storm, but we needed to find strategies for certain color pairs. I have a great love for quirky draft archetypes, so I suggested trying the zero-creatures Dampen Thoughts deck from triple-Champions of Kamigawa Draft. We already knew we wanted some arcane spells like Kodama's Reach and Peer Through Depths, so the strategy fit and let players relive one of the most unique Limited strategies ever.
3. Design Cards
Everyone in R&D is adept at designing individual cards. Seriously. I'm pretty sure that every designer and every developer has made at least one card that you absolutely love. So why does this get listed as a designer task when the development team would already be eminently capable? Well, the thing designers tend to be especially good at is designing quickly. This is a valuable skill because we're willing to try out a LOT of new ideas, so there's a constant churn as we add cards to a set, playtest, evaluate, kill the cards that aren't playing right, and design new cards to try again.
For example, during Theros development, after reshuffling some bestow abilities and using up the most logical keywords at common, we needed simple lines of text for the uncommon bestow cards. We could have stopped the meeting and had everyone bring back ideas next time, but I was the designer on the team and Erik Lauer looked to me to rattle off a dozen suggestions—lines of text that were simple, grokable, familiar, and that I thought would be fun for both Auras and creatures. Then the developers pored over those suggestions, debated them, and put into the file the cards that would go on to be Heliod's Emissary, Thassa's Emissary, and Erebos's Emissary.
When I started in R&D three years ago, one of the biggest surprises for me was how much overlapping work was being done simultaneously. I'd consistently read Making Magic and Latest Developments since their inception, but was unprepared for the scope. To give a sense of the pipeline right now—two sets are in active design, one set is in predesign, one set has been having a few meetings before starting design, three sets are in development, and three supplemental products are in development (assuming I'm not forgetting anything!). There are only six core designers and eight core developers, which, if you start doing the math, means that everyone is wearing a lot of hats.
This sometimes gives you focus whiplash. One meeting might be early predesign, where you're talking about world design and how different sets relate to a three-act story structure and, during the next meeting, you might be balancing commons across the colors—asking very focused development questions like "Should this creature be a 3/3 or a 3/4?" But working across multiple sets at once itself creates valuable cross pollination—bringing the knowledge of one set's development plan is often very useful to the following set's design. So while we segment into two different teams, the process at every level functions less like a conveyor belt and more like a conversation.