Let's See What Develops
As I have a spare week to talk about whatever topic strikes my fancy, I thought I'd discuss something that came up for me while writing last week's column. In fact, this is a topic that pops up often and while I've touched upon it, I've never given it the full column it deserves. Today I'm going to talk about something I don't talk all that much in my design column—development.
Arrested Development
But development shows up constantly in my column, many of you are saying. Why last week I talked about it multiple times. I do talk about development a lot in "Making Magic," but most often as an antagonist. They are always the ones trying to stop me from bringing my awesome ideas to the world.
My job is to talk to you all once a week and entertain you. To do that, I have to be a storyteller. I can't just give you the facts, I have to present them in the most engaging way I can, which means I have to tell you a story. While a good storyteller will make you forget this, stories have all sorts of rules to them. The reason some people can tell a good story while others can't is that is it isn't enough to merely piece together story elements. No, you have to present them in a very specific order. The audience has expectations that you have to meet.
A big part of storytelling is the importance of conflict. The protagonist (a.k.a. the main character) has to want something. Then some force (most often the antagonist) has to attempt to prevent him from reaching his goal. The story is about how the protagonist succeeds (or fails) in reaching his goal. If I'm going to tell design stories, I have to have goals and obstacles. Goals are easy as design is all about creating goals. Design also has plenty of obstacles but I have to attach them to people because one of the rules of storytelling is that having an antagonist makes the story more fulfilling, especially an antagonist that's a person (antagonists can be non-human, they can even be non-sentient like a storm. Running into random problems isn't as exciting though as having someone actively trying to stop you).
Here's the point of my column today. Development isn't the antagonist to Design's protagonist. To continue my storytelling metaphor, they're Design's "best buddy." They're the person who helps Design achieve its goals. Here's another way to say what I want to say. I am about to start the design for "Line" (the winter set of 2013). It will be my sixteenth design lead. In every design I have ever led, the finished product was better for having gone through development. Every set, hands down, no question.
I'll go one further. I believe that development is one of the most important tools designers have available to them at Wizards of the Coast R&D. And today, I am going to sing development's praise because I believe that is something I should do in the designer's column. I'm only sorry it took me ten years to actually do it.
Without any further ado, here is a list of awesome things Development does for Design:
1. They Provide a Second Pair of Eyes
There is a danger in creative endeavors called "tunnel vision." The idea behind tunnel vision is that a designer can be so focused on the task at hand that he or she stops paying attention to things on the peripheral. In Magic design, this can be seen when a designer makes every card in the set directly tie in to the core mechanical heart. (Remaining GDS2 candidates—pay attention.) Imagine Zendikar if every card had to have the word "land" show up in its text box.
A second design problem is what is known as "designer's inertia." Each time you make a pass on a file, you separate the good designs from the bad. The good ideas stay and the bad ideas go. With time though, you start to just assume the good ideas are good. They've been good for every other pass, so you stop questioning them—you lock them in. Little by little, your set fills up with these locked in "good cards" until it's hard to add things because nothing wants to go. Sometimes these "good" cards are no longer good as the parameters of the set have changed. Often times, all the "good cards" are, in fact, good so it becomes very hard to kick out a known success for a new card of unknown quality.
A third design problem is known as "ugly baby syndrome." The idea behind this is that no parent wants to call their own baby ugly. So he or she starts rationalizing why the baby isn't ugly. The designer feels that others can't see the true beauty of the "baby" because they are (fill in the blank).
There are a lot of good things that come from having a singular person create a vision. There are downsides, though, and the entire design/development relationship comes from allowing the system to offset these downsides. A pair of fresh eyes isn't trapped in the tunnel, they haven't assumed any cards are locked in the set, and there is enough distance to call an ugly baby ugly.
There is great value from having one person provide the vision for a design, but for the idea to be fully realized, that person has to take a step back and let someone else focus on it. As I often talk about, Magic design is a group effort and a big part of that is the handoff that happens every set.
2. They Challenge Design
Yes, designers fight all the time with developers. We also argue all the time with other designers. Magic R&D, in general, just likes to argue with one another. That fighting, though, is done with the goal of improving each set. Whenever I talk about how Development argued against an idea that went on to prove itself, that was just them doing their job making sure that the idea was the best it could be.
I have a very good track record when it comes to Magic design. I have designed numerous very popular sets. I have designed a lot of successful cards and mechanics. I have probably been responsible for more innovations in Magic design than any other designer in history. You know one of the worst things R&D could probably do—just let me do whatever I want.
One of the reasons my track record is as good as it is, is because I've always had members of R&D to question everything I've ever come up with. You only see the things that made it through the gauntlet. As I often say, good ideas will persevere. Part of that is the process requiring design to prove everything. I can't just say, "I believe it will work," I have to actually produce the cards/mechanics/sets that work.
I've talked before that in communication school, I was required to take classes on how media functions (teach gun safety before handing out the guns, metaphorically speaking). One class the professor showed us news footage of a protest. In the footage you could see angry Iranians passionately decrying the acts of America. This is the footage that the American media showed during the fourth month of the Iranian Hostage Crisis in 1979. (For those unaware of this story, Iran took 52 United States citizens hostage for 444 days from 1979 to 1981.)
The professor then showed the same protest from a different vantage point. In the foreground was the city going on with its daily life. In the background, you could see the protest going on around the U.S. embassy. Yes, there was a protest, but it was a small handful of people. The rest of the city had moved on. The point the professor made was that the first video is one hundred percent real. Everything filmed did, in fact, happen. He explained that one of the great powers of television is that people believe because they see something with their own eyes that they cannot be deceived. Context, he said, is crucial. "You don't have truth," he said, "without context."
I bring this story up, because it is very easy to look at the developer arguing about split cards, for example, as being in the wrong. That, I argue, is because you are seeing it out of context. The developer does not have the luxury of knowing how the mechanic will be received. It's Development's job to make sure every idea is worthy. Development questioned split cards because they question every mechanic. And the crazier the mechanic, the more they need to question it. Split cards were asking us to make a card frame change, something Magic had up until that point (barring Unglued) never done. That's a giant barrier, one R&D should not have taken lightly.
I'm not going to say that fighting for my designs never gets frustrating, but it's an important part of the process as it produces far more good than frustration.
3. They Care About Things so Design Doesn't Have To
Another great part of the Design/Development relationship is that it allows each part to focus on what they do best. I love innovating, I enjoy creating synergies, I get enjoyment from making the mechanics and creative flow together, I like thinking about the big picture, I adore designing cards and mechanics. These are all things I'm good it. What am I not good at? Figuring out power levels, worrying about the metagame, tuning knobs. Being allowed to do all the former and not have to worry about the latter allows me to be a better designer.
One of the biggest problems I see in young designers is the desire to get too tactical in the design. They get very focused on what's supposed to be the good cards. In design playtest I purposefully try to put the cards at around the same level because I want all the cards to get played. Sure, I could make ten cards better than all the rest, but then all I learn is about those ten cards. You know what I want to be good, the cards that are the most fun to play. How do I know what those are? By playing with the cards.
While there are plenty of overlapping skills, Design and Development tend to care about different things. I think that's great. Specialization works well in the real world. Why not in Magic card creation? If I'm having a problem with my lungs, I'm glad someone went to school and studied the lungs for a long time. Knowing that experts are going to check my work and fine-tune it, is very liberating, and, I believe, makes for better sets.
4. They Have a Different Vantage Point
This is connected to the last point but it's important so I'm giving it its own write-up. Whenever I put together a design team I always make sure to include at least one developer. Why? Because I know they are going to approach the set from a completely different vantage point than I do. They are going to spot problems that I wouldn't be looking for. In addition, developers just look at cards and mechanics differently. It is valuable for a design team to have members who approach the design from different perspectives to allow insightful discussion. This is the same reason, by the way, that I feel designers can be a valuable addition to a development team. The problems we'll spot as a designer are often different from what the developers are focusing on. Also, when a card has to change, we can offer more options as to how to make that happen.
The area where this vantage point tends to be the most helpful in design is where the designers are very focused on what each part of the set does for the set. Our focus is very internal to the set. The developers tend to have a much better sense of what each part of the set will do to the game. How will it affect different formats or how will a certain card cause decks to be built around it? Many times during a design meeting, I've had the following happen:
Me: And that's why this will be a perfect fit for the set.
Developer: I see why the set wants that element but that isn't how the players are going to use it.
Me: What do you mean?
Developer: Well, because of [Reason A], the card won't be used as you want them to use it but rather as [Use B].
Me: I never thought of that. What can we do to avoid [Reason A]?
Developer: I've been thinking about that ...
One of the recurring themes is the value of having different people perform different functions as it allows the team as a whole to be more broad in its capabilities. Design has many reasons it needs to be insular, but it is also crucial to have someone on the outside looking in and the developers are very good at doing this.
5. They Catch Your Mistakes
Whenever I'm asked about being a designer as opposed to being a developer, my line is as follows: I love being a designer. We get to do all the fun stuff and then development has to do all the hard stuff. Design has its own challenges (most people are not so good starting with an empty piece of paper), but we have one of the greatest luxuries. We get the ball rolling. And then once it gets rolling, we say, "Here you go. Try not to let it crash."
A good designer needs to watch out for his or her set in development, and Design is responsible for being there if Development needs design-related help with the set. That said, while Design comes up with a lot of questions, it doesn't always come up with all the answers. More accurately, Design comes up with answers, but Development often finds better ones.
If you ask trapeze artists what their greatest sense of security is, they will tell you it's the safety net. When you're doing crazy flips in the air, it helps a lot to know there's something to catch you if you fall. Development is Design's safety net. Trust me, Design has its share of falls. I should stress I'd have it no other way. If Magic is going to survive long-term it's going to be because Design is willing to push limits and explore the unknown. Doing such means there are times we will fail, but never trying something that might cause us to fall is far more dangerous as far as I'm concerned.
This makes the role of Development crucial to the game's survival. Not just because they keep it fair and unbroken, but because they free up Design to try all the crazy things it has to.
Another Not-So-Rotten Development
The message of today's column is a simple one: Development is awesome. They are Design's greatest allies and a big reason the game is as great as it is. While I promise they will play the antagonist role in future columns, this is merely because doing their job entails getting in the way of my goals. I'm damn glad they do.
Join me next week when the war begins. Well, at least the preview of the war begins.
Until then, may you learn the value of a good argument.
One Last Thing ...
I have made it a habit every year of posting my family's holiday card in my column. Normally I do this during one of the "Best of" weeks but between my vacation and my holiday cards showing up later than normal, I didn't have a chance to "send" all of you my holiday card. I am fixing that today. Without further ado: The Rosewater 2010 Holiday card:
