When I initially received an email from game designer Keith Baker, I was astounded. Not only is Baker the creator of the Eberron setting for Dungeons & Dragons, as well as the designer of the narrative card game Gloom, but he had also just launched a Kickstarter for his latest game, Phoenix: Dawn Command. I knew he’d be swamped with promoting his Kickstarter, and I am a nobody blogger who got his attention on Twitter and sent him a 750-word email for his trouble. I was working on a story about a growing trend of what I have dubbed “prop-based” RPGs: games that use proprietary elements, such as special dice, unique tokens, or, in Baker’s case, cards. I wanted to know what was behind this trend; in a matter of months, we’ve seen Kickstarters for games that use proprietary decks of cards, like FAITH, Neon Sanctum, and Phoenix: Dawn Command, and there has to be a reason that designers are focusing on cards.
I still haven’t answered that question to my satisfaction, but Keith is such an insightful designer that I’ve spent the past couple weeks reexamining my own beliefs and principles when it comes to game design, specifically around conflict resolution. I’ve previously written about why the rules exist (spoiler: it’s to justify killing the characters when the players don’t want them to die.) Around these parts, MAS’s own dynamic duo, Sammy and Fiddleback, took a run at randomness and PC death on episode 65 the Potelbat podcast back in September (spoiler: everyone hates randomness.) As both a player and gamemaster, I am very much of the crunchy system mastery/optimization persuasion. I have spent hours poring over rulebooks precisely to understand and mitigate the randomness of die rolls in order to assure my character is reliably good at whatever it is he’s supposed to be good at, his “One Cool Thing,” if you will.
I’ve played dozens of different systems using a variety of mechanics: d20s, percentiles, dice pools, FUDGE dice, and whatever you want to call Fantasy Flight’s Star Wars dice. I’ve dismissed some for being to high variance—“swingy” like 40k RPGs—and some for being too low—“curved” like FATE and Dungeon World. Maybe what I’ve been looking for all along isn’t the right mathematical outcome curve of dice blended with the right measure of static modifiers and properly turned target numbers. Maybe what I really want is a slight preview of the next die roll. Maybe what I want is actually cards.
* * *
Most players are intuitively aware of the dice curve in the games they play: the set of possible outcomes on a given dice roll. If you roll a d20, every outcome, 1 through 20, has an equal chance. If you roll 2d6, results tend toward the average outcome, 7. No matter how many times you roll, though, the curve never changes. This static curve means your roll at the beginning of the night has the same odds as your roll at the end.
But cards have a fundamentally different outcome curve. Take a standard 52-card deck: when you first draw from the deck, every card has equal odds. The second card you draw, though, has a completely different set of potential outcomes; namely, it cannot be the card you initially drew. Just like Blackjack, results of two draws are not independent; the information you have about previous draws affects the odds of future draws. Each time you attempt to resolve a conflict by playing cards from your hand, you lose the ability to play that card in the future (at least until the deck is reshuffled.) This is the value proposition of card-based resolution mechanics: over the course of a session, the cards you have available to you are random, but over the course of a single action, you know your capabilities.
Of course, this mechanic creates its own set of challenges. The longterm probability curve isn’t as easily exposed, so adjudication for gamemasters can be difficult. In a d20-based game, I quickly know that a Fighter with +5 to hit needs a 10 on the roll to hit a goblin with 15 AC, so he always has a 50% chance. Using card-based mechanics, I need to account for the number of cards in a player’s hand, the number of cards he’s allowed to play in support of a given action, as well as any situational abilities that allow for more of either. Furthermore, in the course of the game, the probabilities might skew significantly; if the player has already played through a lot of the low or high cards in the deck, a given challenge may be unexpectedly trivial or impossibly demanding.
In many ways, the obfuscation of the probability curve is a major part of the appeal of card-based resolution mechanics. Baker notes that, “it’s a tool that hasn’t been fully explored,” either by players or designers. As someone who tends to pursue system mastery for the games I play, I suspect that obfuscation of the underlying system math in exchange for greater clarity on a given challenge is a satisfying tradeoff. For players who are less interested in the crunchy system bits, they receive that outcome clarity at even lower cost.
Of course, this sort of predetermination also limits the ability of the players to fail, as Baker explains:
Essentially, cards give the players a greater sense of narrative control. If you can’t hit that giant this round you know it, and it then becomes a question of what you can accomplish with what you have.
As a player, this sounds fantastic: succeeding—even at a “lesser” ability—is fun, and few things are more frustrating than never being able to successfully do your One Cool Thing. But it raises more questions that game designers who pursue card-based mechanics like Baker will need to address: is the role of the gamemaster still fun? At what point does ceding too much narrative control to the players sap the GM experience, and how much investment in a campaign can a GM really be expected to commit as his narrative impact wanes?
* * *
In Phoenix: Dawn Command, player characters (“Phoenixes”) don’t gain power by killing others; they gain power by dying. After each death, players add additional cards to their deck representing the lessons their Phoenix learned from his previous life. However, there’s a catch: Phoenixes can only return seven times. So each death makes her stronger, but it also brings her closer to the end of her story. In addition, a Phoenix doesn’t return right away and doesn’t return in the place where she died. This is what drives tension: most missions are time-sensitive, and should the Phoenixes all fall without completing their task, they will fail. When they return, they’ll have to deal with the consequences of that failure. Because death isn’t the end, the odds will often be stacked against the characters; players are encouraged to take risks and to be prepared to make sacrifices. Death isn’t the end, but players want to make sure they make every life count.
In designing Phoenix, Baker has attempted to solve for the high-variance problem of d20-based system using the central conceit of the setting: character death and resurrection. He says, “You don’t have the person attempt something that feels like it should be the most dramatic scene in the movie, only to roll a one” and elaborates:
In a game with dice I can face the undead giant, make a heartfelt speech about my fallen allies, use my biggest attack… and then roll a one. In Phoenix, you still have a random factor in the form of what cards you draw, but that means you know what you are capable of accomplishing in that round.
As an added element of control, tying into the death and resurrection theme of the Phoenixes, players can use their magical energy (“sparks”) to increase their total in addition to using cards in hand, knowing that Phoenixes die when they run out of sparks.
For me, this is a “shut up and take my money” kind of proposition. Here is a game system with the long-term randomness I want, but the short-term narrative control that ensures my character doesn’t crit-fail his would-be most triumphant moment. That the system has such synergy with its setting, and that the setting sounds pretty compelling in its own right, are icing on the cake. I listened to the One Shot podcast’s actual play of a Baker-run Phoenix game, and I backed Phoenix immediately; the Kickstarter ends the morning of May 6th.