Piggybacking
Nature abhors a zombie
We gave George, Laura, and Rich a tour of Wizards. We did a Magic 2013 booster draft with them. My favorite moment of their visit, though, was during lunch, where George and I talked about the design of our respective games. George (as well as Laura and Rich) is a huge fan of Magic, having played since Revised, and has admitted that Magic had a big influence on his design of Plants vs. Zombies.
During lunch, there was one tiny snippet of conversation that inspired today's column. I will now recreate that conversation with my normal creative license:
Me: So George, here's something I was always curious about. Why plants?
George: In a tower defense game, you have to lock down your forces to specific areas and it always seemed weird to me that they wouldn't ever get involved elsewhere on the battlefield. I mean, don't your knights see that their help is needed right beside them? I chose plants because I needed units that would stay stationary. Players wouldn't expect them to move.
Me: Interesting. Okay, why zombies?
George: Once again, in a tower defense game, you have to have a slow invading force to give you time to set up your defense. We originally were going to use the aliens from Insaniquarium (George's previous video game) but it seemed odd that they were so slow, so we changed them to zombies because everyone would expect zombies to be slow. That's what zombies are known for—being a slow invading force.
As a game designer, that conversation really hit me. I had always assumed plants and zombies were chosen because they just seemed like a quirky pair together, but they were actually chosen for a much better reason—they conveyed the essence that each side needed: staying put and being slow.
The reason I bring this up is because I want to use today's column to talk about a very important concept in game design that I haven't seen much written about. It's about a concept called piggybacking. What is piggybacking and why is it so important to game design? That's my topic today, so if that sounds interesting, stick around.
I'm Complexy and I Know It
I've spent a number of different columns talking about complexity (my most famous three being here, here, and here), but I tend to talk more about its cons than its pros. I tend to focus on how complexity makes the game less accessible and thus harder to learn and play. What I seldom do is talk about why complexity is good. Let's fix that. Here are some things complexity does positively for a game:
1) It Adds Strategic Depth
I should begin by stressing that lack of complexity doesn't necessarily reduce strategic depth. There are ways to create strategic depth without relying on complexity. With that caveat out of the way, complexity, when used properly, can add a lot of robustness to a game. It allows you to add in interesting corner cases and it gives you the freedom to let each part of the game take up the space it wants.
2) It Allows You To Better Match Flavor
Flavor is messy. It goes all over the place. Game designers learn to abbreviate communicating flavor because flavor doesn't tend to fit in the nice, simple boxes that the mechanics fit in. Complexity allows your mechanics to better match the flavor and keeps nonsensical things (what R&D calls "the elephant in boots" issue) from happening.
3) It Creates More Variety
In Version A of a game, ten things can happen. In Version B of the same game, fifty things can happen. Version B will have more variety of play because, quite bluntly, there are more things that can happen. It's just simple math.
4) It Opens Up Design Space
I have talked numerous times about how I have to make sure we manage the design space of certain parts of the game carefully, because it's a limited resource. Planeswalker design space, in particular, is pretty small, and I've spent great amounts of energy making sure we mine out every ounce of what we have before we dig into new design space.
Complexity does open up some of this design space by allowing more options of things to happen. For much of the same reason it makes more variety in game play, it opens up what design can do because there is simply more of it.
5) It Helps Experienced Players Feel More Invested
Time Spiral has proven to be a very emotional block. The majority of players at the time didn't like it (as documented through market research and sales) but those who did, really, really liked it. Why? Because they "got it." They understood all the references and in jokes. They were able to follow all the moving pieces because they had invested themselves in the game and thus were set up to understand all the small details design and development put into the block.
The reason that group takes offense every time I talk about the block's problems is that it had a very positive effect on them. It made them feel as if all the time they'd spent learning everything about the game paid off. It felt like a reward for their time and made them feel invested. Complexity tends to do this well and is one of the reasons many games veer towards complexity as they try to appeal to their base.
6) It Makes Design Easier
Blaise Pascal (a French mathematician, physicist, inventor, and writer) is famous for saying, "I would have written you a shorter letter, but I did not have the time." I, likewise, am often asked why my columns are so long, to which I always explain that I have too much to do to make them shorter. Elegance, simplicity, and brevity are hard work. That's true in writing and it's true in game design.
The reason that beginning designers tend to make much more complex designs is mostly because it's a lot easier to do. Finding the tight, concise way to make a game mechanic work takes a lot of time. If we were given the luxury of being more complex, it would make design's job a lot easier.
I could go on. There really is a bunch of positive things complexity can do for a game. The problem is the other side has a very compelling argument:
It's the Greatest Force Capable of Killing Your Game
Yes, there are many other reasons against complexity, but this one is enough to make any game designer sit up and take notice.
What this means is that complexity is something a game designer wants but has to be careful with. The trick is finding ways to sneak complexity into your game without making it more complex. What? Is that even possible? Why yes it is. The most common solution to this problem is what is known as piggybacking.
Piggyback in the Game
Piggybacking is the skill of building design around an already known and understood concept. The idea being piggybacking is simple: Instead of teaching someone your game from scratch, use things the player already knows.
Let's use my example above from Plants vs. Zombies. In the game, players buy seeds, which they then deposit in a specific area to grow certain plants they will use to fight the incoming zombie horde. Note how George used the general knowledge of plants to make everything about them seem obvious.
You have to buy something to allow you to make the plants. This is just like the real world. If you want to grow a plant, you buy seeds. Then you have to put them into dirt in a specific location. Once again, this is exactly how you grow a real life plant. Finally, once planted, the plant is now locked into its location. Once again, exactly like real life.
The key here is that by using plants as the pieces in the game, George was able to take all the parts of the game that might feel complex and condense them down to match a metaphor the players already knew.
Let's apply this same trick to Magic. I'll use the highest-profile series of cards from the last year—the double-faced cards. Mouse over to see their terrifying transformation.
Each double-faced card above showed a horror trope of dark transformation. The human becomes a werewolf. The bat turns into a vampire. Dr. Jekyll becomes Mr. Hyde. Each of these cards used the players' knowledge of the trope to help them understand the mechanics.
For instance, all of the werewolves had the same trigger to turn from human to werewolf and a second shared trigger to turn from werewolf to human. How were players supposed to remember this? Because they understood that what would turn one human into a werewolf—a full moon—would turn all humans into werewolves. Likewise, players got that the human side was weaker because, in horror mythology, humans are weaker than werewolves.
The players understood that the bat flies because bats fly. They got the vampire/bat could choose when to transform because in horror stories, the vampires have this ability. They knew that the transformation could go back and forth because, once again, the source material they already knew told them this.
The Civilized Scholar/Homicidal Brute is kind of complex on the surface. The Civilized Scholar requires a trigger based on a discard. The card turns into a different color, from blue to red. The Homicidal Brute has a completely different transforming trigger based on not attacking. Once you layer over the Jekyll and Hyde flavor, all those pieces fall together. The scientist is experimenting and turns into the brute. The shift in color shows the radical change in personality. The brute attacks until he calms down and turns back into the doctor. The knowledge of the trope takes a complex set of items and makes them far less complex.
The More You Know
Piggybacking doesn't rely solely on flavor. Piggybacking only requires a designer to build upon existing knowledge. That knowledge can come from anywhere. For example, here's another story George told me about the design of Plants vs. Zombies:
Part of a tower defense game is that as you get more resources you can start to purchase more powerful weapons. George knew he wanted to have plants with more firepower, but he never liked how in many tower defense games you had to just learn that one unit dealt more damage than another, even though it wasn't always easy to follow. Why, for example, does one type of soldier deal 1 damage while another deals 2?
The base projectile shooter in the game is called a peashooter. It's a little pea plant that literally shoots peas at the invading zombies. The solution to his problem was to create a plant (called the repeater—the game is a treasure trove of puns, by the way) which shoots two peas instead of one. How does the player understand that this unit does twice the damage? Because it literally fires twice as many projectiles.
George was playing into a very basic concept—that two is twice one. Humans understand that two apples is twice the amount of apples as one apple. So by merely making his plant shoot two objects, George got along the concept he needed in a clean way that piggybacked on a very basic piece of information.
Now let's look at a Magic example. In Avacyn Restored, Brian Tinsman, the set's lead designer, was looking for something splashy that would get the players to focus on their draw. In the end, he settled on draw triggers (cards that had special value when you drew them—for more on this mechanic's creation you can read my article on it during the first Avacyn Restored preview week).
I've always been a fan of the idea of draw triggers (I tried to get them into my very first design, Tempest), but I wasn't sure how exactly they fit in this set. I understood mechanically how they fit into what Brain was doing, but they didn't seem to have a purpose in the greater flavor of Avacyn and her army of angels turning the tides and helping the humans defeat the monsters. I decided that if the mechanic was going to stay, it needed to have a context. With some thought, I pitched the idea to Brian that these spells were miracles.
The idea of a miracle did two very important things. One, it gave the mechanic flavor and it tied them thematically into making sense in an angel-themed set. Two, and this is equally important, it helped cement a key concept in players' heads. Miracles aren't planned. They happen at unknown times and do great works. The right context made players understand how to use them. It taught players to focus on the draw. It turned the mechanic into a moment that happened before a player picked up the card from the top of the library.
Piggyback to the Future
Now that I've explained what piggybacking is, let's talk a little about how a game designer needs to use it. Piggybacking is a tool to lessen instruction by frontloading information in the player's brain. A good metaphor for how to use piggybacking is, in fact, the concept of a metaphor itself. I want to explain something to you but I know the idea is foreign to you. To bridge that gap, I compare the thing I know you don't know to something I know you do know.
This is key because humans embrace familiarity and shun unfamiliarity. A metaphor says to the listener: this new thing isn't really new; it's just like this thing you are already comfortable with. As a frequent user of metaphors (I never metaphor I didn't like), I know when I've succeeded because the response is always the same. When the metaphor works, the listener always goes, "Oh." That "Oh" is the listener's internal processing converting something unfamiliar to something familiar.
Metamorphic Wurm | Art by Thomas M. Baxa
Piggybacking is trying to do the same thing except there's no stop-gap. The game designer chooses something such that the first time the game player encounters the thing in question, the pre-existing knowledge is there as a guide. Here are a few questions a game designer has to ask him- or herself when building something new:
When choosing how to represent an element of the game, did you choose the item that best epitomizes what is most important about that element?
George Fan understood that the invaders in Plants vs. Zombies had to be large in number, not too bright, and very slow. Zombies epitomize every quality I just mentioned. Better yet, it makes all those elements feel like one thing rather than three. Zombies do an excellent job because they take these disparate elements and turn them into a single unit.
I often talk about "chunking"—the brain's shorthand for remembering things by connecting them into single units. Piggybacking is just a very efficient way of chunking. When used properly, it allows the gamer to condense a number of concepts down to a single concept.
If you are unable to capture everything, did you prioritize the one thing that most confuses players?
To use Plants vs. Zombies again, the defenders had numerous qualities necessary. George figured out, though, that the most confusing thing was the idea that units had to lock down to location. As I explained, George had played other tower defense games where the designers didn't worry about that quality and it rang false to him.
Note that plants do an excellent job of communicating lack of mobility yet are not good at communicating defensive force. George was less worried about that because he believed he could convert plants into defending creatures in a way that the player would accept. Plants don't normally shoot peas, but the concept, along with the graphics, easily communicated it.
The important point here is that you can't always have perfect piggybacking. When that happens, use it to plug up the area that will most lead players astray.
Do the different elements of your game piggyback together?
Piggybacking is a powerful tool not just to explain elements' functions but also to explain their relationship to one another. For example, Scars of Mirrodin block used a disease metaphor for the Phyrexians. Their main two mechanics were infect and proliferate. One inflicted the disease and the other spread it. Having both mechanics play into the same metaphor helped define not just the mechanics and their relationship but it also gave the Phyrexian race a feel.
The lesson here is that your game is a cohesive whole. Your choices of piggybacks do not live in a vacuum. The more you relate your different piggybacking elements together, the easier you make it for your whole game to be comprehended.
Have you allowed your piggybacking to impact your design?
Piggybacking can often help a design evolve. Let's say you find something that ties certain elements together but isn't complete in its connection. Sometimes the right call is to shift your mechanics to match your piggybacking. For example, when I handed over the Innistrad design to development, I had the Vampires in black and red and stated that I wanted the Vampire deck to be the aggressive tribal deck of the set.
Erik Lauer (the set's lead developer) took the idea of the Vampires' aggressiveness and found a mechanical way to represent the vampires feeding (using the Slith mechanic—getting a +1/+1 counter for dealing combat damage). He allowed the concept that piggybacked the creatures to guide him in adapting the design.
Piggyback in Black
The important lesson is that piggybacking is more than just a tool to teach the player; it is also a tool that can help shape your design. Things that naturally fall together will both help players "get it" and will give your game a more cohesive feel.
That's all the time I have for today. I hope my illumination of this design tool was helpful.
Join me next week when it's time for the annual State of Design.
Until then, may your zombies be slow.