Pacing

I have always found very hard to weight the importance of a good pacing within a game. In other forms of entertainment such as shows and movies, pacing is essential; so much, in fact, that whole tools have been developed in order to optimize it and many studies can be found on the subject. However, it doesn't seem to be one of the deciding factors on a game's success, and many examples of top-selling games are totally awful at it. I personally prefer games that don't drag, so I'll devote this article to the study of pacing.

What is pacing?
Pacing is the behavior of a flow of events accross the time frame (in a game's case, a game session, from startup to end). Proper management of pacing keeps players interested, builds the mood, smooths gameplay, and sets the duration of a game in advance. A peculiarity I discovered reading reviews of succesful games with bad pacing is that they tend to polarize players: players who like them do really, really love them; those that do not hate them absolutely. Maybe love is a requirement to enjoy games with this property?

Which aspects affect the pace of a game?
The most relevant aspect, without a doubt, is the number of players. This poses a problem for games that allow a variable number of players, as things that work well for a low number of players might not work so well with more (and vice versa); other relevant aspects include ammount of variables and calculations handled by each player, frequency of corner cases, and the game state favored by the mechanics. Let's see how to address them to obtain a smooth gameplay.

1. Number of players:
Most games are tuned for a certain number of players: playing with less can unbalance the game towards one player if they play different roles, and it also can cause slow-down if the game features:
- collaboration: less players means less resources at start and slower adquisition of resources, so overcoming obstacles as a group will be harder and take longer, moreso if there are restrictions in how/when can players help each other.
- "stallbreakers": If the game expects players to randomly adquire certain objects that are vital to continue playing, cutting players might reduce by a lot the chances to find them early.
An excess of players increases the waiting if the game uses non-simultaneous turns, and also brings trouble if the game features:
- countermeasures: the more players, the more likely one of them will have something to counter the actions of the leading player, stalling the game ad infinitum; This effect (known as "King bashing") is more pronounced if players can constantly refill used resources.
- single elimination: not only it takes longer to finish a game, but also losing players must await more time before the next game starts.
- resource hog: If limited resources must be divided among more people, it might happen that nobody has enough power to overcome the first obstacles, lagging the game start.

PROPOSED SOLUTIONS:
- Narrow the number of players allowed.
- Tune the game for a number between the maximum and the minimum.
- Set different starting setups for different number of players.
- Set different game modes for different number of players.

2. Ammount of Computation required:
A task that can be very time consuming is keeping track of a value, specially if it's the sum of many elements or a function of other values. Halting the game a couple of seconds to perform some basic calculations is not a problem, but when the value has to be recalculated continually every turn the game slogs considerably. One example of such a task is resource management. If goods can only be adquired at certain times, all planning has to be done in advance, and must cover all actions up to the last purchase. In unforgiving games, that can make for very long turns.

PROPOSED SOLUTIONS:
- Avoid having to perform calculations in advance.
- Put a limit in the number of elements to consider in a sum.
- Use only easy to add values like 0, 1, 2, 5, and multiples of 10.
- Avoid complex calculations such as multiplication and conditional bonus.
- Use a more flexible/simple resource management system.
- Minimize the number of resources to track.

3. Rules complexity:
"Rules-heavy" games require a lot of time before startup, and if they are not played frequently, players will have to read the rules every single time. Another issue happens when a game scenario hasn't obvious, clear or intuitive answer, which requires to stop the game to look up the rules to handle it. If the game has many corner cases, it's likely the pace will be broken many times.

PROPOSED SOLUTIONS:
- Streamline rules to cut corner cases.
- Simplify the rulebook, or include a simplified rule set plus a bunch of optional rules.
- Move element-specific rules from the rulebook to these elements.
- Include redundancy and/or reminder text in places that might create doubts or corner cases.
- Distribute between players the task of taking care of certain rules.

4. Favored game state:
Some mechanics and implementations of a mechanic are known to favor hang-ups and stalemates. Knowing about them will help avoiding these common pitfalls:

- Random acquisition of basic resources: If some basic elements of the game are obtained through a random event, players will get stuck from time to time due to pure bad luck.
PROPOSED SOLUTION: Include a non-random method to obtain the resource at startup, or if the player doesn't have any. For example, if a game requires to roll a 6 to get a pawn, it may include a rule to allow player without pawns to get one without rolling.
- Destroying/Spending Resources: Mechanics that destroy/waste multiple basic resources can severely stuck players if those resources don't recover as fast.
PROPOSED SOLUTION: Reduce the quantity of elements implementing the mechanic and limit their effect and/or power. Elements that waste multiple resources should be rare and worthy.
- Defensive Imbalance: If answers are more powerful, abundant and/or efficient than threats (for example, in many versus one scenarios), the use of these actions will be discouraged until enough power to overcome the answers is achieved, which can take a lot of time or even never happen (a stalemate).
PROPOSED SOLUTION: Limit the occurrence of many versus one scenarios, if the problem is mechanical, fix the imbalance in the implementation, add "stallbreakers" for when the game lasts too long.
- Adding costs to Basic resources: The best way to discourage the use of something, is to attach it a cost. That's why the most basic resources of a game tend to be the cheap. Because they are required to advance the game, putting a cost on them tend to create stall situations.
PROPOSED SOLUTION: Include ways to access those resources without a cost. Reduce or remove costs from basic resources. Use a different mechanic.

That was all! I hope this study helps in designing better, smoother games. If you enjoyed it, post your thoughts on the comments.

So... what do you want to accomplish?

Let's assume that you get enough energy to create a card game from start to finish, and you are eager to sit down and start writing cards in your notebook. That's a conceivable scenario, and in fact, almost everyone I know started this way, including myself.

Now, although that's a perfectly valid way to start a game, you might want to ask yourself beforehand if that's what you really want to do. You might be wondering why. Hadn't I assumed at the start that you wanted to create a game, afterall? Well, this is because there's something that you might not have considered yet: while you wanted to design a game, the question is, which one?

Before going deeper on the question, I'll discuss some concepts about game design. Games are composed by a set of rules, wich form the game's internal structure. These rules define what the game resources are (be them be cards, points, dice, or any other with which the designer comes up), and their meaning. The logic conclusion is that in order to start designing cards, you need to abide to a certain set of rules.

Now, most people don't spontaneously decide to create a card game. What it happens is that they find a card game that they enjoy, and this is what gives them the idea of making their own. Because of that, they are inclined to adopt the set of rules of the original game, with maybe some small changes to adapt it to their personal tastes. The problem with this approach is that it limits too much what can be done with the game, so the end result will be very similar to the original source. Is that what you want to accomplish?

When working with a source reference, you can make changes to it at different levels of abstraction. The higher the level, the more impact the change has in the game, and the more different they will be in a subjetive scale of likeness. Each type of change has its advantages, and it's more adequated to a different kind of project. Here's a brief description of each one that I have improvised, ranging from most concrete to most abstract:

Type of change: Tweak.
Description: This is the most basic (low-level) change that can be done to a game. Tweaks include adjusting values to cards to maintain game balance, flavor changes, polishing the wording, and adding and removing cards to the game. Changes to the game rules are minor (if at all), and no new zones, resources, nor fields are added or removed. The nature of these changes is so basic that the result is still perceived as the same game, but they are nonetheless important. They can be the difference between a fun game and an unfun one.
Good for: New editions, new attempts at getting a game published, expansion sets, clones.
Not so good for: compilations, new games.
Skills required: Common sense, attention to detail, experience with the game.

Type of change: Variant.
Description: Tweaks played according to the game rules, variants play with the game rules. Variants tipically change the starting configuration, and can also add or remove game zones. No new systems are created, but sometimes some systems (for example, a "combat" system) work different. Still, the source game is still easily recognizable in the final product. Because they require little work and knowledge, most designers start either with a tweak or a variant of their favorite game.
Good for: New game modes, mods, spin-offs, compilations.
Not so good for: Expansion sets, showing your talent as a game designer.
Skills required: Out-of-the-box thinking. Ambition.

Type of change: Redesign.
Description: Tweaks left the game rules untouched. Variants changed some rules, but the systems remained constant. Redesign, likewise, changes the systems, and only abides to the fundamental concepts of the source. That way, it takes advantage of all the elements that made the original so good, without tying the designer to the old design.
Good for: Look-alikes. New games. Sequels. Publishing lines.
Not so good for: Spin-offs.
Skills required: Creativeness. Design skills. Abstract thinking.

Type of change: Departure.
Description: At this level of abstraction, changes can be made to the fundamental concepts of the referenced game (some examples of them are bluffing, diplomacy, or tactical battle), so that the game doesn't have to use the same. In fact, the only limits here are the fundamental aspects of card games. Working at this level, you don't even need a reference game, so the only practical reason to have one is to take away from it the concepts that don't work, or to create something completely different to it. Of course, this new game will have to stand on its own, and it's not easy working at such high levels of abstraction. A mistake here means that the game will be broken beyond repair, as it will have a fundamental flaw that cannot be corrected.
Good for: Basis for follow-ups. Avoiding comparisons. Showing your talent as a game designer.
Not so good for: Sequels.
Skills required: Abstract thinking. Vision of the global picture. Talent.

And that was all! I didn't thought it would take so much text, hope the next entries are much, much shorter.