Thursday, October 22, 2015

Tesla: Make Common Cause

This article is WotC safe.
Hello again everyone! Last time, the Tesla Project forum debuted, where the discussion from Our Refinery has continued nicely. Over the past week, alongside discussing proposals and alterations for the candidate mechanics, many of us have begun to design example commons for the mechanics - which leads directly into our topic for this week, designing commons for playtesting our mechanics.

Common Cause by Raymond Swanland
To understand how to design good example commons for mechanics, we must first understand why we're designing these cards. This is the first step to any successful design, really - what is this design for? As Mark Rosewater has said, "Either commons are basic cards needed to make the game work and keep it comprehensible, or they are filling in the essence of the set. Ideally as many cards as possible do both, but plenty of cards fill one of the two roles." However, we have an additional goal - to create commons that properly put our mechanics through their paces.

First and foremost, commons are meant to be representative. In terms of a set as a whole, this means we design commons to portray the themes and mechanics of the set - "they are filling in the essence of the set". In terms of designing example commons for mechanics, their goal is to showcase how the mechanic is meant to be used and played. The commons we design should represent the mechanic as it would actually exist. This goal is what leads to cards like Groundswell, Galvanic Blast, and Clutch of Currents—these are the kinds of cards that 'every set' has, and the ones we naturally tend towards. Designing representative commons is important, because it pushes us to find out how far we can stretch the mechanic before we have to tread into unfamiliar and strange territory.  When testing these cards, our goal is to see whether they feel natural and play well. If we can't make enough fun 'normal' designs with a mechanic, it could pose problems.

In addition, we want elegant and simple commons.  For all commons, the goal is to keep things relatively simple, because "commons are basic cards needed to make the game work and keep it comprehensible". This is especially true for mechanics, as they tend towards the complex. In addition, such commons serve as our 'control variables', letting us see exactly how much the mechanic offers on its own. Therefore, for our purposes, 'elegant and simple' means it features the new mechanic and nothing else - cards like Servant of Nefarox, Jeskai Windscout, and Eyes in the Skies are the best examples of cards like this. When testing such cards, we must ask ourselves: Is the mechanic interesting enough to pull a card on its own? How well does the mechanic play if it has no other 'intrigue' to it besides its own merit? Another important factor these designs test is whether our mechanic can possibly appear on a card without being red-flagged. If every card with your mechanic ends up red-flagged, that's an issue that needs to be addressed. A set can only support so many red-flagged commons before it becomes a problem, and if multiple mechanics automatically cause cards to be red-flagged, we'll run out of breathing room, fast. I'll refer to Reuben Covington's excellent guide on red-flagging and New World Order, rather than poorly repeat it in my own words. This is the hardest of the goals, in my opinion, as it's far easier to add to a card than it is to subtract.

Lastly, though representative and simple commons are important, an important goal exclusive to our example commons is to be innovative and experimental. Our goal is to test the mechanic, which means not only seeing how 'normal' and 'simple' it can be, but to give it a stress test as well - to test it in both directions. How complex can our mechanic be at common before it's too complex? What kind of unique and exciting effects is our mechanic capable of at common? What does our mechanic bring to the table that nothing else does? And, importantly, do these complex / experimental designs remain fun?

Now that we've identified our three goals, let's go over some tips for designing good example commons.

  • First off, before designing any commons, think over your mechanics and identify the following: What does the mechanic bring to the table that's new? What does it do best? What playstyle and kind of card does it shine on? What are its weaknesses?
  • For designing representative commons, identify the 'usual suspects' of a set. Red gets a burn spell at common, blue gets a card draw spell, black a removal spell, and so on. Once you have a list of these 'basic' cards, use what we've found our mechanic to be good at, and staple these uses to the most complementary effects. For example, Scry was used on designs like Scouring Sands and Lost in a Labyrinth, in order to give some less-played 'usual suspects' a bit more utility.
  • For designing simple and elegant commons, the key is (once again) to pair your mechanic with the most complementary effects. For example, Renown pushes people to attack - so it appears on cards that explore the many ways one can attack. Immediately, evasively, keeping up defenses, discouraging blocks, and so on. Notice that, though Renown is a mechanic that pushes for aggression, it doesn't appear on entirely aggressive designs! Sometimes a 'complementary' effect compensates for a mechanic's weaknesses rather than focusing single-mindedly on its strengths. Finding variety in simple and elegant designs is vital.
  • For designing innovative and experimental designs, the idea is to identify the 'least upper bound' of complexity. What's the weirdest thing we can do with this mechanic at common, do you think? Earthen Arms is a wonderful example, as its pieces are very simple, but altogether it makes for a surprisingly complicated card. Do you stack all the counters on one land you previously Awakened? Do you Awaken another land, and put the counters on a third creature? And so on. Again, as we've identified what our mechanic does best and does interestingly, we explore those uses as much as we can.
Overall, we've got a solid start towards designing example commons for mechanics - yet one more question remains. After we've designed our commons... what next? We'll have a bunch of nice common designs, but many of a mechanic's possible problems - such as complexity issues, and how well it plays - can't be seen just by reading a card, but must be felt by experiencing it. For example, there is an entire category of mechanics, which includes Exalted and Unleash, that read poorly but play very well. Without playtesting mechanics like this, their merits would never be found!

Yet we have a problem. We have a bunch of commons, but we do not have a set. This presents us two significant—and separate—problems: we only have our mechanic-example commons, and we don't have an actual set to test how the mechanic works in Limited. What do we do?

In regards to the first, Mark Rosewater said it best in Nuts & Bolts: Initial Playtesting: "What was filling in the non-mechanic slots for the initial playtests? The answer is basic cards. Until you have a good handle on what your set is doing, basic cards serve well both to allow you to play and to let the new parts of the set take focus." This is an extension of the idea that a good test has controlled variables. We want the rest of the format to be as simple and straightforward and proven as possible, to ensure that the only variables affecting our results are the mechanics themselves.

The second question has a lot of possible solutions, and I'll present just a few. For one, we can take a similar approach to how we solved the last problem - we can exchange cards in a 'normal' format with our cards we wish to test. Just like we did in the initial Tesla playtests, we can start with a simple and proven format, and see how our mechanics affect it. I recommend turning to a core set - since we're designing cards that replace 'simple' and 'representative' commons, it's easiest to find such cards in a core set, where 90% of the commons are just that. This is important because it lets us test aspects of mechanics that are relevant only to Sealed. For example, if we were playtesting Allies or Slivers, we would obviously be interested in how the archetype plays in Limited. In Tesla, we have the same concern with Mecha.

Another way to test Limited, though a bit weird, is to play Winchester or Solomon draft with a preset selection of cards. This lets you tune your cardpool to test exactly what you want it to, while still capturing much of the same 'pick order' and Limited feel that you might be looking for.

Besides testing Limited, one can make simple Constructed decks to test mechanics. Reuben Covington is a huge proponent for testing with Duel Deck style construction, where each deck focuses on a mechanic to playtest it in a focused manner. For example, he designed a Duel Deck for "Access the Machine" long ago, to see how well it played in practice - and in doing so discovered numerous valuable insights about the mechanic, which has inspired much of the progress we've made on the mechanic. One can also make 'mini-decks', like the free sample decks Magic has handed out in the past, to see more of the cards more consistently.

Before we wrap up today, here's my last few notes:
  • When designing example commons, take notes on your goals for each card. Compare the goals of the cards to how well they do in playtesting, and to the comments of other designers when you share your example commons.
  • When playtesting, be sure to take notes! And ask the playtesters, including yourself, to write down any thoughts that come to mind and how they felt after they played.
  • Find a wide range of skill levels and psychographics! As designers, many of us understand Magic-ese well, and know how the game works. Talk to your friends, significant others, and family members, and see if any would be willing to give Magic a try, or to try out playtesting. We want as diverse a range of people as we can - Spikes, Jennies, Tammies, LSPs, veterans, and casual players. 
The big push now is to not only make more commons for our mechanics, but to start testing these mechanics in practice rather than just in our heads. I'm really loving the cards we've all been producing, and the insightful conversations we've been having, over at the forums. Hopefully we'll start seeing some playtest reports soon!

Have a great week, everybody.


  1. My playtest recommendations: If you're playtesting a single particular mechanic to put it through the ringer, I wouldn't do a full-on limited playtest to do it. Make ten commons with the mechanic in whatever colors are appropriate, simulate 4-5 other packs of Origins, cut out the rares and uncommons, and build a limited deck. Repeat for a second deck.

    1. Agreed, for the most part. I do think we'll want to be playtesting drafting mechanics like Mecha, but you're right, that's not exactly the correct move for this early on.

    2. Nice write-up!

      In GDS2, when all the commons of a single color were submitted, they simply put two of each in a deck with basic lands and got to work. That won't play like a normal format, but it's plenty to show you what works and what doesn't.

      We could simply take all the commons for one mechanic, fill out with some core set staples, double if necessary, and go. Alternately, take any two mechanics and make a deck of those.

      More advanced set-ups will be important soon, but may be wasted effort this early.

  2. Is there a list of Tesla cards and mechanics?

    1. I don't think there's a definitive list of cards anywhere, but you can use the side-nav (Tesla, under Projects) to find the entire history of the set. There's also a forum (linked at the beginning of this article) where people are discussing the mechanics currently under consideration.

  3. This past weekend I actually assembled a 101 playtest pool in the hopes of trying things out this coming weekend. Should I put the card list and playtest notes in the set overview section of the Forum? I don't know practically how we are going to track all the potential playtesting.