Which Comes First?

Back Story and Game Mechanics in Game Design

Originally From Chief Herman’s Holiday Fun Pack, Cheapass Games 2003

What is a game’s “back story”? It’s the description of the game world. It tells you who the players are, what they are doing, and why they are doing it. It’s not the rules or the mechanics, just a story that helps the rules make sense and makes the players want to play the game.

The back story in Chess, for example, is basically “Players control two kingdoms at war.” It’s not much, but this simple description makes some of the rules, like the piece names, the board layout, and the victory conditions, easier to grasp. It’s also not perfect, but at least it’s a better story than “Five gardeners must eat one peach.”

A lot of games don’t really need a back story: Poker, charades, baseball, tic-tac-toe. Those games are entirely about the pieces or the players or the strategy, and slapping a storyline onto them wouldn’t make them any better. “You and your opponents are smooth-talkin’ space cowboys tryin’ to collect six different ‘color crystals’ by visitin’ mysterious robed hermits who ask trivia questions” wouldn’t lend a whole lot of quality to Trivial Pursuit.

On the other hand, some games are swimming with back story. Despite all of its charts, tables, and rulebooks, Dungeons and Dragons would be pretty meaningless without the story. In most role playing games, the mechanics exist simply to support the storyline, and players have no problems adjusting the rules of the game if it will better serve the story.

Ideally, the back story of a game shouldn’t just be an add-on to the rules. It should convey the rules. A back story can explain what you’re doing, and it can cut the rule book in half. On the other hand, an incongruous story can be worse than none at all.

Here’s an example. Let’s say I’ve written a new fighting game, in which the object is to beat the stuffing out of the other players. The last person left alive is the winner.

Every time you damage somebody, the life points they lose get added to your life points. But you can’t hit people directly. Instead, you leave little land mines around the board. Building a minefield hurts you, but once you’ve made it, it will damage the other players whenever they land on that space.

Land mines have different strengths depending on where you drop them. What’s more, you can take a little more damage later on to make your land mines more potent, but not until you have laid a series of minefields within two or three spaces of each other.

Now, this next bit doesn’t make too much sense, but bear with me: if you’re nearly dead, and you need extra life points, you can deactivate some of your land mines in exchange for healing a few life points. Or, and this makes even less sense, you can agree to trade control of one or more of your minefields in exchange for a free direct hit on any opponent, if they agree. 

You can set up a variety of other combinations of free hits, and/or other exchange of control of land mines elsewhere on the board between yourself and any number of other players. And you can pretty much do that at any time, not just on your turn.

This is only a fraction of the rules, but I hope you’re already confused. Or perhaps you’ve figured out that I’m describing Monopoly. Now, if your status is called “money” and not life points, all those ridiculous rules suddenly make a lot more sense. “Land Mines” are called “Properties.”

When you pick up Monopoly for the first time, you don’t have to read a story, much less the rules, to figure out what the game is about. Why? Because it’s about money. That stuff everybody wants. If you run out of it, you probably lose. Buying and selling rental properties makes all the garbage I just told you make sense. Mostly.

Is it conceivable that a game designer (or, more likely, publisher) might produce a game that’s as counterintuitive as the combat version of Monopoly I just made up? Absolutely.

I recently played a “Pirate” game that was not about Pirates. I won’t name it, but if you’ve played this game you’ll recognize it from this description.

In this game, players are trying to capture ships. Arrr. Shiver me timbers. Good so far.

Here’s how you capture a ship: you have a handful of commodities, like wheat, beans, rum, and so on. Each ship has a specific list of these things: two rum and three wheat, for example. Each player in turn plays cards next to a ship, until one of them has played the exact list of commodities required to take that ship. At that point, he can roll dice to try to capture it. (There are also actual pirate cards: you can play them beside your commodities, but the number of pirates you can play is limited by the number of commodities you’ve already played.)

When one player tries to capture the ship, everyone else can play commodities out-of-turn to also try to take the same ship at the same time, as long as they’ve already placed at least one commodity beside that ship.

Sound good? There’s more. You can discard commodities from your hand to try to dislodge the commodities that other players have placed on their sides of ships, to keep them from horning in on your boarding actions. This requires a die roll, so sometimes it works, and sometimes it doesn’t. Just like in real life.

There is often a point in learning the rules of a game where I am forced to remark, “Just like in real life.” This was it for me.

My interpretation of these rules is that, during the Golden Age of Piracy, the most dangerous scalawags of the Spanish Main were two kegs of rum and a bag of rice. Wild rice.

Did the designer of this product write a pirate game? Probably not. This game probably makes sense if you’re a stock broker, or a barber, or five gardeners trying to eat a peach. Or perhaps this game was originally about nothing, and had a story applied to it. That happens a lot.

Now, if you’re the designer of the Pirate game, you’re probably feeling a little defensive right now, and asking me where I get off making games like Devil Bunny Needs a Ham and complaining about game themes that don’t make sense. Although there are better examples of badly themed games in my ludography (Particle Stream leaps to mind), Devil Bunny is the one that most people ask me about.

Here’s the answer: Devil Bunny is about climbing a building. Actually, it’s about a cadre of wily sous-chefs racing to the top of a tall building while Devil Bunny tries to knock them off, erroneously believing that this will earn him a ham. Most of that is fluff, but the game is basically about climbing a building and the mechanics actually reflect that. And (this astounds most people) I actually did write the story of that game before I wrote the rules.

I think story is so important to a game that I usually insist on writing the story first. I’ve made a lot of games, so there are exceptions. The main exceptions in my catalog are the games that are strictly themeless, the ones where I point out the stupidity of the story (“Just like in real life”) as I do in Particle Stream, and the notable exceptions of the dice games Diceland and Button Men.

I like themes in games for the same reason that the publisher of the Pirate game does: theme sells. I’m not just talking about getting a player’s money. I’m talking about getting his attention. The biggest expense in picking up a new game isn’t really the money you pay for it; it’s the time you take to learn how to play. Most people would rather not spend half an evening learning a new game. I can get players to invest more time by getting them hooked with a story.

I recently attended a lecture by a famous and prolific game designer whose back stories often seem to fall into the slapped-on-at-the-last-minute category. A member of the audience (not me, I swear) asked him the leading question, how important is theme to your design process?

His answer was interesting: he said it was very important, that he always started with a theme. But he also said that, as the mechanics evolved, the theme often changed three or four times. We all chuckled uncomfortably.

He also gave an example of a game he’d sold to a publisher. When he turned it in, the game was about the Mafia. It was published as a game about teddy bears.

This seems to point some of the blame at publishers, not designers, but it seems like a game that is genuinely crafted to simulate one set of rules shouldn’t be so easily perverted into something else. Thinking about it, I can’t actually think of anything that makes the rules of the Pirate game make any sense. It’s probably what I like to call a “math game,” a purely abstract game mechanic that any slapped-on story can’t make sensible. The fact that these games emerge with no basis in reality makes adding a theme later on a really tough assignment. Unfortunately, in some game markets, publishers can’t distinguish between a genuinely themed game and a math game with a story.

I suppose I have the luxury of being both the publisher and the designer, so when I write a game about lazy adventurers who sneak around London pretending to be voyaging to the South Pole, it’s not unexpectedly published as a game about chipmunks holding a bake sale.

If you’re a game designer, I hope you take the time to create games where the back story and the game mechanics actually match, or just admit at the beginning that the game has no story at all. That way, when I play it, I won’t find myself slapping my forehead and crying out in a stout voice, “Just like in real life!”

Portions of this article originally appeared at Envelope Games