Multiclassing in Magic R&D

Posted in Feature on October 5, 2009

By Matt Place

I'm writing this article from an interesting perspective. I filled a unique role in the creation of Zendikar: I was the designer/developer for the set. This is a lot like being a fighter/wizard, with the exception that I don't have to rest to memorize my spells. Being the designer/developer meant I was a fully functioning member of both the design team and the development team. Later on I will go into more details on what this role entails, but first, how did I get the job?

My Theory on How I Multiclassed

Like many sets before it, Zendikar had a rough idea of its theme many years before any design meetings were held (thank you, Mark Rosewater!). Now, some sets have obvious themes that lend themselves well to exciting hooks—for example, Ravnica's guild model. However, the set theme that Mark had in mind for Zendikar did not have quite that super theme like Ravnica. The theme proposed for Zendikar was "Lands Matter." When I first heard this proposal, I was not impressed. It felt a bit on the tame side (or maybe something that rhymes with tame?).

Every so often, Mark would bring up "Lands Matter" as a set idea for sometime in the future, and I would respond, "Finally! Lands haven't mattered in any games so far. Now finally they will!" Yes, I can be sarcastic and mean. But before you feel too sorry for Mark, keep in mind that he dishes it out too. For example, his mini-biography (which will be on display at Pro Tour–Austin) says something to the effect of "Everything wrong with Magic is Matt Place's fault." That is pretty mean, right? And now that I think about it, why is that mentioned in his bio?

Anyway, the point is that I was not a believer in the "Lands Matter" set theme for Zendikar. And I believe that the fact that I was loudly unconvinced of it is why he asked me to be on the design team. On the team I would make a good litmus test. If the mechanics were not exciting I would voice my dissent. But if I did like the directions we were headed, Mark could be more confident that something good had been discovered, since even the non-believer had been converted.

What Is the Designer/Developer Role?

So that is my theory on how I got the role. Now I'll talk about what this role entails.

During design, I not only played the part of a design team member but also acted as the development rep. If a mechanic was proposed that was too strong or had other "development" problems I would let the team know, and we could nip the problem in the bud. This meant a lot of time was saved. For example, we didn't waste time exploring broken mechanics like "timewalk X" (I won't give any clues as to what the mechanic did—you will just have to trust me when I say it was too good).

I was also there to do costing for cards that we were putting into the set. This, by the way, solves a big problem that existed when I first got to Wizards. There would be playtests held for sets that were still in design, and because no developer had looked at the set yet, many of the cards were absurdly undercosted. It is hard to focus on the design-relevant issues, like whether or not the new mechanics are fun, when cards stronger than some of the Power Nine are in your Sealed pool. We saved a lot of time by having me there to cost the cards mostly close to correct.

During development, similar to design, I played the part of a development team member but also acted as the design rep. Very often there would be questions during development meetings as to what the intent behind design decisions was, and I was there to answer those questions. This gave the development team better insight into the design and more than a few times helped save a card or mechanic from being cut.

Could Mark Convince Me?

When the Zendikar design team began to meet, one of the early challenges was to find fun and exciting "Lands Matter" mechanics. As I mentioned, this was something I was not convinced could work.

Mark had the design team look for many mechanics that fit with the theme "Lands Matter." The team had a lot of ideas that we experimented with. Mark talked about some of these in his article Achieving Zendikar, Part I. Many of these had a similar drawback: they were mechanics that were land-themed but didn't actually play nicely with lands. For example, "landshort" was a mechanic where you could get more value out of your spell by skipping your land drop for the turn. Having six or seven of these cards in your Sealed Deck meant you often only had three lands out on turn six. This wasn't what we were looking for—it made you feel bad for playing cards that cost five or more and made you wonder if you should be playing fewer lands in your deck. Players running fewer lands in the "Lands Matter" set would have been terrible.

Another space we explored was the ability to use your lands for spell effects. Like this card:

W, discard a land: Target creature gains protection from the color of your choice until the end of the turn.

These types of cards did encourage you to value land higher and potential run more in your Sealed Deck, which was good, but they had other serious problems. Once again we were in a spot where you couldn't cast your expensive cards because you had pitched your lands to get spell effects. Another problem was the bad tension when you were wondering if you should discard lands, like Kabira Crossroads, that had "enters the battlefield" triggers.

Kabira Crossroads

Eventually we made a realization that was very valuable. We should stop trying to force the player to play lands in a new way and just accept that they will want to put their lands into play as normal. This lead to finding the mechanic "landfall." Many of the first designs using landfall played very well, and I was beginning to become convinced that a land set wasn't as crazy as I first thought.

The Creation of Allies

Even though I had started to come around on the "Lands Matter" theme, I still felt Zendikar was missing something. I attempted to solve this problem by designing a mechanic I named "superslivers." These were creatures that were like Slivers, except when they came into play they put a +1/+1 counter on every supersliver in play. I was pushing for this, or a mechanic that would fill this type of role, because I felt the set lacked appeal to some segments of the Magic audiance.

Here is an example:

Supersliver (whenever this comes into play, put a +1/+1 counter on each supersliver you control).
Superslivers you control have haste.

I built some supersliver playtest decks to prove to the team the mechanic was a good idea, but they were not convinced it was needed, so it was shelved for a bit. A month or two later Mark decided we did need a mechanic that had "Sliver appeal." Mark talked about this mechanic in his article Achieving Zendikar, Part II. I'll fill in some of the interesting points he didn't hit. First, the mechanic in design was first called "teamwork." The teamwork creatures had abilities that would turn on if enough teamwork creatures were on the battlefield. This mechanic played well, but not great. It was changed a few times throughout design and in development.

Eventually Henry Stern, the lead developer of Zendikar, decided that teamwork (whose name had changed to adventurer) would be taken out of the set. As the designer/developer, I was not happy. Looking at the big picture, I believed the set needed this mechanic. I expressed how I felt to Mark, and we worked together on a new version he had designed. We eventually took it back to the development team with hopes that they would keep the mechanic.

The version we presented was very close to the final version of Allies, except that every Ally got a +1/+1 counter when another Ally entered the battlefield. The development agreed to try it out. This early version of Allies quickly proved to be too aggressive, since they all were getting huge fast. But the solution to have just some of them get +1/+1 counters solved the problems, and the mechanic made its way back into the set permanently. I was happy.

Sea Gate Loremaster
Oran-Rief Survivalist

The Stellar Story of How Zendikar Got its Groovy Traps Back

Killing mechanics like teamwork is part of development's job, and teamwork was not the only mechanic that nearly died. It also happened to traps during early development. After a few playtests, many of the developers were not happy with the state of traps. And rightfully so—the early version involved first "arming" the trap by exiling it face down, then when your opponent "stepped on the trap" by meeting whatever the trap condition was, you could cast it for free. This version had a lot of rules baggage and play issues. It would require a lot of text because it needed the rules on how to "arm" it, it needed text for the trigger condition, and it needed even more text to say what it actually did when you cast it. This early version also had the big drawback of not being playable unless the opponent triggered them, meaning they often would never get used. So development killed the mechanic, and rightly so.

While I knew it was the right decision, I wasn't completely happy with it. Because I was the design/developer for Zendikar, I had been playing with the mechanic for a long time. I knew there was a lot of fun in the trap mechanic. The "gotcha" moment when your opponent made the wrong move and you were able to use your trap was hilariously fun. Luckily, when the mechanic left the set, its absence was felt. In a set review meeting, the Vice President of Wizards R&D, Bill Rose, talked about the issues he had with the set. He wasn't happy with the state of quests (which were called maps at the time), and he felt the set was missing something. Having been involved with the set for so long, I knew the solution was to improve the design for quests and to bring back a better version of traps (a version that we actually had early on in design).

Pyromancer Ascension
Inferno Trap

I felt that these fixes needed to be done quickly, so I decided to go rogue! Instead of going through the "proper" channels and organizing official teams and meetings, I pulled in some people who could fix these problems in just a few meetings. The team consisted of Gregory Marques, Tom LaPille, Mark Rosewater, and myself. In the first meeting I presented an outline of how I thought quests should work, and using that template Mark designed the card that would become Pyromancer Ascension. That really impressed the team and convinced us we had found the right direction for quests. Traps were also solved quickly by this crack team. The solution was actually easy, since we just used a version of traps we had first designed many months ago early on in design. We presented a few designs for our new versions of traps and quests and were able to convince the rest of R&D that we had found the right recipes. Additionally, a few of those proof-of-concept card designs actually made it into the final set.

Mark Was Right and I Was Wrong

In the end, I admit it, Mark was right about "Lands Matter" being a good theme. But please don't tell him I said that! I am especially happy that landfall doesn't force players to jump through unfun hoops to get value out of their cards, but instead rewards them for doing something they would have done anyway—play lands. I became completely convinced that Zendikar's theme is a lot of fun to play, leads to some really exciting individual card designs, and would get a good reception from players.

For the record, I still plan to hate Mark's new ideas until he proves me wrong. After all, it is my job!

Latest Feature Articles


September 20, 2022

(Almost) Everything to Know About Unfinity Boosters! by, Mike Turian and Adam Styborski

Welcome to the lights and excitement of Unfinity! Magic's latest Un- set release is packed with attractions (and Attractions) to delight players—from the fresh-faced thrill seekers ready ...

Learn More


September 20, 2022

Unfinity Mechanics by, Matt Tabak

Welcome to Myra the Magnificent's Intergalactic Astrotorium of Fun! It's the galaxy's most awesome entertainment complex. For just a few credits, or whatever currency your planet uses, th...

Learn More



Feature Archive

Consult the archives for more articles!

See All