Developing for Design

Posted in Latest Developments on March 13, 2015

By Sam Stoddard

Sam Stoddard came to Wizards of the Coast as an intern in May 2012. He is currently a game designer working on final design and development for Magic: The Gathering.

Last year, I had Shawn Main write an article of Latest Developments discussing what it was like to be the design rep on a development team. Well, that process goes both ways—a design team also gets a member of the development team on it. Having people who cross-pollinate our teams with different strengths is one of the reasons we are able to consistently release high-quality expansions. For Dragons of Tarkir, I was the development rep on the design team, and the carryover from design on the development team.

One of the reasons we have people from each team on each set is so no team ends up getting surprised by something that a set is doing. While it's relatively easy to track the kinds of things going on in a set in Multiverse, you have to be looking at the set to find that out. Between design and development, we have somewhere around six sets in some stage of the process, so keeping an eye on everything is difficult.

Witches' Eye | Art by Daniel Ljunggren

The development team wants some regular updates from one of its members to let us know what a set in the future is planning so we can support it with cards that come before it, and—maybe more importantly—so we don't accidentally block that set's progress by printing cards that will make it difficult to work by the time it gets into development. Similarly, the design team member is there to both generate a lot of new cards and to make sure what we are doing in development doesn't conflict with the larger plans of the design team.

Developing a Design Mindset

The role of the developer on a design team isn't to tell the design team what to do or not do, nor to try and shoot down everything that doesn't seem to be quite right. The role is about acting as a designer and trying out some pretty off-the-wall things, while trying to rein in the more crazy ones—or at least find ways that those mechanics might be expressed in cards that would see Constructed play. A mechanic can read incredibly fun and interesting, but if development can't balance the mechanic, then we're going to have a hard time making cards that people will actually want to own. It's not that development can't make storm cards that aren't broken, it's that we don't believe there are a ton of designs that do that while still reading and playing well.

One of the hardest things for me, personally, of working on a design team was trying to ignore my desire to fix everything all of the time. Part of design is trying out new things and, inevitably, failing. I often wanted to skip the playtesting part and move straight into the "try something different instead" part. The thing is, failing is part of the process, and figuring out what parts of a failed mechanic are actually fun is one of the ways that design ends up with fun mechanics. Oftentimes, a playtest won't yield any useable mechanics or cards, but it will bring the team one step closer to figuring out what kind of room there is to express what the set is trying to express.

Keeping Things on Track

While it is important to not spend a lot of time trying to tell the other designers what will and won't make it through development, the role of the developer is to keep things on track and make sure the mechanics and cards the design team comes up with are things that development can actually work with.

As an example, when design came up with the idea of double-faced cards, Tom LaPille was the dev rep on the design team. While those cards were difficult to get right, they didn't create any inherent problems for development. It would cause challenges for other people in the chain, such as creative (who would have to commission extra art) and all of the people whose job it is to actually typeset the cards and get them printed. He believed the mechanic could work, and he did his best to make the cards actually fun and strong enough that other people within Magic R&D would also believe.

A mechanic that didn't work out for Dragons of Tarkir was "Aura morph." One of the original concepts for how the Tarkir block would work was to put morph on creatures in Khans, lands in Fate, and noncreatures in Dragons. The first version of this we tried was Aura morph to highlight some cross-block synergy with Theros's enchantment and Aura theme.

As the development rep, I quickly pointed out several problems that I saw with this plan. It wasn't that it would be hard to balance the cards, but that there were larger flaws in the gameplay that development couldn't easily solve. Because (at the time) the morphs in Fate Reforged wouldn't be creatures, there really was no way that a face-down card in Dragons Limited would ever be able to turn up to be a larger creature, you could block without worrying about your 2/3 dying to anything except for a pump spell—removing a lot of what I believed was fun about morph.

We attempted to quickly solve the problem by making Auras that had weird triggers—like being cheaper to turn up if they were unblocked and enchanting the opponent, or even being negative Auras that were free to attach to the blocking creature when they were turned face up—but we realized that the whole idea was a non-starter and moved to variations of the creature morph ability.

Now, I don't think that if a developer hadn't been on the team they wouldn't have come to the same conclusion eventually, but the hope is that the developer will not only be able to identify these things earlier, but also direct the design team into areas that are easier for development to create fun and meaningful cards in. The more time the design team has to work with on mechanics like this that work, the more time it has to design cards that can make it into the final version of the file—which I think just makes our sets more enjoyable than when development makes too many of the cards.

Cost Matters

One of the goals for design is to have playtests with a pretty flat power level. That doesn't mean that everything is the exact same power level, but we want to make sure that the things that the set is trying to accomplish are strong enough that the Limited games don't come down to "Well, the removal spells and flying creatures mechanics still work." We want the removal in design to be strong enough to keep a creature with an Aura on it from dominating the board, but not so strong that people feel like they can't do interesting things. Basically, if the majority of the power in design is in the interactions between cards and mechanics, then we can quickly figure out if those are inherently fun or not. If they aren't adding strong cards we won't fix it, and if they are, then it's worth spending some time trying to figure out how to get them to work in development.

Demonic Taskmaster | Art by Chris Rahn

During design meetings, it's the developer's role to suggest casting cost or power and toughness for cards. We can change cards on the fly, but it's pretty disruptive to ask everyone to add a mana to a card in the middle of the playtest. Because of that, the developer on the design team is supposed to go through the file on a semi-regular basis and re-cost cards to make the playtests go as smoothly as possible.

In general, most designers are reasonable at figuring out about how much mana it would take to cost the vast majority of cards. An uncommon 4/4 with flying and lifelink? I would be surprised to see a designer ever put that at something other than six mana. On the other hand, there are plenty of new mechanics that are much harder to cost, and it's good to have someone with more experience tweaking power levels to be the one to take the first shot at it.

One of the goals of getting cards through the end of design is that we have things that are (theoretically) printable. The file doesn't need to be done, but it would be bad to get cards and mechanics the design team is attached to that only work because they are undercosted. As it turns out, it's easy to bias people toward liking things that are more powerful than the things surrounding it. Make one of the mechanics in a set more powerful than the rest, and people will give you feedback of "this mechanic was really fun, but the rest were kind of boring." It's natural—the stuff that works is the stuff that people gravitate to, and the stuff that doesn't feels frustrating. It's the design-team developer's job to try and get everything to a pretty similar level so we can figure out what will be fun when things are balanced, not just in its current incarnation.

At the same time, it's also important for the development rep to make sure that the set will work in the context of "this will work in the real world" and not just in a set's sandbox. It's possible to make any mechanic to work if you build an entire set around it, but development needs things to work not just in one-set Limited, but also in Standard. Buildup-y mechanics like Auras can be made to work in Limited by making the removal really weak, but unless the plan is to make Standard not have any powerful removal, those things are not going to make a big impact. The more the development rep can steer the design team to areas that don't require huge upheaval later, the more polished the set will be by the end, and the more of design's vision can be preserved.

That's it for this week. I'll be back next week with M-Files Dragons of Tarkir edition.

Until next time,

Sam (@samstod)

Latest Latest Developments Articles


June 9, 2017

Changes by, Sam Stoddard

Hello and welcome to another edition of Latest Developments! Today I'm going to talk about several kinds of changes within R&D and how we deal with those. Card Changes From the day ...

Learn More

Latest Developments

June 2, 2017

Things I've Learned by, Sam Stoddard

Hello, and welcome to another edition of Latest Developments! This week is the five-year anniversary of me joining Wizards of the Coast as a contractor on the development team. My officia...

Learn More



Latest Developments Archive

Consult the archives for more articles!

See All