when I get to California, I’m gonna write my name in the sand

I’ve been really into using brute force Monte Carlo simulation to find hand distributions in Magic lately. It started because I wasn’t sure how aggressively I was supposed to mulligan when I was testing Eldrazi Tron. The difference between Eldrazi Tron’s best hands and even its average hands is so massive that it’s usually worth giving up a card to try to find a broken start, but I wasn’t sure what to do with borderline hands that were only missing a piece or two. Like, what are you supposed to do with this hand, on the draw?





If this hand finds Urza’s Tower, Expedition Map, Chalice of the Void, Mind Stone, or Eldrazi Temple on its first two draw steps, it’s an good hand. Map on turn two is a little slow, but it’s still turn 3 Tron with a Reshaper. Even if the hand bricks twice, a Tower or Temple on turn 3 would still represent a great draw. That’s 18 outs twice and then 8 outs once: a 63.59% chance of a solid hand. Those odds aren’t perfect, but is it really worth spending a card to try to improve?

What about this hand, on the play?





This hand is drawing to Chalice of the Void and Mind Stone in one draw step or Urza’s Mine and Eldrazi Temple in two draw steps, plus the scry. So this hand has a 40.93% chance to get there. Again, not perfect, I didn’t think the chances of a great hand on 5 cards could have been that high either.

Rather than guessing and stumbling into an intuition for these hands, I figured I’d rather just know:





The numbers are the top of this table are the number of cards seen in a game. So 7 represents a 7 card hand as well as 6 cards and a scry. So the probability of a broken hand after mulliganning once is 63.85% and after mulliganing twice is 50.66%. Following the table, it’s clear we should mulligan both of these hands. With the first hand, we only slightly improve our chances of having a good draw on the first mulligan but we give ourselves the opportunity to mulligan again if we miss, which is an additional 18% equity.

I was surprised by these results. Before simulating, I was sure the first hand was a keep and that the results would just confirm my intuition. With any other deck in Magic, I would never mulligan a 63% shot at one of my best draws unless the consequences of bricking were catastrophic. But Eldrazi Tron features so many broken draws and its spells are so individually impactful that here it’s just correct.

These results also indicated that Eldrazi Tron was much more consistent than I thought it was. I had always assumed Eldrazi Tron was a cheesy deck that needed to get lucky to win. But honestly, it’s really unlucky if the deck doesn’t produce a broken draw: if you’re willing to mulligan to 5 looking for a great hand, you’ll get one over 90% of the time. (Note here that the table doesn’t consider that you functionally see 7 cards twice with the Vancouver mulligan rule.)

In addition, notice how dramatically the Vancouver mulligan rule strengthens the Eldrazi Tron deck. With the Paris mulligan, both of the hands above would have been clear keeps, and between them the Eldrazi Tron deck would have had upwards of 30% fewer broken draws.

Do note that I defined my five classes of “broken” hand pretty liberally. I asked Eldrazi Tron master Collin Rountree what kinds of hands he would always keep, and it boiled down to these: hands featuring Tron, hands that could cast an Eldrazi on turn 2 or 3, and hands with Chalice. Some hands in these classes will be weaker, some much stronger. Overall though, I think Collin’s heuristic is quite good. Also note that this simulation doesn’t take into account the equity of hands that don’t quite get there but you’d likely keep anyway on 5 cards, and it functionally assumes you know your top card when mulliganning with a scry. However, these effects somewhat counterbalance each other, and even trying to account for them would make the simulation exceedingly complicated.

After that, since I’d written this whole framework, I explored some other applications. The first was how many 0-drops to play in Affinity:





Starting from a standard Affinity deck and varying the numbers of Memnite, Welding Jar, and Galvanic Blast, we can see that each Memnite you play gives you an additional 1.2/1.8% chance of casting a 2-drop on turn 1 on the play/draw and each Welding Jar you play gives you an additional 1.1/1.4%.

These results were also surprising to me, even though I’ve played Affinity for a long time. Firstly, I didn’t expect the chances of having 2-mana on turn 1 to be quite so high. I always felt exceedingly fortunate when I got a draw that good, but now I realize the deck is even stronger than I thought it was. (And I liked it a great deal already.)

But secondly, and perhaps more operatively, I didn’t expect the impact of additional Memnites and Welding Jars to be so similar. I’d always assumed that Memnites were critical because they could operate Springleaf Drum, but apparently that isn’t particularly relevant for having 2 mana on turn 1. Welding Jar has a lot more utility, and I think I should have been playing more of them the whole time.

Granted, there are other considerations than casting 2-drops ahead of schedule. Memnite considerably increases your chances of casting a 3-drop on turn 2, for example. At the same time, I think the chance of casting a 2-drop on turn 1 is reasonable proxy for the general explosiveness and consistency of the deck.

While writing this script, I also realized just how many more combinations of cards cast a 3-drop on turn 2 than cast a 2-drop on turn 1. It was so many that I couldn’t be confident I’d enumerated all of them, and that made me think that I should also have been playing more 3-drops as well, like Makis Matsoukas did at the last Pro Tour.

Lastly, I tried to figure out the optimal manabase for Grixis Energy in standard for my friends playing GP Memphis:





Firstly, I just figured out the chances of each checkland coming into play tapped (and of all checklands in a hand coming into being tapped) in a typical manabase. The results suggested to me that most Grixis Energy lists were playing too many checklands and too few cyclelands to enable them. Then, out of curiosity, I decided to iterate over every possible combination of the lands in the deck and try to find the optimal manabase:





These results ultimately weren’t very interesting, and in retrospect I shouldn’t have expected much. I was curious what would happen if I “penalized” tapped checklands and drawing cyclelands similarly, to minimize the number of tapped lands in the deck overall while maximizing access to colored mana based on the relative representations of colored symbols in the deck’s spells. But most of the terms in that utility/loss function are just closed-form hypergeometric expectations that say to play a lot of dual lands, so most of the land slots were mathematically locked.

Still, after tuning the parameters to find the decision boundary, the final proportion of cyclelands and basics to checklands was interesting. Averaging over the best configurations, my program generally played 6 basics, 7 cyclelands, and only 4 checklands. This suggested that checklands are much, much less consistent than people give them credit for being, and people should play them much less. And to an extent, I think we saw these results borne out in practice last weekend at GP Memphis. Every high-finishing Grixis Energy deck save Matthew Kling’s featured at least as many cyclelands (or Evolving Wilds) as checklands, and even Matthew played 7 cyclelands to his 8 checks.

Two failings of my utility function are that it didn’t prioritize untapped mana later in the game for Scarab God more highly than untapped mana early and it didn’t weigh having access to all 3 colors at once in addition to having the right proportions of each. In practice, players played more checklands and fewer basics than my algorithm suggested, which makes sense. Checklands mostly come into play untapped when you really need untapped mana and too many basics make the mana much shakier. Still, I suspect most of these top lists should have had at least one more basic.

Ultimately, I’m not sure how practical or interesting these simulations really are. But I’ve gotten some cool and surprising results after even these few preliminary analyses, and it just seems like a basic thing that almost nobody does. Anyway, hopefully you’ve enjoyed reading this. I actually really enjoyed writing it.

If you’d like to vet my logic or try a simulation of your own, you can download my code here: https://github.com/nalkpas/hand-simulator

Until next time. (Hopefully not another 5 months from now.)