Welcome to the second week of Battle for Zendikar previews. Today I will continue the story of the set's design and also show off another fun preview card. If you haven't read last week's column (Part 1), I urge you to do so, as I'll be proceeding under the assumption that you have. That said, let's jump back into the design story.
We Don't Need No Stinkin' Colors
When last we left, my design team and I had made the decision to make all the Eldrazi cards colorless. Some would be what we ended up calling "true colorless," in that they cost generic mana to spend and were colorless. Others were devoid, meaning they had a colored mana cost, but they were colorless for anything that cared about their color.
A quick aside, because this question has popped up numerous times in my social media. Is devoid somehow breaking the color pie? The answer is it's doing exactly the opposite. By having devoid spells, we are allowing ourselves to make colorless spells that still stay confined within a particular color. A red devoid spell, for example, gets to do red things because it still requires you to spend red mana. It's the true colorless spells that are the actual danger—but as we've learned with artifacts, there are some tricks to make sure the colorless spells don't undercut the color pie. One big trick is not making too many of them—which inspired the creation of devoid.
Once we committed to all the Eldrazi being colorless, that allowed us to mechanically affect them (both positively and negatively, but more of the former), so "colorless matters" became an important theme of the design. We ended up having some color combinations care more about colorless permanents (black and red) and others care more about colorless spells (blue and red). Cards that cared about colorless cards being cast was where the two areas overlapped.
Art by Michael Komarck
Spawn of the Scions
The other area besides colorlessness we wanted to bring back was the Eldrazi Spawn. For those unfamiliar, Eldrazi Spawn are 0/1 colorless creature tokens with the ability to sacrifice themselves to add one colorless mana to your mana pool. The Spawn did good work helping to cast the Eldrazi (especially the larger ones), had unique gameplay, and were very flavorful. Also, unlike other elements of the Eldrazi, they were New World Order–friendly. The very first Battle for Zendikar design playtest had Eldrazi Spawn in it, and the Spawn stayed all the way through design.
Development liked what the Spawn were trying to do, but felt that they were making games a little more defensive than would be preferable. The design team had put in cards to help encourage the idea of attacking with the Spawn, but their natural 0 power made it hard to do anything without help. The development team decided to try a tweak and changed the Spawn from 0/1 to 1/1. Playtesting proved that this change was doing good work, so the change was made permanent. The creative team then changed their name from Spawn to Scions to reflect that in our six-year absence, the Eldrazi had grown in power even down to their tiny creature token forms. Design-wise, we decided to focus the colors that made Eldrazi into green and blue. Green is one of the colors that makes the most creature tokens and is the top color in mana production. Blue was chosen because of its history with producing colorless mana and the desire to let green-blue have a ramp strategy that would be similar to the feel of Rise of the Eldrazi.
Hungry, Hungry Eldrazi
The next big hurdle for the Eldrazi was capturing a sense of voraciousness. One of the defining traits of the Eldrazi is that they "eat worlds." Back when we first introduced the Eldrazi during Zendikar block, I said that we internally described the Eldrazi as "Galactus meets Cthulhu." Galactus is a humongous character in Marvel comics that literally eats worlds. On top of that, the one Eldrazi titan we encounter on Zendikar is Ulamog (aka Ulamog, the Infinite Gyre). Of the three titans, Ulamog is known as the Eldrazi titan that eats everything.
I really wanted to give Ulamog and his lineage a mechanic that captured this endless hunger. I did not, however, want to bring back annihilator. So the big question was, how can we create something that captures a sense of this world-eating but doesn't just shut down the game? We explored if there was a different way to "eat" permanents, but we kept running into the same problem that destroying permanents becomes very "win more" (an R&D term for a card or mechanic that helps the person who's ahead get further ahead).
Art by Michael Komarck
Meanwhile, another goal I had with the Eldrazi was making them feel alien and unfathomable. In order to do this, I had to mess around in mechanical space that we normally don't use. During exploratory design, we tried numerous crazy mechanics. For example, we had a mechanic called "hedronize" that was a keyword action. Whenever you hedronized, you rolled an eight-sided die (made to look like a Zendikari hedron) and there were eight possible effects that could happen. The idea behind the mechanic was that it would make the Eldrazi difficult to play against because you would never quite know what they were going to do. In the end, it also made it hard for you to play the deck, because you never knew what was going to happen.
During exploratory design and early normal design, we pushed a lot of boundaries trying to find "hunger" design space. One day, we decided to try cards that cared about what's been exiled. We only looked at the opponent's exiled cards, as this kept you from abusing the system by exiling your own cards.
Also, there was my issue with the exile zone. Once upon a time, the graveyard was where cards went when they died or were destroyed (if permanents) or were countered (if spells). As more and more spells made use of cards in the graveyard, the zone stopped being a place things were removed from the game and turned into a second hand. While I enjoy graveyard shenanigans as much as the next player, I have always felt it was important for exile to not just become another graveyard—which is why I've been very against anything that brings cards back from exile.
The way the cards worked in design was that they all exiled one or more cards (in many different ways and from many different places) and then had some ability that cared about what had been exiled, sometimes just counting numbers but sometimes specifically caring about what cards in particular were exiled. The more I played around in this space, the more I realized what my concern with the exile zone was. It's important to have a zone to send things that signifies that they are, for all intents and purposes, removed from the game. In fact, the exile zone used to be called the "removed from the game" zone because that was its basic function.
The more I examined the issue, the more I realized that what I was trying to keep from happening was you taking advantage of things you've exiled (or things of yours exiled by other players). Once you've made the choice to exile something (or someone else has exiled it for you), it's supposed to be off limits. But this abuse is lessened if you only have access to exiled things that aren't owned by you.
When this mechanic was turned over to development, they had a bunch of problems with it—the biggest being the rate at which it grew. It was hard to have scaling effects where the cards didn't quickly get out of control. That's when Erik Lauer, the set's lead designer (and also head developer, my equivalent on the development team), came to me and asked if instead of counting how many cards your opponent had exiled, perhaps we could use them up. What if there was a zone even more removed than exile? What if things could be exiled from exile?
This meant that the Eldrazi player would do everything they could to exile cards and then "eat" the cards that have been exiled for effect. By using the exiled cards as a cost, it could keep them in check and allow designs with much bigger effects. The problem this led to was there weren't enough ways to exile cards. Design had changed a lot of effects that normally got rid of permanents or spells to now exile them. The ability Erik liked had been one we had put on a single creature. That creature exiled a card off the top of an opponent's library every time it dealt combat damage to that opponent. What if this ability was keyworded and put on more Eldrazi? This is what ended up being called ingest.
Erik then came back to me with another request. Having to keep track of an extra zone was logistically a pain. What if when you "ate" the exiled cards, instead of being super-exiled, they went back to the opponent's graveyard. My gut response was a strong dislike, because I've worked so hard to keep exiled cards from returning, but the more I thought about it, the more I realized that it wasn't affecting the issue I cared about most: the ability to get back your own exiled cards. The original version of what we now call Processors was you paying a cost to get an effect, a small part of which was returning exiled cards to your opponent. The system could not easily be abused, because it was your opponent who chose whether or not to bring it back to the game, and even then, it was put back into the graveyard where it's not as easy to access. I played with Erik's suggestion for a while and realized that it actually was the cleanest and easiest execution of the idea. Also, it felt very weird, which was what we were shooting for with the Eldrazi in the first place.
Okay, the Eldrazi had colorlessness, devoid to keep them from breaking the color pie, "colorlessness matters," Scion creature tokens, ingest, and Processors—the creatures that utilized cards in exile. We had done a good job of capturing the many aspects we needed to capture. We, of course, were only half done, as we still had the entire other side to design. (Note that for clarity’s sake, this story has me talking about design of the Eldrazi first and design of the Zendikari second, but both actually went on concurrently through design and development.)
Give a Rebel Yell
We knew a number of things walking in to design the Zendikari side:
- Landfall was coming back.
- Allies were going to return with a mechanic that was synergistic with the Allies of original Zendikar block.
- "Land matters" would be a theme of some kind.
- We'd have to create some contrast between the Zendikari and the Eldrazi.
These four tenets all played out in the design and development of the Zendikari. Let's go through each one by one.
Landfall was coming back.
Art by Daniel Ljunggren
With the exceptions of the poorly labeled "mechanic" full-art lands, landfall was the most popular mechanic of the original Zendikar block. It played into the lands theme of Zendikar and it allowed a lot of design space on creatures. Bringing it back was a no-brainer. What was a little trickier was how we were going to bring it back.
While landfall was well liked, it did cause a few problems last time around. For starters, it pushed Limited (and Constructed for a while) to be hyper-aggressive. When your creatures are mostly given a bonus on your turn, you're very encouraged to attack. The end result was that Zendikar Limited was a little too fast for some players' tastes. We wanted to bring landfall back, but we wanted to make sure it was executed a little differently. Interestingly, design pulled a little too far back and development ended up making the landfall cards a little more aggressive (but still less so than the first time around).
Next, we wanted to make sure that while returning to landfall, we weren't just repeating the same designs. The Battle for Zendikar design team worked very hard to make landfall feel familiar while also executing it in a few new ways. My favorite is an uncommon cycle called the Retreats that are all enchantments that let you choose one of two effects for the landfall—sort of a landfall charm.
Allies were going to return with a mechanic that was synergistic with the Allies of original Zendikar block.
When we knew the original Zendikar block was going to have an adventure theme, we were excited to make creatures representing adventurer parties. This ended up being the Allies. To make the Allies have a linear connection, we used an unnamed mechanic that rewarded you whenever an Ally you controlled entered the battlefield. They came in three varieties. (For the fuller story, check out my column on the design of Allies in the original Zendikar block.)
The first we called the "fighters," and they were Allies that got a +1/+1 counter put on themselves whenever they or another Ally entered the battlefield under your control. Next, we had the "wizards," which generated an effect whenever an Ally entered the battlefield under your control. That effect was scaling and counted the number of Allies you had. Finally, we had the "clerics" that generated an effect that affected all of your Allies whenever an Ally entered the battlefield under your control.
When we first started out, the goal was to see if we could make a new Ally mechanic that would fit in with the old Ally effects. As I said before, we wanted you to be able to mix old and new Allies and have the deck work. Design started with the idea of trying something similar but different. Instead of caring about Allies entering the battlefield, we cared instead about Allies attacking. Here's how that mechanic—which was never given a name—worked: Only Allies could have that unnamed keyword, and if they did, whenever they attacked, they granted an ability to all your attacking Allies. Since they were an Ally themselves, they accomplished something even when attacking alone, but they were better in a deck with more Allies.
Some mechanics work wonderfully in design but start to fall apart as the developers begin stress-testing them. Design had liked how the attack trigger played into the themes of the rebels fighting back, but the gameplay ended up being a little too monotonous. All Ally decks had one style of play: aggressively attacking. We wanted that to be one option, but not the only one.
Development ended up going back to one of the original mechanics of the Allies: the one we had called the "clerics." These are Allies that grant an ability to your Allies whenever an Ally you control enters the battlefield. Erik tweaked it, though, to make it a little less punishing to decks without lots of Allies. Instead of granting an ability to your Allies, the mechanic grants an ability to all of your creatures. This allows you to play a deck with a few Allies in something like Limited, where it's hard to completely fill your deck up with them. This mechanic ended up being called rally.
"Land matters" would be a theme of some kind.
While the creatures were definitely some of Zendikar's biggest defenders, they weren't the only ones. Zendikar itself was going to be part of the battle. We wanted to make a mechanic that helped show the land itself fighting back. We eventually settled on awaken (called "animus" in design), an ability that went on spells and allowed you to pay extra mana to permanently animate a land. The reason the ability ended up on spells was that most of our other mechanics were going on permanents, and we wanted something we could use on spells.
The original version of the mechanic turned a land into a 2/2. When that didn't prove to be enough, design changed it to a 3/3. In development, the call was made to make it a variable number. This added some complexity, but it gave development an important knob to be able to balance the mechanic and also allowed a wider range of design space of cards that could be created.
The set would also have numerous other land-related designs. We made a new cycle of rare dual lands with basic land types to play with fetch lands in Standard. We made a new cycle of "spell lands" that enter the battlefield tapped but have an enter-the-battlefield effect. We even started an enemy cycle of lands that can animate themselves, following in the footsteps of the ally land cycle in Worldwake.
My preview card doesn't technically have awaken, but it's pretty close—so this seems like a good time to show it off. It's also a legendary creature and an Ally.
Meet Noyan Dar, Roil Shaper.
My memory of this card is it started as a nonlegendary creature, and when we got a list of the characters out of which to make legendary creatures, we went, "Oh, we already have one for this guy."
We'd have to create some contrast between the Zendikari and the Eldrazi.
Design played around with a number of different ideas, but it was development that found the answer to this issue. If the Eldrazi cared about colorlessness, then the Zendikari were going to care about color. The converge mechanic was made in the spirit of the (unnamed) domain mechanic from Invasion block. The spells with converge create a scaling effect based upon the number of different colored mana spent to cast the spell. As one colored mana is required to play it, the spells always do something. This mechanic allows a very different drafting strategy for those wanting to try something else.
Landfall, rally, awaken, and converge gave us plenty for the Zendikari side to focus on.
One Last Thing
Before I wrap up for today, I do want to answer one pressing question. A recurring theme you'll see through this and last week's articles is how often things were changed in development. Spawn turned into Scions. Ingest and Processors were made. Awaken became variable. Converge was added. Why such an excess of changes in development?
The answer is that we decided to swap from the three-set block model to a two-set block model in the middle of the design of Battle for Zendikar. During most of that time, Standard rotation hadn't changed—so we were trying to figure out how to keep Standard from increasing in complexity, and the only answer at the time seemed to be bringing down the complexity of each individual set. That meant I was trying to solve a very complex problem while keeping one hand tied behind my back, and the result is that the set didn't get handed over as complete as I would have liked.
Erik and his development team stepped up though, and did amazing work finishing off the design and turning it into the exciting set you all are going to get to play very soon. Also, with the rotation changing in Standard from two years to eighteen months, that meant that not only did we not have to go down in complexity per set, but we could even go up a little.
Let the Battle Commence
And that, in a little over six thousand words, is how Battle for Zendikar came to be. The set is packed full of all sorts of cool stuff, so I'm very excited to see what you all think of it. Please feel free to email me or talk to me through any of my social media (Tumblr, Twitter, Google+, and Instagram) with your opinions on both the set and today (and last week's columns).
Join me next week, when I start going through some card-by-card stories from the design of Battle for Zendikar.
Until then, may you save Zendikar, or doom it—your choice.
"Drive to Work #260—10 Things Every Game Needs – Fun"
This is the eighth podcast in my "10 Things Every Game Needs" series. In this episode, I talk all about the importance of fun in your game.
"Drive to Work #261—Khans of Tarkir, Part 6"
This is the sixth part of my seven-part series on the design of Khans of Tarkir.