Tom used to be a lawyer. Now he's a game designer. The two have more in common than you think.
As a rule I’m not a fan of Twitter as a platform for argumentation. It’s often hard to express something compellingly in 140 characters. Sometimes it’s not even feasible to break an idea up into 140 character chunks.
Kevin Wilson (designer of, inter alia, Netrunner) was nevertheless able to make a strong case on Twitter today. Since tweets have a way of being lost–like, sadly, so much game design theory–I thought I’d keep them here for future reference.
Costs in games are a double-edged sword. It’s easier to balance games with more costs associated with their cards/pieces/etc., since there are more knobs to turn. Yet, the more costs there are, the greater the player’s mental overhead. Adding more costs can be valuable, then, but they should be compartmentalized so that the player only needs to think about one or two of them at any point during the game.
FFG’s Netrunner is a superb example of compartmentalizing costs. Take a look at this Netrunner card, which represents a program used by the game’s hackers:
This card has three costs. First, there’s a monetary cost to put the card into play (the 5 in black in the upper left). Second, the program has a memory cost, denoted by the 1 in a chip just to the right of a monetary cost; players can normally have up to four memory’s worth of programs in play at a time, and this takes up one of them. Finally, the single pip in a row of five at the bottom-right indicates that Yog.0 costs one influence during deckbuilding.
Having three costs (separate and apart from the fourth cost to use the card’s ability) is a lot. Fortunately, Netrunner lightens the player’s load by putting the costs in separate game-stage compartments. Influence is only relevant while building a deck, and never matters during play. Cost and memory might influence deckbuilding, but they don’t have a rules-based role at that stage; they only need to be tracked precisely later, while the game is in progress. This compartmentalization means that the player only ever needs to track a maximum of two costs at once.
Of course, even two costs is enough that mistakes can be made. I once saw a video of a tournament Netrunner match in which a player had five memory’s worth of programs for the better part of the game. Neither player noticed.
Like all design rules, the rule of compartmentalization has exceptions. Starcraft, which effectively makes attention a game resource, is perhaps the classic example: we’ve all been told to “SPAWN MORE OVERLORDS” because we forgot to check how much available supply we had left. Starcraft is a fast-paced game that’s intended to test your ability to divide your focus and juggle lots of things without dropping any of them, and satisfying many costs (minerals, gas, supply, build time) is part of the challenge.
At the far side of the spectrum from Starcraft is Hearthstone:
One cost, noted in the gem in the upper-left, with a computer enforcing the rules so that you can’t forget to pay it. This is great for the more lighthearted game that I have the sense Hearthstone is meant to be, though it does put a lot of weight on the designers, who have fewer balancing knobs to turn.
Fine-tuning balance makes a designer want more costs–but every new cost is one more thing players are going to have to keep track of. Be mindful of how much effort players are being asked to expend dealing with costs, and compartmentalize them to make things easier–or, if you’re going to go the other way, be sure your game is as amazing as Starcraft. 😉
One of the things I love about Netrunner is how the game expresses complex ideas using core mechanics. A given card will use the exact same mechanisms as lots of other cards, but still have something it uniquely, convincingly represents. Each such card is a masterwork in miniature, a perfect building block for a remarkable game.
By way of example, take a look at Yog.0.
Yog.0 is a simple card—and an amazing design. The italicized flavor text gives us the thematic background: this card represents a tool for hackers, a database containing lots of stolen passwords. While that might seem pretty complicated, Yog.0 only needs two bits of text to fully express the concept.
To see how that’s true, let’s imagine how such a database might work in practice. The player is in the role of a hacker, and the card represents a list of passwords. If the player-hacker needs to break through security and the relevant password is listed, there’s no additional cost in time or money. She has everything she needs. If the password doesn’t appear, however, the database is useless; she must use a different tool.
Both of those aspects are represented on the card. The first is contained in the line above the italics. Without getting into the technicalities of what it means to “[b]reak” a “subroutine,” it’s clear that the player-hacker gets to make progress for a cost of zero. Furthermore, since it costs zero the player-hacker can do it as many times as she wants. Both of those are what we expect from using a list of passwords; so long as the password is in the database, the player-hacker can keep right on going, no additional input required.
Of course, it’s also important to capture the situation where the password isn’t there. That’s handled by the “3” in the lower-left corner. In Netrunner, every security system has a strength. Getting through requires a hacking program of at least equal strength, as noted in the lower-right corner.
Yog.0 has a strength of 3. Right there, we can tell which passwords are on the list. The password to get through this is:
But to have the password for this, Yog.0 would need a strength of 4. It doesn’t, so we know right away that this password is missing.
All of that thematic information, in one line and one number. Yog.0 doesn’t rely on its italicized flavor text to put across what’s happening; we can feel it as we rush through one code gate after another, effortlessly putting in the necessary passwords. We can also feel lit in the sudden stop when we run into something we don’t have the password for!
Compare how Yog.0 works to more complex alternatives. Password tokens could be put on code gates, and Yog.0 could come with some; a match means one can get through. We’d have to keep track of all those tokens, of course. There might also be a need to accumulate more tokens; that could be a minigame, with the player-hacker stealing new passwords. Stealing passwords doesn’t directly advance the player toward winning, though, so there need to be adequate incentives for participating in the minigame. That implies a development issue . . . .
Ack! Thematic design can very quickly lead down an incredibly complex road.
Yog.0, like many of Netrunner’s cards, is brilliant because it avoids that trap. It has all of the thematic power with none of the rules bloat. That’s the gold standard for thematic components, and the key to an elegant, yet thematic, game.
So you’ve designed a game where it’s hard to transition from reading the rules to playing intelligently. Maybe the player has options whose import–the “why” as distinct from the “what”–aren’t clear just from reading the rulebook, or perhaps the game is just too complicated for new players to be able to devote much thought to strategy. Everything is fine once someone is invested and has discovered the game’s tactical nuances, but the learning curve is more like a cliff. How can you help new players understand their choices, so that they don’t just quit in frustration?
There’s an often-overlooked solution: simply tell them.
GMT makes Fire in the Lake, its excellent-but-complex simulation of the Vietnam War, approachable using that exact method. Fire in the Lake has two big humps in its learning curve: first getting through the dense rulebook, and then understanding how the rules are applied on the tabletop to make progress toward winning. By being straightforward about what each maneuver is intended to accomplish, GMT gives players a tremendous boost over the second hurdle.
You see, there’s a lot for new players to take in when they start to learn Fire In the Lake: four factions, each with their own victory conditions and unique actions. It doesn’t get easier when one considers that each action has multiple parts. A US player, for example, can assault with her own troops in any of several locations (which costs no resources), then has the option of forcing her ally to attack (which does cost resources). How many pieces are removed by the assault depends on who’s attacking–the US or her ARVN ally, the terrain, and whether or not the US has established a base at that location. The US player also has three other actions she can take, plus three additional helper-actions which can’t all be combined with all of the main options. Her choices are also, by the way, contingent on the monsoon.
As you might imagine, it’s not easy to see the forest for the trees at the end of all this. After going carefully through the rulebook before my first game I was so busy juggling the technicalities in my head that I wasn’t sure how to fit my choices together into a strategy. Then I looked down at the player aid, and saw this:
Having the execution details of a patrol–the cost, where patrolling troops can move–was useful. The greatest value, though, came from that first line: “Purpose.” Here’s why you would do this; you’ll get the following out of it.
All of a sudden it was possible to make meaningful decisions. I had been getting ready to take actions “just to try them out,” accepting that the match would basically be an extended tutorial. Equipped with some basic information about what I could expect from each action, however, I was able to pursue a coherent strategy right away.
It’s worth pausing to reiterate that. A few lines on the player aid saved me from a four- to six-hour tutorial, and launched me right into the exciting part of the game. Those couple of sentences granted an enormous return in player engagement.
Fire in the Lake isn’t the only game that can benefit from explaining when and why certain moves are useful. Consider, for example, chess. The rules of chess are quite simple. Even small children can easily learn the game.
However, the strategic implications of the choices available are complex and often opaque. On his first turn a player can move a pawn, or jump with a knight. When is one better than the other? Why? If he should move a pawn, which one? How many spaces forward? I’ve never heard anyone say that they stopped playing chess because they couldn’t learn it, but I’ve heard people say that they just found it overwhelming.
Now imagine how much more accessible chess would be if every set came packaged with some basic information about what various moves accomplish. This opening brings the bishops and rooks forward to useful positions; that maneuver threatens the opponent’s pieces. Suddenly the player could to evaluate positions, at least in a simple way, and make informed choices. If he wanted to bring the bishops and rooks forward, he might try these moves; if he preferred to get his queen involved, he would at least have an example of what not to do.
Of course, that sort of information is readily available; there are any number of chess resources out there. Seeking them out, however, requires a level of investment that cannot be assumed of new players. When the problem is getting players engaged in the first instance, there’s no better solution than putting valuable help in the one document they’re most likely to read: the rulebook.
As always, this is not a tool suited to every game. Twilight Imperium 3rd Edition doesn’t need to expend energy telling people what the “Warfare” and “Production” roles are for. Netrunner can safely assume that everyone will understand the use of “purge all virus counters.”
When there’s a divide between a game’s rules and its strategy, however, a little explanation can go a long way. Helping players out with a brief statement of how each option might contribute to a strategy does a great deal to bridge the gap between reading the rulebook and having fun with a game. If nothing else, it avoids four- to six-hour tutorials!
The Law of Game Design 