Guest Post: The Basic Elements of Solo Variant Design
/By Mike Mullins
The recent rise (or perhaps simply the acknowledgement) of solo gaming has caused many designers and publishers to consider adding the “1” to their game’s player count. While unofficial solo variants have long existed on the BoardGameGeek forums, there is now a wonderful push to put those rule sets in ink.
Apparently I’ve produced enough of said rule sets that some folks are interested in my approach. For this article, I’ll walk you through my thought process from the very moment I'm presented with a new project. Specifically, we’ll look at how to extract the key elements of the multiplayer experience that you must capture in your solo variant, as well as discuss the basic solo structures like score attack modes and artificial opponents.
What Are We Dealing With Here?
The single most important step when creating a variant of any kind is to pinpoint the crux of the game. To broad-stroke things, there are a handful of different win conditions a game might employ.
Finish an Adventure: Most adventure games, whether co-op or not, have a clear objective that is readily translatable to solo play. It's rare that major changes are required, so let’s assume you can handle this one on your own, OK?
Satisfy a Condition: The objective here isn’t “kill the goblin king,” but “have 10 cards in your hand” or “deplete your opponent’s life points.” This is much more complicated because you must also identify the manner in which opponents impact your progress.
Win a Race: Whether you are referring to a VP goal or an actual finish line (which, by the way, are the same thing), this type of solo game is inherently challenging because you must find a way to put pressure on the player.
Avoid Elimination: This can be the primary focus of a game, but often appears as a secondary element designed to increase tension during a game.
OK, So…
Putting your finger on the goal isn’t particularly difficult, but it’s a necessary first step. Let’s continue along this road and examine the ways that an opponent can mess with you. (You’ll immediately notice that I overuse bulleted lists.)
Direct, Instant: Lightning Bolt. Lose 3 life. How can this be effectively replicated in a solo game? Does the card actually have to show up? Is there a condition that must be met, such as one red mana?
Direct, Transient: “For the next two turns, hand limit is reduced by one” is a surprisingly vexing phrase. It requires strict definition of a turn’s phases and length, some method of tracking the duration, a set of timing rules, and an effect priority.
Direct, Permanent: Or at least long-lasting. Typically these are cards or effects that last indefinitely but may be removed or replaced by the player at some cost.
Indirect, Limiting Resources: If you’ve understood any of my ramblings to this point, you know what “limiting resources” means. I would, however, remind you that time is a resource.
Indirect, Changing Game State: If you are not satisfied with full randomization, this can be the most involved type of effect to automate. How would an artificial opponent occupy action spaces, swap hexes, purchase cards from an offer, or any other such action?
Didn't You Say Crux?
I did indeed, literary device that's asking me questions. You know a game’s goal, and you’ve looked at all of the player interactions. Now consider the different aspects of the gameplay and ask yourself, “What could I completely remove or totally randomize and be left with a rewarding set of decisions?” There you go, what remains is the crux. Those are the elements that must be preserved in your solo design at all costs.
Gimme Some Stuff!
The most common question I get about this process is, “How do you decide between designing an AI opponent and simply having the player try to attain the best score possible?” This decision is fundamental, but it’s never the first thing I consider. Instead, I always ask the designer or publisher what kind of components I’ll be allotted.
Here's what you might end up with…
Nothing: Maybe there isn't room in the budget, or the game components are final, but you must work with what you’re given. If you were thinking about designing an AI this a huge blow, but not a death knell.
A bit of ink: OK, so you don't get your own components, but you have the green light for some solo-only icons or text on cards. A well thought-out set of icons can carry a solo design.
Cards? For me? Now we’re talking. Depending on how many you’re allotted, you have all you need. Make sure you get a firm number of cards; game balance can depend on the size of the solo deck, or the number of item cards, etc.
Components: Ha ha, don’t tease me like that… Wait, you’re serious? I can make a player board, or some tokens? Maybe even my own custom die? Even a single solo-only component can be transformative, and add an immediate legitimacy to the variant itself. (Publishers, re-read the previous sentence. Several times. Go ahead; I'll wait.)
Hey Dummy, That's Not AI
Allow me one last little detour before finally answering the question that prompted this article. Many (most?) people consider the terms “AI opponent” and “dummy player” to be interchangeable. I suppose that’s true in the parlance of our time, but we really should disentangle them.
Dummy players are much more common; they are easier to design and typically sufficient. Most dummy players replace indirect player interactions, taking away resources, limiting player options, or providing a game timer. Dummies are usually fully random (roll a die, occupy a space) or strictly defined (collect highest value card). Adding a decision tree to “improve” the dummy player is the transformative event that creates AI.
I'm baffled by the widespread distaste of dummy players that allow smaller groups to play otherwise inaccessible games. I can understand preferring an actual human as an opponent or teammate, but if you step back and consider the player interactions as we have, a well-designed dummy leaves the players with very similar gameplay decisions.
Our New Question
Does this game’s solo mode require an AI or a dummy, or can it be left as a simple score attack game? The preliminary answer addresses the type of player interaction within the component design space.
Let’s proceed by identifying the rules, cards, and effects that refer to other players. Can effects referencing opponents simply be removed, or are they integral to gameplay? Can cards referring to teammates or “a player” target the solo player? If questions like these can be addressed by a few sentences in the rules, or solved by the components you’re allotted, an AI opponent isn’t necessary.
Example 1: a heavy Euro that plays as “multiplayer solitaire.” This type of game is easily identifiable because players care very little what opponents do on their turns; at the start of your turn, survey the board and make choices based on available options. At the most, you’d need a dummy to limit player options, but often variable setup conditions can make a rewarding puzzle-type solo mode.
Example 2: the same game, with an allotment of solo-only cards. This decision basically makes itself. Make an event deck that interferes with the player’s plans, and play it enough times to set a reasonable score goal. Quick piece of advice: Not every event can be negative. Include some null cards or even the occasional beneficial event so the player gets the satisfaction of executing a planned turn.
When A Dummy Won't Do
Perhaps your first attempt made it to the table and fell completely flat. Maybe you realized that your concept was lacking something even before you tried it. Either way, it's time to consider Skynet.
It's clear now that the game you're working on needs proper player interaction to work. Completely random opponents may never be able to challenge a player, or they might create an unacceptably altered player experience. An opponent operating under a strict decision tree often turns the game into a solvable puzzle, which you might deem sub-par. Now your job is to adjust the random slider to somewhere in between zero and one hundred percent.
In the next installment, I'll talk about this process, define “acceptable exceptions,” and revisit score attack to discuss an appropriate goal.
Mike Mullins is a longtime playtester and developer, best known for the creation of solo modes for games such as Castle Dice, Lagoon, and Compounded. He and Darrell Louder recently co-designed Bottom of the 9th, which of course is playable solo as well.