Theory: Compartmentalize Costs

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:

8-17-15 - Yog.0

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:
11-14-14 - Hearthstone Card

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. 😉

Advertisement

Theory: Doing RPS Right

Rock-paper-scissors (“RPS”) dynamics are sometimes held up as fundamental to game design, a core principle that makes balance possible. Taking rock-paper-scissors too far, however, can lead to reductive games that are only interesting during character selection. It’s vital to understand that what’s interesting and valuable isn’t the RPS, but the interesting decisions a good RPS setup can contribute to.

The Story So Far

To my knowledge, the popularity of RPS comparisons in game design started with an article on Sirlin’s old website. It’s worth reading the article in full (and I’d love to see it preserved on the redesigned site), but his core argument went something like this: rock-paper-scissors, as we all played it as children, has little to no strategy because there’s no basis for preferring one move over another. The opponent is probably choosing more or less at random, so there’s no way to predict what he or she will do, and you’ll just have to play randomly, too. However, it’s possible to inject strategy into rock-paper-scissors by giving each move different payoffs; if rock is worth 2 points and everything else is worth 1, you know that both players want to play rock, and you can use that knowledge to craft a plan.

Sirlin followed up with another article, this one on how RPS is implemented in fighting games. Again, it’s excellent and well worth your time (and also worth preserving). While I can’t trace the spread of its ideas, I can say that this article was extremely influential among fighting game players, and that in the years since its publication I’ve seen its arguments and conclusions repeated many times. I think it’s fair to say that after this article, RPS was off and running.

Today, RPS has become ingrained in game design thinking. However, saying that RPS with differing payoffs can be interesting doesn’t mean that it’s always going to be executed correctly. In particular, it’s not great when the only meaningful RPS decision is made early.

RPS Done Right: Interesting Decisions that Support More Interesting Decisions

Go back to Sirlin’s second article for a moment. He describes a series of situations in which both players make a choice, and one of them just loses. Attack beats throw, period, with the attacker doing damage and the thrower accomplishing nothing. It’s a hard counter, just what we would expect from RPS: rock doesn’t sort of beat scissors, it SMASHES scissors and gets ALL THE POINTS.

However, that decision isn’t the be-all and end-all of the match. Rather, a match will involve many such choices. Indeed, much of the interest of the game comes from the choices building on each other: “last time he went for the throw and got me, I think he’ll try that again even though it doesn’t do as much damage as an attack.” Evaluating moves becomes a multi-layered process, as one judges not just their value in the abstract (rock is worth 2 points) but also how the opponent seems to be responding to those values (this opponent is being tricky by playing lots of paper).

We see the same building of decisions in other good RPS games. Starcraft, for example, has units that beat other units—but players build many units over the course of a game, and can expect to skirmish several times before the match is decided. As a result, players will make a number of important and engaging building decisions. Over the course of a game one might shift gears in response to what the opponent is building, feint, condition the opponent to expect one thing before building something else, and otherwise make interesting choices throughout the game’s duration.

Magic has only one RPS decision, but it still uses that choice as a springboard for more decisions later. It does this by incorporating RPS into an important, but not definitive, early choice.

It used to be said that there were three broad strategies in Magic, and that they interacted in RPS fashion:

Aggro (“aggression”) beat Control, because it won before control could lock down the game.

Control beat Combo, because control stopped combo from assembling its Rube Goldberg victory condition.

Combo beat Aggro, because aggro didn’t stop combo from assembling the Rube Goldberg machine.

While the model spoke in definitive terms, however, making the right choice at deck selection (e.g., playing aggro against someone who was playing control) never actually decided the game. Rather, it provided an advantage which had to be carried through in play. The player on the winning side of the RPS decision still had to manage random card draws and the opponent’s resistance, which could still be potent even coming from a position of disadvantage. Making a good RPS choice thus offered advantage but guaranteed nothing, and so the game’s in-play decisions remained meaningful.

RPS Done Wrong: One and Done

For a contrast to Starcraft, Magic, and other good RPS implementations, consider a fighting game where some characters beat other characters RPS-style. That might be balanced. If Ryu beats Zangief, Zangief beats Dhalsim, and Dhalsim beats Ryu, then everyone has about an equal chance of losing and the game is fair.

However, that game has only one important decision: which fighter to choose. It’s all downhill after that, as one plays out the inevitable result of the character select RPS. None of the decisions in the actual game are very interesting, because Ryu is just going to clobber Zangief no matter what their players do.

Weighted RPS mechanics, then, are not an inherent good. They can in fact be very dangerous, locking in results and turning the rest of the game into going through the motions. If RPS is going to be used, it’s critical that the game not hinge on a single, early RPS choice, but rather that the RPS decisions create further interesting decisions as the game goes on.

This problem is not strictly theoretical. Several miniatures wargames have wrestled, or are wrestling, with the problem of an early RPS choice that dominates the game.

Minis games’ RPS issues revolve around how in-game armies are built. Broadly speaking, minis games have a system wherein heavy armor (tanks, flying tanks, whatever the game’s setting has) is largely invulnerable to infantry; infantry is good at dealing with anti-armor specialists; and anti-armor specialists destroy heavy armor. As a result, games can be decided as soon as the players show each other their armies; if one player has way more tanks than the other player has anti-armor specialists, the tank player will pretty much have the run of the field. It’ll be particularly egregious because that game will probably still take two hours to finish; two hours is a long time to have no interesting decisions.

We’ve seen a number of solutions to this problem over the past decade: allowing pieces to serve in more than one role so that players can always use all three of rock, paper, and scissors, for example, or trying to opt out of the RPS situation entirely by flattening the differences between armor and infantry. I’m sure we’ll be seeing more in the future. Even if the problem is entirely solved, however, its persistence over many years will stand as a reminder that leaning on the RPS tripod can leave a designer flat on the floor.

Keep Your Eyes on the Prize

Rock-paper-scissors isn’t the ultimate in game design; it isn’t even a good summation. What it can be, if done right, is a source of fascinating choices for players. The key to using RPS well is to always keep focus on the decisions, asking whether the RPS is making them more interesting—or less relevant.