Welcome to Bloodthirst Week. This week we'll be exploring a mechanic of Ravnica's Gruul guild that found its way into the core set with Magic 2012. When I first heard the topic of the theme week I assumed I would write an article about what we look for in returning mechanics specifically in the core set. As I began to figure out what I wanted to write, it hit me: I'd already written about it a month ago. (Okay, it wasn't the whole column, but it was enough to make me rethink what I was going to write this week.)

As I thought more about returning mechanics, I found myself thinking about an important aspect of game design: resource management. Note that I'm not talking about the game mechanics of resource management, but the resource management of game mechanics. Just as gamers have to worry about the resources we as game designers give them, so too do game designers have to be careful with the resources they have available.

Today's column is going to examine what I feel is a natural shift that coincides with the maturity of a game: the ability to manage resources in the game design itself. We'll start at the beginning and work our way forward. Be aware that I am talking about the evolution during the entirety of a game, in this case Magic, not a particular set.

    Stage #1: The Wasteful Early Days

When a designer first designs a game, the major goal is getting the game off the ground. If you look at the history of game design you will learn this first important lesson: most games die—quickly. It's very easy to have a warped view because almost all the stories you read about game design are the successes. What you seldom hear are all the games that never quite found their footing. As an example, I have two bookcases in my den (and a bookcase in my basement) dedicated to my game collection. What percentage of the games I own are still in print? I'll be kind and say 20%.


Note that my game collection skews towards successes because obviously I am more likely to pick up games with a proven track record. The number of games produced that are still on sale five years later is probably under 5%. Ten years later is probably under 1%. I bring this up because when a game is first coming out, the last thing the designer is worrying about is his or her design resources. If the game fails, it doesn't matter what design resources are in reserve. As such, it's just not on a game designer's radar.

As with each stage, I'll take a look at Magic during the relevant time. I wasn't at Wizards during this portion of Magic's lifespan, but I've had a lot of conversations with Richard Garfield (creator of Magic). Alpha pulled out all the stops mechanically speaking. Richard tried lots of different things mechanically because he wanted to show off the breadth of what Magic could be. As I often say, Magic is a game of discovery, meaning its earliest incarnation wanted to allow as much discovery as possible.

Stage #1 is usually represented by a carefree spending of design resources. As stated above, this is done primarily because the needs of an early design have very different priorities.

    Stage #2: One and Done

So let's assume your game is one of the few that makes it past infancy. Now it's time to start making more designs for your game, be it an expansion, a supplement, some promo material, etc. If your game has any depth, you've barely begun to tap into your design resources. As such, you're still pretty carefree. In fact, odds are that you don't even recognize your design resources as something you need to manage. Usually at this stage, mechanics are a disposable resource—one and done.

Also, as this is early in the game's lifespan, it's not yet obvious that the game is going to be around ten years later. The mindset of saving game resources for future use only comes about when you see that you have a future to worry about.


I started freelancing for Wizards during the second half of year one and was working full time near the beginning of year three, thus I was here when Magic went through this stage. At this point there had been design work on about a dozen sets and each one was easily able to find new design veins to tap into. This ease of finding new design areas created a feeling as if design possibilities were endless. Because of this, in the early days, we honestly felt like any mechanic that we used would either become evergreen (we would use it whenever we wanted to) or would be tossed on the scrap heap.

Proof of this mentality can be seen in the Reserved List, the list of cards that we promised in our early days never to reprint. For each large set we were allowed to put aside, if memory serves me, 20% of the rares to be eligible for reprinting. The remaining 80% would go onto the Reserved List, never to be reprinted. Notice that every rare with a block-specific keyword mechanic was put into the 80%. Why put it on the list of cards we may reprint? It has a mechanic, thus we're never doing again.

I know it seems odd that it would never occur to us that we'd want to reuse a mechanic, but be aware that at this stage of design, the focus isn't on resources. With an unknown future and what seems like endless design possibilities, there's no sense of urgency.

    Stage #3: Acknowledging the Future

As the game starts getting its footing, there's more acknowledgement that a future might exist. As such, for the first time, you begin to think about how much of your design-space resource you are using. At this point, you haven't yet got to the idea of reusing mechanics, you're just more aware of using up your "disposable" mechanics slower.


I believe this stage comes about when the game designers stumble upon a mechanic bigger than needed for the slot it's going to be used in. For Magic, my earliest memory of this happening was with the cycling mechanic in Urza's Saga. We realized very early that there was a lot we could do with cycling, but we also realized that cycling could get us pretty far. In fact, as it turned out, it got us through the entire block. (Okay, I did "cycling from play" as a twist on cycling in Urza's Destiny but even that was cycling , and no one but me and four guys noticed what I was up to.)


Cycling was the first time where we left ourselves space to bring the mechanic back. It wasn't that we knew we were going to bring it back as much as that we knew we didn't need any more than cycling to make the block work.


The importance of this stage is the first awareness that your game design resources are in fact resources. I believe one of the biggest signs of designer maturity is the desire to do your design with as little design as possible. What is the least you could put on a card and have it still be cool? What is the least amount of things you could put in a set and have it still work? This is the stage where a designer starts to appreciate the value of doing more with less.

    Stage #4: Bringing It Back (With a Twist)

The previous stage helps set this stage up, but there is a big difference between conserving resources and renewing them. To use a recycling metaphor, you first learn to reduce waste before you learn the value of buying things that are recycled. This stage tends to come about because the designer is trying to solve a problem and realizes that the answer is not something new but something old.


This is exactly how it happened in Magic. We were working on Onslaught and we were looking for a mechanic like cycling. One day I had the big epiphany: what if we just used cycling? In order to sell this to the rest of Ramp;D, I had to come up with a new twist for cycling. Costs other than were the obvious go-to answer, but it was my suggestion of cycling triggers that got everyone on board.

I think the desire to innovate the returning mechanic is a key part of this stage. The idea is that you aren't reusing a mechanic as much as you're continuing its use from its first appearance. The reason I believe this is important at this stage is because the designer still doesn't see existing mechanics as tools for design to use. At this point they're a resource that hasn't yet been used up.

    Stage #5: Reusing Mechanics Is an Option

The next stage of resource management is moving from continuing the design of an old mechanic to merely bringing it back. The difference between the two stages is this. In the last stage, the returning mechanic is thought of as a resource that hasn't been completely tapped out yet. This means the returning mechanic must be evolved.


In this stage, the designers start realizing that their mechanics have a general function that can be reused. A mechanic brought back need not do anything more than it did the first time it was used. For example, in Time Spiral, one of the rules of bringing back mechanics was that we didn't evolve them.

Another important mental shift is the idea that the returning mechanic is itself a selling point of the set. Early in a game's design, newness is the key thing a new product brings to the game. Players are even trained to ask of a new expansion, "What's new?" With time, though, a game starts to gain a history. This history starts to create its own equity. Bringing back a mechanic is no longer laziness, but nostalgia.

Time Spiral was the first set where we explored this concept in depth. We played up the fact that mechanics were coming back and encouraged players to embrace their return. While Time Spiral had its issues, it did teach us a very important lesson: mechanics from the past have value unto themselves. Bringing back old mechanics is not seen as a weakness of the design, but of strength.

The caveat to that last statement is that the returning mechanic has to make sense in the design that brings it back. If the mechanic makes organic and holistic sense then it is a boon for the set. If not, it will stick out like a sore thumb and be seen as a liability.

    Stage #6: Returning Mechanics Is a Necessity

Over time, designers will start to get a better sense of the limitations of their design space. With this knowledge comes an important realization: mechanics are a resource that have to be carefully rationed. At this point in a game's lifespan, it has proven itself and is no longer struggling to stay on the shelves.

Once you believe that your future is limited by your own actions rather than outside forces, you start to look at your design in a completely different light. When people ask me what will be the death of Magic, my answer is that I believe Magic would have to cause its own death. What I mean by that is that Magic has created enough momentum that it would have to be mismanagement from our side that would kill it. (For the record, I don't believe we're going to kill it.)


As I love my metaphors, let me compare this to a fundamental change people encounter getting older. When you're young, you don't tend to think much about your own mortality. You do the things you enjoy and sort of assume that things will get figured out later. One day, though, you wake up and you realize that you have a lot of impact in how your life is going to play out. If, for example, you do unhealthy things, it's going to shorten your lifespan. So you start looking at life differently. You start thinking about how your actions are going to affect you.

Game design is similar. In the game's youth you tend not to think of the impact of your actions, but as the game matures you have to start taking responsibility for your actions. A big part of this is understanding your mechanical resources. Once you take this into account, you start acting more responsibly. This is what leads to seeing old mechanics as an important resource.

During Shards of Alara design, Bill Rose (VP of Ramp;D and the lead designer of Shards of Alara) sat down with me, and we talked about the importance of preserving our resource of mechanics. To help with this Bill suggested that we include a returning mechanic in every block. I agreed with him and since then, every set has reused an old mechanic. Shards of Alara had cycling. Zendikar had kicker. Scars of Mirrodin didn't have a straight-up repeat, but that was because metalcraft was a new kind of "artifact matters" and infect was a mixing of poison with wither. Innistrad has... well, you'll see.

I believe the addition of old mechanics to the Core Set is another extension of this stage. We are trying hard to make the core set fresh but accessible, so reusing nice simple mechanics from the past, like bloodthirst, makes a lot of sense.

    Resource of Strength

For Bloodthirst Week, I've done very little talking about bloodthirst, but I feel my column today is examining a much bigger topic of which bloodthirst is an example. Magic has matured as a game and as such the designers of Magic have had to also mature. The inclusion of bloodthirst in the core set (and scry before it and [unrevealed mechanic] after it) demonstrates an important step forward in Magic's design.

Bloodrage Vampire | Illustration by Steve Prescott

We're here for the long haul. It's my belief that Magic will outlive all of current Ramp;D. Because of this belief, I (and the rest of Ramp;D) make decisions based on doing what is best for Magic's long-term health. Bloodthirst might not seem like a big deal but in the big picture the fact that it's back speaks volumes for how its design is being handled. That was the point of today's column.

For those counting, this is the five hundredth week of DailyMTG.com and of Making Magic. That means next week's column will be my "Five Hundred and Counting" column. After that will be a theme week, and then three weeks from now will be this year's State of Design column, where I examine the last year of Magic design with a fine-toothed comb.

Until then, may you take a moment to think about how you're affecting your older self.