When I see players jamming games in between rounds at the Local Game Store and they tell me they're playtesting, I'm deeply skeptical. I don't doubt that they're learning something by playing games. In fact, it'd be alarming if that wasn't happening. However, playing games isn't the same thing as actually testing. It's an important component, to be sure, but actual testing is closer to work than play. Testing is an act of active learning. Just playing games is passive learning at best.

If this sounds rather familiar, that's good. It means that you read last week's article. This is a direct continuation of that discussion. Once a deck has been put through enough goldfishing to ensure that it actually works and the pilot is minimally competent, then it's time to actually playtest the deck. This requires playing actual games but isn't just playing games. Players looking to test for tournaments and develop need to get serious about testing. This involves actual work.

Active Learning vs Passive Learning

When I said testing is active learning while just playing is passive learning, readers in the education field almost certainly took up arms over said terms. Everyone else was just confused. How can actually playing games be passive, and why isn't that ok? To the first group: Chill, this isn't about the academic debate. To the latter, it's not an either-or thing. Both active and passive learning have their uses, but players need to be aware of what they're doing to maximize testing efficiency and results.

To simplify the linked Wikipedia articles, active learning requires students to be actively involved in teaching themselves while passive just requires them to absorb information. This probably sounds contradictory, but the way most players playtest is very passive. They sit down, play some games, and intend to absorb the lessons the match gives them. There's nothing inherently wrong with that.

However, it does mean that the lessons that can be learned from this are dependent on the random chance inherent in the games. Whatever happens, happens, and thus whatever lessons happen, happens. If a player wants to learn something specific, they cannot rely on passively waiting for it to happen. Take an active role and set up to learn what needs to be learned.

Test Scenarios

Case in point, at the end of last week's article, I said that if there is something specific that needs to be tested, then test it. Just test it. Set up the scenario that you want to test rather than passively waiting for it to happen organically in-game. Waiting for it to happen "naturally" is passive learning. It's hoping that the relevant information will come and also stick. Setting up what specifically needs to be tested is active learning and needs to happen too.

Players are, in my experience, perfectly fine passively learning via playing games and seeing what happens. However, if I tell them to set up the exact circumstances they want to test, they balk. The justification for said resistance is always some variant of "it's not natural." The feeling is that only data from games is valid. This is wrong.

If something is worth wondering about, it's worth understanding. When that question lingers despite repeated test games, it obviously doesn't come up enough to definitively answer in normal games. Therefore, the only way to see it enough is to force the scenario to happen. Doing anything else is just wasting time.

I'm not saying that playing a game normally as part of testing isn't useful. I am saying that doing so is insufficient and players need to take more agency during testing. Especially more intense, tournament-focused testing.

Testing the Hard Way

From my experience, most players are very lackadaisical towards testing. Even serious players would rather treat testing as hanging out time, with most of the learning coming via post-mortem dissection. Which I do, absolutely and unequivocally, understand. Hanging out with friends is far more enjoyable than actually working. However, for players like me, it is necessary to break out of that mindset.

I have a lot of ambition as a Magic player. I want to win, keep winning, and win at the highest level. However, I don't have the natural talent and luck that help the best players make it look easy. I've seen plenty of them do exactly that, and envy is but the tip of my ensuing emotional iceberg. No, if I want to do well, I need to work for it. Hard.

Which is exactly what I did at the grindiest time in my life. In 2014-2015, grinding Magic was my job. I was traveling to every event I could, testing as much as possible, and playing as much as finances and travel time allowed. I cashed more tournaments in that period than the rest of my life, probably combined. It paid off when I made it to Pro Tour Khans of Tarkir, making Day 2 of my first and so far only Pro Tour.

Which I should mention, was despite all my drafts going horribly awry and my Jeskai deck being suboptimal. I could never figure out the right top end and just split the difference having run out of time. However, the work I'd put into testing everything beforehand let me sufficiently navigate past my shortcomings to kinda-almost-get there anyway. Here's the system I had then, parts of which I still use despite not having time for all of it anymore.

Step 1: Change Testing Tools

The biggest suggestion I can make is to not test with actual Magic cards. Use universal proxies instead. I know that sounds weird, but there are two reasons not to test with the actual deck. The first is purely financial as it saves wear and tear on real cards and sleeves. Yes, I really was that big of a penny-pincher once. However, it also forces players to think harder about the game and to actually understand their cards.

Universal Proxies

The first thing is to make universal proxies. Normally, when players make proxies they Sharpie lands with enough information to identify a specific card. Instead, make proxies that could be any card:

Step 1: Make a grid. It should have four columns and enough rows for the number of cards in the test deck. For a 60-card deck, that means a 4 x 15 grid.

Step 2: Proxy enough lands so that each one corresponds to one of the boxes in the grid. Mark them only with the grid coordinate, i.e. A1, G3, D4. No jokes about battleships or the sinking thereof. I've already made them all. Sleeving is optional, but I'd only use otherwise busted-up non-tournament usable sleeves. Pinching pennies and all that.

Step 3: Fill in the grid. Each row should contain as many of the same cards as possible. For example, if a deck plays four Ponder, then B1, B2, B3, and B4 should all be Ponder. If it's only two, then B3 and B4 and fill in B1 and B2 with a different two-of. Don't mix and match, it makes it hard to keep track of everything. The order of the cards doesn't matter, feel free to input the cards in whatever order makes sense.

Step 4: Repeat the process for everyone involved in testing.

Step 5: Have the Oracle text for each card available, either via Scryfall or Gatherer.

Why Proxies?

I'll preface that I didn't come up with this idea. The original idea came from a Star City Games article from years ago. There's no link because I don't remember who wrote it or the name and my Google-fu wasn't strong enough to find it again. I have refined that idea heavily so that it's not really recognizable anymore, but I always cite my sources.

Anyway, the purpose behind these proxies is to break familiarity with the cards. So many players play their cards on autopilot without really thinking about the cards themselves. At some point, everyone gets more used to playing (and even seeing) their card as they remember it being used. I know what Lightning Bolt does, I don't need to read the card. For simple cards that might be true. However, I've watched players misplay their cards so often by adding or subtracting functionality that this is a serious concern.

Playing with proxies breaks that familiarity because to know what a card does requires looking at the grid for identification, then to the Oracle for what it does. It retrains the brain away from what it thinks a card does to what it actually does.

Also, it speeds up testing in the long run. When finished testing one deck, grab another deck grid instead of making another. Rather than physically replacing cards during deck refinement, just change the grid. It saves a lot of time fiddling around with cards.

Playing With Proxies

Of course, in the short run using just proxy decks will be awkward. Getting used to looking up the cards will slow players down for the first few iterations. However, it gets much easier over time.

Playing with the proxies is no different than playing with actual cards. It just requires checking the grid to see what the cards are. Where it gets weird is that the first time that any non-basic land card is played, the player must read out loud the full and unabridged Oracle text. This is essential so that every player knows what's happening and is key to the retraining bit from above. Subsequent plays don't need to be read out in full but repeat this process for every game. Not match, game.

Additionally, any time there is any question about a card, read out the full Oracle text. No cutting corners, no assumptions, just hard data.

Step 2: Record Everything

I do mean everything. Every decision made and why, every observation and thought, wins and losses, and every single data point should be recorded for dissection and discussion afterward. It's best to write them down so as to keep the opponent in the dark, but do whatever works.

Also, record the game in video form. This will be a lot easier for anyone today because phone cameras actually work now and are good. Back in 2014, I was fiddling with a full digital camera that didn't like to focus. Today's webcams and smartphones are vastly superior. It's critical to record every play and every single card drawn in a match and the order in which they were drawn for the purpose of Step 3b.

Step 3a: Play Matches

With the test decks built, now start playing the test matches. For the first few, play typical Magic matches, but play them to their conclusion. Don't concede, don't assume defeat or victory. Play until someone actually loses. Hard locks are an acceptable win. There are many ways that a match can turn around. Use testing to look for those opportunities.

On that note, play all three games in a match. Even if one deck just blows the other out convincingly in two, play the third one anyway. There's value in playing as many individual games as possible, but more importantly, more game threes mean more opportunity to test sideboards, which are often undertested relative to the maindeck.

After some number of standard matches, stop playing normal games and start the hard testing. How many matches depend on the player, I usually play 10-20. The purpose of the typical matches is to learn how the match works, which cards matter and why, and if the sideboard strategy is appropriate. Once there's a reasonable answer established, it's time to start digging in.

Step 3b: Replay Matches

Did the match hinge on a certain decision, or was a mistake critical? Back the game up to that point and find out. Use the recording to rebuild the boardstate to that moment, with the right cards in each player's hand, and try the game again. Put the cards back in the exact order that they were drawn. Or even separate them from the deck and just draw from the pile until the whole library needs to be shuffled.

This allows players to really dissect their decisions and get into how valid their instincts were and refine them. It's possible that the decision didn't really matter, and defeat was inevitable from that position. If that's the case, then finding out and subsequently determining if the original line was best is very useful. If there was a better option, how obvious was it originally, and how can it be found more easily in the future?

I don't know how useful it actually is, but back in 2014, I'd also insist on backing games up all the way to the beginning and switching who was on the play vs the draw. Many games will play out very differently and there can be insights to be gained, but many hands are unkeepable on the play vs the draw. It feels like doing this would be useful, but I've never been sure.

Step 4: Test Scenarios

For all the reasons already stated, test scenarios. The rest of the testing up until now should have identified corner cases, specific interactions, sequencing lines, and other interesting data that should be looked into. Set them up and then dissect them. There's something there worth learning. Find it.

Step 5: Analyze and Adjust

This is the really critical part. Up until now, the decks shouldn't have changed from the first match. The whole plan was to test that deck, and only now is there the data to know if it works and what must be changed. Analyze that data and make changes accordingly. This is where having the decks just be Excel spreadsheets is very convenient. Once the chosen adjustments are made:

Step 6: Once Again, From the Top

Now return to Step 3 and do it all again with the adjusted deck. Don't forget to update every other deck, too. I said at the beginning it's hard work. However, I stand by the results it brought me.

Not For Everyone

While the whole thing requires a level of commitment only the most dedicated grinders can match, using proxy decks and testing scenarios is useful for almost everyone and easy to adopt. For players looking to improve and who feel their skill is plateauing, my system can make up for skill deficiencies with pure practice and knowledge.