torsdag 25 augusti 2016

Continuous deckbuilding

A couple of years back, I held an impromptu seminar on the Nash equilibrium. For those of you unfamiliar, it's a solution concept in a branch of mathematics called game theory; the thing Russel Crowe's character in A Beatiful Mind gets a prize for at the end of the movie. It’s also a fairly unfriendly and complex topic far removed from the line of work of the audience I presented it to.
Off the bat with a subtle Nash equilibrium / Magic card reference. This can only be good, right?
I wanted to test the waters. See how well I could handle a talk about a topic most people weren't a priori interested in; a topic which the audience had little prior knowledge about nor practical use for. I guess it went well enough; no one threw their underwear on the stage, but on the other hand, no one threw their underwear on the stage.

I’ve been thinking about this topic for a while. About building things.
// Here be Dragons
Now, what I do for a living other than ski boxing and screaming at trains, is IT consulting. I have a few reasonably tuned strings on that harp, with my main focus on testing and release management. The IT industry has changed a lot since back in the old school days of 93/94. Back then, it was somewhat feasible for a programmer to write a game or a fairly high-end program for public consumption and understand most of everything about how it worked. Go back another decade or so, and we're at a time when it wasn’t that uncommon for a single developer to write all parts of game - from music and story to game play dynamics and logic - often knowing exactly what part of the code used which parts of the machine's memory registers.
That's how you get Easter Eggs like this I suppose.
This is really not case anymore. Though we have much better tools to works with today, creating and releasing a major product is complex. I could write about how Knight Capital Holdings lost $465 million in 45 minutes because they failed to deploy new production code to their eighth server. Or mention how healthcare.gov wasn’t built to handle the proper load and prompted President Obama to issue an apology from the White House Rose Garden on US national television. Or just listen to people playing Magic Online complaining about buggy software until they threaten to ragequit over to Hearthstone.
Ain't easy being Worth.
But let’s leave that for some listicle to handle. Today, we go deep nerd. We’re going to look at how to create and deploy working software. Creating software is not unlike creating a Magic deck, so let's take the tools we use to build software and use them to build a deck instead. It’s old school Magic and software development processes in a ghastly topical blend. Buckle up mofos!
Of course we will.

Why?

Step one. Why? ”Always start with why.

Why do we want to build this deck? In a larger context, this could be defined as an epic; essentially a large user story that can be broken down to a number of smaller user stories. A user story is one (or a few) sentences written in everyday language that captures the ”who”, ”what”, and ”why” of a project; in this case the deck. It is most commonly defined as ”As a <role>, I want <goal>, so that <benefit>”.

As an Old School Mtg player who enjoys trying different strategies, I want to build a monored Sligh deck, so that I can play it with friends and lend it out during tournaments.

As a Netflix user, I want to be able to resume a program I’ve previously watched, so that I won’t have to search the buffer whenever I return to a program.

As a Vintage player, I want a deck that have a favorable matchup against the most popular decks in the current meta, so that I can win tournaments with it.
Solid choice two years ago, but doesn't beat Mentors nor Eldrazis today.
This may sound like a no-brainer, but it is really not the case. People rarely think about why they do things. Why does Magic Online have an interface that many describe as unfriendly? Is it because we haven’t thought about who the intended user is? What’s the goal for the product in one setting? What would it be in five?

I’ve worked at a lot of projects where employees - certainly including myself - can’t explain exactly what that the product is. Or at the very least, we have different ideas of what it is, and what words mean. We need to find a common language and a common model everybody understands. As a smarter man than myself said, ”The worst bugs, the major technical debt, are mostly modelling errors”.
It will get worse over time.
What is a Magic card? If you work with software that use Magic cards - be it MTGO, TCGplayer, Gatherer search or whatever - there should probably only be one answer to that question. Both technical and domain experts in the project should understand it. Looking at it from a domain driven design (DDD) viewpoint, it’s probably a collection of objects (value objects and entities) bound together by a root entity.

The values objects and entities of a card will be different for different products. If we go to morphling.de to check out Vintage decks, those lists don’t care what edition the cards are from or what their rarity is. If we search for a card at the ChannelFireball store, those cards wouldn't need to store specific rule FAQs for the card (like they do at Gatherer search). And if we play a card in the Duel of the Planeswalkers app, that card doesn’t care about its real life prize tag, but cares a lot about how the card interacts in an actual game of Magic.

Knowing the components we work with will eventually save us time and a help us avoid a myriad of bugs and refactoring. If we neither know why we do something nor what it is that we do, we’re in for a hard time down the road.
A Sorrow's Path, if you will.

Requirements

Let’s say we’ve reached a basic idea overview of the who, why, and what. Let’s build that Sligh deck I’ve been thinking about for a couple of months.

As an Old School Mtg player who enjoys trying different strategies, I want to build a monored Sligh deck, so that I can play it with friends and lend it out during tournaments.

That’s our epic user story. This story will then be broken down in smaller tasks with unambiguous requirements.

Software requirements can go deep, easily becoming a faceless set of rules no one at the team really cares about. On the other side of the coin, we might skip the requirements all together, or make them fluffy rants of uselessness that can’t reasonably be verified without bias (”The deck should be good”).

IEEE (Institute of Electrical and Electronics Engineers) define a requirements as
  1. A condition or capability needed by a user to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
  3. A documented representation of a condition or capability as in 1 or 2.
Yep. I will also humbly note that IEEE-830 defines Software Requirements Specifications, and that IEEE-829 defines Software Requirements as "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)."
Words and such. Here’s the deal though; when we’re creating something - anything - together, the requirements should be a collaboration tool.
Functional requirements!
Say that you and a couple of friends have decided to go on a road trip. When you meet up to talk about the trip, one of the friends has already booked all the hotels and pit stops, decided on which road to take, and booked you all in to The Gathering of the Juggalos at the end of the trip (yep, in this scenario you're friends with a juggalo). The guy then asks for your commitment and money to pay for your accommodations on the trip he planned.

The road trip now has a few feature requirements. Where to stay each night, where to travel, and what the end of the line will look like. This might make you feel less excited about the trip. It would probably be more enjoyable if you had collaborated with the requirements, in particular as you will commit a big part of your time to it. Maybe you know about a great bed and breakfast on the road that your friend didn’t even look up, or maybe you know a lot more about cars than your friend who already booked one. What if you don't care about magnets, and with a small detour you could have caught an unplugged session of Neurosis in addition to the Insane Clown Posse festival.
Everybody gets pitchforks.
When we talk about feature requirements in software development, I am a big fan of the Three Amigos approach. In a nutshell, it states that the requirements of the project should be written in collaboration between a feature developer, a tester, and someone with deep knowledge about the end user (e.g. a business analyst or designer). This gives us a more complete picture of the delivery, help us avoid a lot of communication problems down the road, and as a bonus increases the motivation and “ownership” of the end result. In many cases, we’ll also find out cheaper solutions to solve the problem, and squash a bunch of potential bugs already at the drawing board.

When we write the requirements, they should be unambiguous, testable and understandable for both technical and non-technical personnel. I think that it's a good idea to use some form of Gherkin syntax when writing requirements. It makes them easy to transform from plain text to testable code; using Cucumber, RBehave or similar tools. With Gherkin syntax, we write our requirements on Given-When-Then form. E.g. ”Given that I’m driving my car at crusing speed; When I press my foot on the break pedal; Then the car should slow down.”
It’s funny because this is kind of like a car and the banding ability is like collaboration.
If you are familiar with software development, you’ll recognize this as the first steps in Behaviour Driven Development (BDD), also known as Specification by Example. To let Dan North summarize the methodology: ”BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

Some requirements regarding the road trip are fairly unnecessary to state. At what time should you eat dinner each day? What color should the seats of the car have? These are either not pertinent to the experience of the trip, or will restrain your agility during it.

Let’s look at the very specific requirements that must be true for most every Magic deck. Things like

Given a constructed Magic deck,
When I count the number of cards in the main deck
Then that number must be at least 60

...and such. If we go deep enough, we see that the requirements could define things like what a Magic card even is (we don’t want to accidentally build a deck with Jack of Clubs or Charizad), or what constructed Magic is (”Hey, in 5-color you have to play like 300 cards!”, no one just screamed). But we are not trying to write Principia Mathematica here, we simply want to write requirements that makes sense to an end user. Testing of the smallest units of truth is done during the feature development part of the process (i.e. unit testing). What we're looking for here is something more like this:

Story: 93/94 Sligh deck
As an Old School Mtg player who enjoys trying different strategies
I want to build a monored Sligh deck
So that I can play it with friends and lend it out during tournaments

Scenario 1: We want to be able to lend the Sligh deck to other players in tournaments if we don't play it ourselves. As such, we want to have zero overlap between this deck and the Project M and Monogreen decks.
Given one player playing the Project M deck
And one player is playing the Monogreen deck
When one player is playing the Sligh deck
Then all decks should be fully constructed without proxies

Scenario 2: We have access to a decent card pool, and should be able to build a solid Sligh deck without spending too much additional money on the project.
Given we need to buy cards to finish the Sligh deck
When we calculate the total cost for acquiring the cards
Then that sum cannot be higher than $100

Hey! Did you actually read that? Is anyone still here? I assume that the two guys still reading are Bjørn-Einar Bjartnes (who shares my unhealthy joy of both software development and building Sligh decks), and Shaman Ben Perry (who could just enjoy the absurd nihilism of writing 26 pages of software development theory on a supposed Magic blog, laughing in the face of reason and clickbaits). You’ll get a deck list in about 2000 words. Also, I guess that Ydwen Efreet is a criminally undervalued card if you want to go do one of those new-fangled buyout thingies (NB: Please don’t buyout Ydwen Efreet).
Nothing like a picture of a wall of text to alleviate the monotony of a wall of text. Did some syntax highlighting though.
Those requirements in the picture are important to make sure that we actually make a Sligh deck. Those are still very much what we call functional requirements, and easily testable.

There are some other requirements we should note as well, called non-functional requirements. These requirements are used to judge the operation of our product, rather than specific behaviors. In software development, this could be the average response time of pressing a like-button at Facebook. The number of people whom could stream Stranger Things on Netflix without the video lagging for more than 1% of them. How frequently your Magic online client will crash. The most critical of the non-functional requirements are often referred to as the Key Performance Indicators (KPI) of the product.
If you like testing non-functional requirements, some stuff Netflix do is basically nerd porn.
Say that the best deck in 93/94 is U/R Burn (the most represented deck in Shark tournament top8s the last few years). If you want to build a deck that can beat U/R burn, it’s not that hard. You cram a bunch of life-gain, main deck circles of protection and cities in bottles, and build a pile that is solely made to make U/R Burn's life miserable. Being able to beat one deck is similar to only having to worry about a few hundred users. It's comparably not that hard to write a webpage that can handle a hundred or a few thousand users. But with each magnitude beyond that, you’ll face new problems. Writing an interactive webpage with millions or more daily users is a whole other bag of snakes.
This is deploying it to a larger market without load testing it. Obama doesn't approve.
Our non-functional requirements for the Sligh deck include that we should statistically win against a goldfish opponent at the latest turn seven with 14 out of 15 opening hands. On average, the winning turn should be before that. It says that we should deploy some interaction turn one at least 90% of our games. It says that we should have at least an X% chance of winning against deck Y.

Off to development

“About time to get that mo-fo'ing co-so of a deck. Why not just start here!?1” Because if we start here our twitter feed will become a peanut gallery of angry nerds, and we’ll lose a lot of revenue to Hearthstone due to buggy decks. Or some other analogy.

Your requirements should drive your implementation, not reflect it.

Just like a carpenter wouldn't grab a stack of wood and a hammer and start pounding away to build a chair, we can't just grab an IDE and swordfish away to build a webpage. If the chair were to be stable and fit with the rest of the furnishings, we need to first work out of what the finished product should look like. Write requirements on how to saw up the planks. Having documentation of the product and how to make it doesn't make the carpenter less of a craftsman. Give me and Ed Carpenter (real guy!) the exact same detailed instructions on how to make a chair, and I can assure you that Ed's will look better. Give Patrick Chapin and a random new player at the local FNM the same instructions to build a competitive standard deck, and Chapin will come out on top.
That is what happens when the brewmaster brew.
(Sidenote: It would be awesome to have Tha Gatherin playing a live session at n00bcon. Would anyone happen to know how much they would charge to play at a Swedish equivalence of Moe’s Tavern? Let my bidding start at $400 and a local couch to sleep on.)

The first step in building a 93/94 deck list may be to make sure that the deck is actually legal in the format.

TestIs9394MagicCard()
{
  foreach (card c in slighdeck)
  {
    Assert(contains(c, 9394LegalCards))
  }
}

TestNumberOfCardsInDeck()
{
  Assert(slighdeck.decksize() >= 60)
}

...and so on. These kind of tests are called unit tests. Unit tests are the lowest level of testing, verifying the smallest testable parts of the product. It’s written by developers in the same language as the feature code. In an ideal world, most every line of feature code have unit tests.

Starting with an empty deck list, of course all these tests will fail. But we write the tests firsts, and when they start passing we know that we're getting somewhere. Writing test before we start will actually speed up the development process a lot and help us avoid late surprises. The earlier we find the bugs, the cheaper they will be to fix.
Guess bugs are like Power in that aspect.
We want things to fail as soon as possible. Realizing our deck list only contains 59 cards is lot cheaper to fix before we place the order to buy the last cards. And it gets really expensive when we get disqualified presenting a 59-card deck just after they announced the top8 at our first Grand Prix.

As we want things to fail early, we could implement a few of the feature requirements already here as unit tests. Let’s write unit tests that check our mana curve. No need to wait until playtesting to see if we made mistakes in the theory.

TestNumberOfOneDropPermanents()
{
  Assert( (slighdeck.NumOfPermanentsWithManaCost(1) >= 8) && (slighdeck.NumOfPermanentsWithManacost(1) <= 13) )
}

We’ll do the same for all the examples in the feature requirements regarding mana costs and card types. Let’s write a deck list to make those tests green.
Make it green!
Now we enter the realm of creating solid decks. What separates the master carpenter from the novice woodcutter.

In deck building, current best practice is to approach the task with four sets of eyes. These are eerily similar to the best practices of creating software products.

I’m a big fan of George Baxter and the other pioneers in deck building theory from the 90s. But I think that the greatest contributor to the subject is Patrick Chapin. In his book Next Level Deckbuilding, he gives far deeper insight to the processes and art of deck building that I could ever hope to do here. In the book, Patrick defines the four paths as this:
  • Top-Down. What is there?
  • Bottom-Up. What is not there?
  • Forward. What’s the gameplan from turn one and forward?
  • Backward. How did we get to the winning position?
Top-Down. What's there? Good decks play good cards. We cannot entirely rely on mana curve with a complete disregard for card quality. Let’s start with adding 4 Lightning Bolts, 4 Chain Lightning, and 4 Mishra's Factory. As raw power level goes, we should heavily consider Blood Moon as a three-drop. We start here, and build around this.

If we're playing mono-red, we have access to a few powerful cards we can cast more easily than other decks. Ydwen Efreet is deceptively strong, and we will always have the right colored mana to cast Fork or Ball Lightning. Gauntlet of Might could pull a lot of weight here as well.

Bottom-Up. What's not there? What’s useless and inefficient? We might need to playtest to see this well, but we have a few hints already. The two-drops on the curve are sorely lacking. I wish I could play seven Ironclaw Orcs.
The powercreep these days...
Basically, the beatdown two-drops we get to choose from are Ironclaw Orcs, Atog, Kobold Taskmaster, Ank of Mishra, Copper Tablet, Goblin Rock Sled, or perhaps a one-off Raging River. Control-wise, we could add stuff like City in a Bottle, Fork, Shatter, and Chaos Orb. But we really want 6-8 ways to use our mana turn two aggressively. Maybe we could commit even more on one-drops to use all mana turn two. The lack of solid two-drops hurt, but it is not enough reason for us to pivot and scrap the deck.

What’s not there for our opponents? Life gain is lacking in the format. Apart from Mirror Universe and Ivory Tower, dealing damage here is basically the same as getting poison counters in the Modern format. You won't get rid of it. Ivory Tower and the red circle of protection could be an issue, but people don’t play those maindeck, and we should be able to race Mirror Universe. To handle the viable life gain alternatives, we should probably look to Manabarbs and Shatter/Detonate in the sideboard. Pyroclasm isn’t here. In the current meta, few or none play Moat or Wrath of God. This could help make the deck viable.

What else is not here? Looking at our requirements of not taking cards from our other assembled decks, we won’t play Mox Ruby, Black Lotus nor Library of Alexandria. Having a budget of less than $100 in new cards makes us unable to play Gauntlet of Might.
Might be that Dragon Whelp is a better 4-drop anyway...
Backwards. We burn out the opponent before they have the chance stabilize. We have zero cards in hand, and our lands are all tapped. This is round six or so. To get here, we have dealt at least 14 damage with creatures, and have a couple of burn spells to seal the deal. So the turn before that we attacked with a swarm of creatures, at least five damage. The creatures are small, so either we need evasion or to be able to destroy opposing Mishra's Factories. By turn six, opponent has had five land drops and drawn 13 cards, so we might need some disruption to get here.

If we have attacked for more than ten damage by turn five, we should have a lot of board presence turn four. Without moxen nor Lotus, everything above three-drops are curiosities. We'll only cast one or two four-drops before we win, so we don’t need many. Turn three we attack with two creatures. Hopefully a one-drop and a two drop. Could be two one-drops and a factory. Turn two we drop a threat or attack with a factory. Could also go for a one-drop creature and a bolt.

Forward: We need a land drop and threat turn one. If our land drop is Mishra’s Factory, it is much preferable to be able to use the mana than to not. Black Vise seems like an obvious include, maybe Brass Man as well? Turn two we attack with the Factory and our one-drop, or even better, play a two-drop. If we don’t have a factory, we need either two-drops or two one-drops to make our mana useful. Making our mana useless is how we lose, our cards are weak in a vacuum and we need tempo to win.
This might work.
I leave it as an exercise to the reader of examples of applying those rules to software development. But one concept is important enough to note in particular, what in Lean is called ”Acheiving Failure”. It affects deck lists, road trips, and software development.

As Eric Ries put it:

"We spend a lot of time planning. We even make contingency plans for what to do if the main plan goes wrong. But what if the plan goes right, and we still fail? This is the most dreaded kind of failure, because it tricks you into thinking that you’re in control and that you’re succeeding."
Forethought is 19/20.
We should always have focus on the actual value we're looking for. The product itself is secondary to the value of it; be it joy, profit or whatever. Here, the product is a monored 93/94 Sligh deck. The value is that we want to play it with friends and be able to lend it out during tournaments.

What if the deck is simply not competitive in the local market? What if a majority of the meta is Tax Edge with 4 maindeck Ivory Towers or Power Monolith combo? Then the value of lending it out during tournaments would be very slim as most anyone wouldn't be interested in borrowing it.

What if the deck is utterly unenjoyable for your friends and they don't want to play against it? Like if your play group enjoy casual kitchen table vintage, Duel Decks and such, and this one guy shows up with Draw-Go or Uba Stax. Sligh could possibly hit that point, as its game plan is to win before the opponent gets do do his or her thing. If we make a "perfect" Sligh deck that no-one want to face outside a tournament, we haven't got the value we looked for either.

Focus on value. If we realize that the product doesn't give the value we're looking for, pivot. We could just scrap the Sligh curve and go for midrange. Or maybe just build an Erhnam Burn'em or Dead Guy instead. No need to waste time and money on something that doesn't give us any benefit.
It's a bad thing if we realize that we've achieved failure after spending a long time and a lot of money acquiring all the cards. That's why we want to start small, and instead make continuous small improvements to our product. The first version we present might even lack core functionality; its main feature is for us to learn from the users so that we can make the next version better. In Lean startup methodology, this is what is called a Build-Measure-Learn loop.
The first thing we build is called a Minimum viable product (MVP). The MVP is defined as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". This was the MVP for my Project M deck back in 2012:
63-card deck list on an airplane sick bag.
This is enough for the primary customer (in the case of this pet deck; me) to see what the deck could look like and figure out if it is something I'd like to take further. To get an overview of the expenses in creating the deck and look at the synergies. Bring it to a friend, ask them to look at it, and see what feedback I get. This deck list has some functionality in that I can learn a lot from it, but it of course lack one of the core functionalities of a deck; i.e. ability to play it (I didn't have the cards).
Feedback can be painful. Data help us avoid bias.
It seemed like a good plan to keep working on though, and step two was to create a deck list that I could build in the next couple of months. I know that the deck I'll play won't be the end-all be-all product, but if I waited to play the deck exactly as I wrote it on the paper bag, I'd have to wait over two years before playing it. And I would first then realize that the deck should probably be built differently (e.g. no Power Artifact combo).
Project M v1.0, January 2013.
If we're building a deck for a high-level tournament like the Pro Tour, then we have to own the build-measure-learn loop. We have a couple of weeks after spoiler season to come up with ideas, proxy together decks, playtest them, and then either scrap them or keep working on them. Build-playtest-learn, repeat until tournament. We'll have great advantage in a cross-functional team of deckbuilders, playertesters and strategist at our side.

Every new iteration should go quickly from learning to playing. How long does it take between that we realize that we  should cut 2 Swamps and 2 Plains for 4 City of Brass to improve the early game, to that we hold that new version of the deck in our hand?

Test and release

Let's go back to the Sligh deck.
The MVP for the Sligh deck.
After we've exhausted what we can learn with basic theory crafting, the next step is to take this to a sandbox environment and see how it plays. Testing in a local environment if you will. In this sandbox stage, it may be a good idea to use what in software development is know as mocking.

A mock object is a simulated object that mimic behavior of real objects. It could be a crash test dummy mimicking a human when testing car safety, proxy cards for playtesting, or a preconstructed reply from a function mimicking a data base request. We could test a lot of our functionality before we have everything in place.

What do we not need yet? Physical cards and a real opponent for two. Lets build the deck in an online deck builder to see how well it matches up against the goldfish opponent and how well it mulligans.
Those lands can't be right...
After doing this for a while, a couple of things get clearer. A first turn factory can do a good job as an attacker turn two, but as we don't have that much spells that cost one colorless, it is basically takes both the the one-drop and the two-drops spot on the curve. The factory curve could often work better with turn one mountain + Goblin; turn two Factory + Goblin/Orc; turn 3 three-drop, or Bolt + attack with Factory.

Even as a one-drop colorless card, Brass Man seems underwhelming. We rarely have the mana to untap him. Many of our three-drops are also kinda slow; cards like Ball Lightning would better follow our game plan. Atog looks plain bad as well, in particular without the Brass Men.

Whenever we come up with a new idea to improve the deck (or when we've finished writing a few lines of software code) it should quickly become a part of the solution. Making this happen continuously all the way to the finished deck is called continuous delivery. That process aims at building, testing, and releasing software fast and frequently. To make this go safe and painless, we use build automation tools. Continuous integration tools like Jenkins or TeamCity helps us check in our code to a mainline shared by the team multiple times a day, while checking that the new changes didn't break the product too badly (e.g. by running unit tests and integration tests).

We rebuild to this:
This online deck builder is basically a continuous integration tool. It checks that I have the right amount of cards, that the deck is legal in the format, and can show me the mana curve as well as helping me draw sample hands.
Eventually the deck feels faster and more consistent against the goldfish. Time to take this to a proper testing environment where we can play it against real opponents.

Now, actually putting together a deck can go fairly fast if we have the structure and architecture in place. If we don't, it can take hours upon hours. Are our cards organized in binders in a way that help us find them quickly? Do we know where that fourth Thoughtseize we're pretty sure that we own could be? Have we spent time or resources on acquiring a solid card pool, or will we have to buy new components to build the deck (or start making proxies for this stage)? Do we have 75 matching sleeves somewhere?
Is this our data base?
This is of course the same issues that can face the release process step for our software. Our automated tools help. I feel that I could write quite a lot about this part of the process, as it is basically my day job. But I also realize that this is page 23, and we're close to 6,000 words already. So instead of writing an extra 3,000 words on version control, sideboard plans, release management tools, integration tests, and dependencies; we'll just take four bullet points. Then I'll show you my winning deck lists from last weekends tournament in Stockholm and an awesome Buster Keaton clip.
  • Is it scary to make changes to your deck? Are you afraid it won't work? Do you want to spend days testing it manually before trying it out in a tournament? (Lacking automated test coverage)
  • If you rebuild the deck and it doesn't work that well anymore, can you quickly return it to the previous build that worked? Have you thrown away your old deck list or traded away the cards? (Version control and rollback plans)
  • Is it hard to build decks because you have to move cards from deck to the next all the time, or your decks shares a lot of cards between them? (Dependencies)
  • Do you feel comfortable with your sideboard, knowing what to board in and out in most matchups? What could go wrong? (Risk analysis)
Ok, sweet. Here are the decks:
Constructed: Undead Party Crasher
Top8 Draft: URb Control
And here's Buster:
So now we have decided on the deck list, put together the deck, and taken it to the final testing environment before production, i.e. the real market. Think of this last testing environment (commonly known as "preprod") as a stage where we really think the deck will work, but we want to do a general verification before we take it to the Pro Tour. This is where we test our non-functional requirements with load testing and such. It is where we actually sleeve up the deck and play it against a gauntlet of real opponents before the tournament. How much we test here is dependent on risk, i.e. the probability of failures and the impact of those failures. Testing a completely new deck for the Pro Tour requires more effort than testing a net-decked build before a FNM.

The less testing we have to do manually here, the faster we can take the deck to production. If we have a team, we ask them to help us out to save time. If we can in some way automate the testing of our requirements, we do that in all cases it makes sense in terms of time and cost. We can reuse those tests every time we tweak our product, so it's an investment that will pay dividends down the road.

As for the Sligh deck, we have something we can use in production now. While it's not "done-done", it delivers the value we were looking for while not having any major bugs or other issues. We'll play this deck with friends, maybe lend it out during tournaments, and see when the benefits of changing the deck further will be worth the cost of doing so. The first step will probably be to replace two Shatters with Detonates and the Digging Teams with Goblin Artisans and Goblins of the Flarg. After that we try to find a second Goblin King. The build-measure-learn loop never stops. We will continuously tweak this deck as long as there's joy in using it.
93/94 Sligh
Ok, so this was a very long and kinda weird post. You'll get those from time to time. If you got all the way down here, well done! Maybe you picked up on something. Maybe you got some ideas on how work with software development. Perhaps you got some new plans for deck building. Or maybe you just picked up on the dangers of booking a road trip with a juggalo.

onsdag 10 augusti 2016

Off the grid and news around the world

Didn’t a UN Special Rapporteur report conclude that access to internet is a human right? Or did they settle on technology being an enabler of rights and not a right in itself? I don’t know, and I’m in no good position to google it right now.
They say two weeks before it’s up and running in our new apartment. That's an unusually long time to be off the grid. I assume that this post will hit the web soon enough though. I have my phone and can always post it via that one. Flashback to my second apartement in Munich 2012.

Ok, so if we don't get to play with the web, let’s go old school. How did people read about Magic in 1994?
The Duelist #1, January 1994
That's the first ever printed Magic magazine. ”The official Deckmaster(tm) magazine”, no less. There’s some info on hot upcoming releases here, like Antiquities in February and the ”much-demanded” Pocket Player’s Guide in March. I kinda get that it was much-demanded; when all the available rules were contained in the original rule book, things got weird quickly. The ABU rule books encourage solving rules conflicts with coin flips, and suggests handling timing issues by not playing a lot of spells.

The magazine is ripe with classic 90s cockiness and corny fantasy references. I kinda get why we might have gotten roasted in school in the mid 90s for playing Magic when reading this. The strategy is low-level as well, mostly things like that Circles of Protection are not the same thing as Wards, and to have a chance to beat circles you should play more than one color. Lets drop this and find an old school fanzine instead. Maybe some deeper tech.
Lord of the Pit #2, 1994
Hm. Something about the Magic culture in 1994 makes players really want to show off how rad they are, more so than just the casual cockiness we saw in The Duelist. There’s a surprising amount of references (or just statements) about them having sex and having access to alcohol. I can’t think of any article I’ve read on ChannelFireball or StarCityGames where the writers brag about how many times they’ve managed to have sex in one evening. Sure, there are writers who indulge in the combination of alcohol and Magic (this blog would be an example, and of course the MtgUnderground), but I’d like to think that’s more of a narrative device than e.g. an off the cuff suggestion that you should mix 10 cl green Chantreause and 10 cl black Sambuca and call it Bayou. Not a bad idea per say, but needs context.
We were a punchable bunch
I need something fresher. The printed media of 1994 doesn’t cut it for me right now. Let’s see what we find in the note-folder on the laptop.
...
Hey, found a sweet mail from Francesc in Spain:

So far the Old School MTG players group in Sant Feliu de Llobregat (yeah, this place exists) is a reality but alas not everyone has their decks ready. And as everyone is going on vacation or leaves town (or even the country) for several weeks we agreed to do our first Old School MTG beatdown in September.
Sant Feliu 93/94 crew logo
At this very moment the only deck ready to be played is my unpowered mono black that goes by the pet name 'Stout' but the other guys are brewing their own decks (some of them didn't have many cards from back in the day so the process is a bit more difficult for them than it was for me), the most complete one is so far a UR burn (unpowered as well).
"Stout" deck
We go by the Ravenna ruleset so it will speed up the process but we all agreed that once our decks are fully assembled we'll pursuit full 93/94 legal decks (you can spot obvious revised and italian editions in the pic).
 

As a final note and thought we are enjoying the building process immensely, a part not to be dismissed when playing (well, before even playing) old school. 

Have an amazing summer all of you cardslingers ;)”

Good man. Speaking of the Italian rules, there will be a showdown in Camaiore (Italy) in October, which looks simply awesome. I'll just cut and paste from the facebook event:


Fishliver Oil Cup 2016
93/94 Old School Tournament
Italian Rules, Swedish style!

Entry: 20 Euro
First Prize: Arabian Nights Fishliver Oil signed by all participants and a Cup.
Second Prize: Nothing at all (there is only on winner, right?)
Special: All participants will have a chance to win in the UNLIMITED TIMETWISTER RAFFLE taking place before the second round.
Additional prizes: other prizes will be revealed in the upcoming weeks.
Bonus feature
: The 2016 Noobcon world champion Martin Berlin have been invited and will be flown in by the organizers to compete in the tournament. That's the first edition of a new recurring event and we want to establish a tradition every year offering a free plane ticket to the winner of Noobcon to play for a Fishliver Oil in Italy.

Rules: We will follow the so-called "Ravenna Rules", which means Swedish standard rules as described on http://oldschool-mtg.blogspot.it/p/banrestriction.html allowing additional editions (Alpha, Beta, Unlimited, Revised, Fbb ITA-FR-DE, Fwb ITA-FR-DE, Arabian Nights, Antiquities, Legends, Leggende, The Dark, L'Oscurità, Renaissance, Rinascimento).
The tournament will include a swiss (last two rounds untimed - intentional draws are not allowed!) and a single elimination top-8.


If I’m going to book one flight for a Magic trip this year, this is the one. Plans are in motion. Need a Fishliver Oil for my monoblue suicide deck.
Better than Terror with Merfolk Assassin.
Before that though, I’m going to Stockholm next weekend to play the ”From Russia with Love” tournament, battling with guys like David Chambers from San Francisco and Constantine from Russia, both of whom by a chance were to visit Sweden in late August. Gordon Andersson and the Stockholm crew quickly organized a tournament for the occasion. Looks like I’m the lone player coming from Norway though, as they hastily reached the cap on the available seats in the tournament.
The top8 of that tournament will be settled with 93/94 Cube draft btw. Cube courtesy of Martin Berlin.
So, I guess that’s the end of the rant for today. If you need some more solid old school tech, Geena has posted a new article about the sligh archetype. Well researched, and a great read. Far more consistent than this rambling here ;) Danny Friedman has also updated the Understanding Ancestral Recall blog with a new post about the Relic War tournament in Chicago. Some solid Power Artifact tech. And one rad innovator has just started an instagram account chronicling 93/94 Magic cards using 93/94 computer graphics. Check out www.instagram.com/8bit_mtg and nod humbly at the Flying Men :)

Let's cap off today with a picture of Axelsson’s UB Suicidal Tendencies from Wexio:
Simply beautiful.


tisdag 26 juli 2016

AFK and some decks to beat

I’m off to ride a bike from Gothenburg to Oslo during the next four or five days, and then travel north and live in a log-cabin for a week or so. Look at cows and such I guess. What do Magic players even do on their vacations?
Erik, Marina, Gajol, Honka, Øyann and Hörnet yesterday. To be fair, one person around this table does not play Magic.
I'll be off the grid for a week or two, or at least far away enough to not properly update the blog this week or the next. Some digital vacation. Though if there's need for some extra 93/94 fix during the coming week or two, I've updated the Decks-to-Beat section with 16 new decks :)

Arcon 93/94 Top4
14 participants, photos of 4/4 decks. The large Arcon convention in Norway hosted their first non-proxy 93/94 tournament this year. The Norwegian 93/94 meta is much like their metal; unusually black. Again we see a top4 without a single blue card, instead Sinkholes, Geddons and large creatures reign supreme alongside a TaxEdge deck.

The Ivory Cup 2016 Top8
29 participans, photos of 8/8 decks. The first Ivory Cup in Stockholm showed off a myriad of different strategies, and showed that the players from the Swedish capital is capable of skillfully piloting a lot more than control decks. Eight different archetypes in the top8, and the final battle stood betwen the Trolls and the Goblins.

Wexio State Championships 2016 Top4
16 participants, photos of 4/4 decks. For the third year in a row, it was time to battle for a glorious Prodigal Sorcerer and to determine who was the top 93/94 player in Småland. Again, the control decks are mostly left behind. The top4 is dominated by burn spells and effective creatures, alongside a BW Party Crasher. In the end, a five-color Artifact Aggro deck ended up at the top of the heap.

Also, if you want to try a new approach for old cards and multiplayer this summer, you should check out Geena Buxton's two posts about old school EDH at Nomad Gamer; Deep Dive and Mine. Old School. She digs into sets as far ahead as Alliances in the 100-card decks (as that was the time when the terms EDH and "Highlander" were first defined for Magic in The Duelist), but if you're not abhorred by the concept of 1997 and Ishan's Shades with Rituals of the Machine, it sounds like a really sweet and nostalgic approach to multiplayer :)

Have a great summer!

fredag 22 juli 2016

Battle at Blackpool: The UK Championships in Old School Mtg

One could argue that the last month has been a harsh mistress for the Kingdom. News speaks of political turmoil and an abrupt end in the UEFA soccer cup. But as the scald of Stratford-upon-Avon wrote; The course of true love never did run smooth. For love is there, as good people with good stories will tell. This one, about the first UK Blackpool championships in old school Magic, didn't grace the papers. But it is a tale to indulge. This is the story from the horses mouth. It's my pleasure to give the soap box to the first Blackpool UK Champion in old school Magic; Bryan Connolly! Enjoy! /Mg out

Welcome to my first Old School report, which is actually on my first Old School event... When I first heard of old school, I was disappointed to discover that some groups only allowed up to unlimited printings for base set and no reprints. I can see the attraction of keeping it exclusive, but this represented a big of a challenge for me. I actually started playing round Beta/Unlim' Arabians, but briefly stopped as I thought it was getting too expensive! I came back during Revised/Legends, but tended to trade my older (non power) black bordered cards away, keeping only things like bolts, elves and some basic lands etc. I recently discovered the UK group is more relaxed than some, and will happily allow reprints of from Revised, 4th, Chronicles/Renaissance etc, subject to art being the same. This meant no having to acquire ABU duals or Arabian Serendibs, Cities etc. I actually sold or traded all my Arabian and Chron's Cities years ago to dodge City in a Bottle (before it was errata'd) so had to dig out old Cities along with original picture Icy's and as many old playables as I could from the dustiest areas of my collection. Happily I also found a couple of booster boxes which have been traded or sold nicely in the meantime! I've not played much in the last few years aside from a couple of Vintage events a year since the kids came along, so Old School promised to be a reminder of simpler times and a lot of fun to boot.
Simpler times.
Once I realised the format was playable, it was time to decide what to actually play. My favourite deck of the time was based round efficient critters, counter and burn, with splashes for the good stuff in black and white. I dropped white (and sometimes black) depending on how many Blood Moons were played back then (often a lot). I didn't even get chance to test at my local store (Patriot Games in Sheffield) so after a little goldfishing and jiggling, I decided to cut the white the night before the event and keep the blue fliers, restricted good stuff, counters and burn, plus a little black for tutor and twist (the former allowing more singleton 'bord cards such as Blood Moon.) I was agonising over the final mana base and ultimately adopted the one used by Gordon Andersson a few months back at Noobcon, actually ending up pretty much the same deck, as once you add the black for Twist and Tutor, it's pretty close to optimal, apart from a possible change of some counters to Sinks. The sideboard being the usual complements of REBs and BEBs, Flux, Boomerang, Shatters, Blood Moons and Control Magic that makes UR(B) so good.
UR(B) CounterBurn
The event took place during the season end of a series the UK shop Magic Madhouse was running in Blackpool. Sadly, the turnout was slightly lower than hoped due to the event taking place just after a cluster of other big weekends, plus the Old School event clashed with a couple of things that ate into participant numbers slightly (The main event, a large modern with excellent prize support, Senior Championships with booze based prizes, some EMA events, including an amusing Iron Man that saw a foil Dack countered and thus ripped up!) so a couple of people dropped out quite late in the day and we were a fairly small field. 4 rounds Swiss plus a top 8 promised a good shot at playing the deck a few times. This was billed as the first UK Old School champs, but there was actually a similar event last year, but it's Old School, so no-one is that bothered, the main thing is that it's becoming more popular and people will travel to play.
Pre-tournament signing of the participation card D'Avenant Archer.
My first round was against Steve Rich who seemed to be on a conventional zoo deck. I got very early beats in, including a turn 1 Black Vise on the play, so I slightly misboarded for game 2. It was actually more of a sui build, heavy on the Unstable Mutations, Giant Growths, Blood Lust and Berserks (with some cunning avoid fate to keep things alive.) Serendib swung at me for 10 very early in game 2 and I got too far behind as a result. Once I corrected board and play style (I was not the beatdown) I was able to keep his actual creatures down and strand his pumps in hand to pull out a 2-1 for my first ever round of Old School. Steve's been on the scene forever and has always been a cracking bloke, so first game was a pleasure.
Round one facing Steve.
Second round was against Rod Smith, another stalwart and active supported of the Vintage and Old School scene who turned out to be on a RBW critter list round big hitters like Juzam and Su-Chi, with plenty disruption in the shape of Sinkholes, Plows, Bolts, Disenchants and the like. In the first round, I landed an early Flying Men and was able to keep nibbling away, control his guys and burn him out. I borded to be a little more control oriented and to try to land a Blood Moon as he was very light on basics (2 swamps it transpired.) Took a bit more damage in the 2nd and had to deal with a City in a Bottle, but the dib and burn got there for a 2 – 0.

Third Round was against James Griffin, piloting a mono white deck which was a thing of beauty to behold. He does his own alterations and every single card was altered (and by altered, I mean entirely repainted) himself with a monochrome feel with subtle colour used to good effect. I was able to keep multiple Crusades from hitting, meaning I could Bolt or creature trade efficiently, and I cast my mind back 20 some years to remember how best to counter the mono white builds. I was able to get a favourable combat trade by a sneaky Boomerang of a Crusade. I avoided getting 'Geddoned and once the creatures ran out, the burn could go to his face instead for another 2 – 0.
James's monochrome altered WW.
Fourth round was against Jim Brophy, one of the Irish crew I've known for years, and was faced with a similar deck, albeit much prettier (entirely black bordered, and I mean Beta rather than FBB.) Jim didn't have the Black splash, but went with heavy hitting top end in the form of Serendib Djinn. We could have easily drawn in, but where's the fun in that? The first 2 games were slug fests, each of us taking it down still on double digit life, with the last one being such a close one. We both mulled and traded blows, it came down to the wire with us on one life each, but I edged it in the end with sneaky use of blasts. Top 8 and undefeated in my first Old School, and having a ton of fun to boot.
Jim's blinged boardstate.
Quarter was against Chris Cooper on a Dead Guy style build chose to plow my Flying Men early rather than take evasive damage, but that was one less answer for Factory later. His Twist did little other than empty my hand of instant burn. His life total went down in the usual increments of 2 from factories and 3 from Dibs and Bolts, plus the odd Psi Blast here and there.
Quarterfinals vs Chris.
A tactically timed shatter on his City in a Bottle in the second game let me drop my City of Brass and Twist his entire hand away before following up with the last few swings, all taken in good grace. By this point I'd realised that without exception, anyone playing Old School is pretty much certain to be a truly nice person.
Good people
Semi was against Alastair Kennedy, another Sheffield based bloke who I try to get the odd test in with in the local shop before Vintage events, but neither of us knew what the other was on thanks to a minor domestic trauma that kept me out of the shop the week before. He turned out to be on U/W deck control and got a nice bonus of a free mull' out of me, as between chatting, eating and drinking, I managed to shuffle some my board in for game 1 and I saw an Energy flux in my opener – I immediately advised the judge and I deboarded, got a warning and a compulsory mull. This one promised to be a grind, especially with untimed rounds, so mid way through, I decided best way to actually win was to try to fight permission on my terms even it if meant 2 for 1 to deal with Serra's and use life as a resource to thin him down. 
Alastair vs. Karl in the swiss.
With us both getting a little low on cards, I managed to set up a situation where I had a plan B of Wheel to run him too low on cards left to kill me, but instead got plan A off: This was to wait till he tried to resolve a Serra, and ultimately get to Mana Drain it, then have enough mana left to pull off a near lethal Braingeyser, with exactly enough mana to pay for a Power Sink in case he had one left. Decking win in the first with Alastair at 18 life! All the hate in the world came in for game 2, and with my smaller flyers and some Chains replaced with REBs and Fluxes, his Moxes were going to Lotus Petals, and Tomes and Icy's a bit of a liability. An unpleasantly timed Twist when we got to mid game let 2 swings from a Serendib and a fist of burn seal the deal. The run of fun and pleasant games continued.
Alastair's UW Control deck.
Final time, against Rod Smith again. Game 1 was a bit of a roll, as he had turn one library, which is always tough to beat. After bording to more control, game 2 went my way, having to 2 for one a couple of times with the library Gods favouring me this time, with a strip ready for Rod's, and we were down to the one for all the marbles (or in this case, a wee trophy and choice of which oversized card we got.) Rod was back on the draw and didn't look 100% happy with his 7, but kept. 
The final seven.
I decided to chance keeping my opener, which one of the onlookers took a pic of: City of Brass, Bolt, Ancestral, Shatter, Blood Moon, Twist and Fireball. After a bit of early trading, Rod was forced to drop City in a Bottle to stop Serendib, and I decided not to shatter it till I absolutely needed. Another game of life as a resource, saving my counters for the biggest things (like CoP Red) not risking a Serendib killing me while being neutered with Maze, Imprison, Spirit Link or the like. I had to go very low to take control and keep multiple counters while on 2 life, with Rod then having to plow a couple of my factories to avoid going too low himself, thus giving me a cushion against Bolts – I was back up to 8 briefly. 
Finals vs Rod
He ended up under a Black Vise with multiple Arabians cards in hand, and even had to cast a “do nothing” Balance to free up his hand a little and cut down on damage. As the game ground down I ended up with multiple Counters, a Control magic for Su-Chi, Trolls or Black Knights, plus Bolt and Psi Blast and a Serendib to beat with if he did blow the City and start dropping Juzams. Got to the point that I couldn't see an out with likely played cards (I gave Rod credit to not run Healing Salve) and showed him my hand of “no” and burn for the handshake.
So, what have I learnt about the format? Suggestions that Vise should be de-restricted are not realistic, it just deals too much damage early, keeps card drawing (especially with Library EOT) in check, and gives free kills off Wheels and Twisters. Speaking of the Library, in the absence of Wasteland, early LoA can be a deciding factor, especially for controlling mirrors. Having had a run on one classic deck from the era, I'm torn whether to fettle with it, or dig out some other old stuff and go combo or heavy control.

Wonderful day of magic at a well run event with friendly people and no unpleasantness. Magic Madhouse even donated a proportion of entry fees to a charity of the winner's choice and sprung for a nice glass trophy. Am hoping to fiddle with more deck types and get to more events, am certainly sold on Old School. There are still complex decision trees, different archetypes to explore and metagame, but less anguish over whether they're holding a Force/Mis-step or Daze, and more booze and junk food. I'll be back for more, that's for sure.