We’re huge fans of cooperative strategy games. A well-designed co-op game can keep all the players engaged throughout the game (even when it is not their turn) and is enjoyable regardless of the outcome. These types of games can be susceptible to the bad apple problem, where a bossy or unengaged player can lessen the experience, but we think the risk of that is far outweighed by the rewarding experience of playing with a good group.
We like to classify co-op strategy games based on how the game can end:
While designing Countervirus over the past year, we spent a lot of time thinking about binary outcome co-op games and tried to abstract away all the details to figure out which features are necessary to produce an experience we enjoyed. This is the first of a series of posts summarizing our thoughts on the components of a binary outcome co-op strategy game, which we break out into:
The game end timer
The need for a timer
In one form or another, there is a timer that ends the game in every co-op game we’ve played. In binary outcome games this usually means you lose, but in games with continuous outcomes this is usually when you get your final score. By forcing an upper bound on game length, the game builds up a sense of urgency as it progresses and the players become more aware of the game’s impending end. Not only does that urgency create excitement and encourage the risky behaviors that can improve the gaming experience, it also gives the game the advantage in the long run and wards off trivially optimal ‘slow and steady’ strategies that make the game boring.
Some timer types
The advance of time is an irreversible process, so the timer can be generally thought of as any monotonically increasing (non-decreasing) function of time, turn or some other game mechanic that causes the game to end when it crosses a threshold. For instance, the real timer in Break the Safe, a kid friendly co-op game guaranteeing a 30 minute or less play time, has the most predictable and least controllable timer possible: a clock that sounds an alarm after a half hour of play. Cycle timers, on the other hand, end the game after a fixed number of turns or rounds. They are more forgiving of slower paced players and enable more strategic decision-making while still invoking a sense of urgency. Both of these types of timers are relatively easy to control by the designer because they only have one parameter to tune: how long do you want the game to last?
Probabilistic timers, which are driven to cross the threshold by random events, are an interesting class of timer because they add suspense and surprise to the urgency inherent in the timer. The random events are determined by a game mechanic with known frequency but random outcomes (e.g. rolling dice or drawing cards after each turn as in Pandemic or Countervirus). The event outcomes occur with known probabilities determined by the designer, which means the timer will go off in a range of times according to tunable distribution.
Tuning probabilistic timers
Independent and identically distributed (IID) events, such as rolling dice or drawing cards from an infinite deck (good luck with the manufacturing of that one) are the simplest to tune, but perhaps offer the least control. The lower bound on those timers going off is determined by the frequency of events. If you roll one die every turn and the timer goes off after five 1s have been rolled during the course of the game, then the soonest it can go off is five turns. There technically is no strict upper bound you can set on an IID-based timer since the probability of hitting the threshold never equals 1 no matter how many turns you play (see Figure 1). However, it practically reaches one pretty quickly and the 99th percentile can be tuned to avoid outlier games that drag on.
Decks of cards are finite sized, so they’re not really IID events. If there are Ninc cards in the deck that increment the counter and it takes you M turns to get through the deck, then you know with probability equal to 1 that after M turns, the counter will have increased by Ninc. On the other hand, once Ninc increment cards are drawn, you know with probability equal to 1 that you will not draw any more until M turns have passed. This property changes the lower bound calculation depending on the details of the rules for drawing event cards.
A simple example is a deck of Ndeck cards, where f cards are drawn per turn and a timer that can increment T times before it goes off. After k cycles through the deck there will have been kNinc increments to the timer. The timer will therefore go off during the Kth cycle through the deck, where K = ceiling(T/Ninc) and ceiling rounds a number to the next largest integer. For example, it will be the 2nd time through the deck when a timer with T = 4 and Ninc = 3 goes off. So after K-1 cycles, there will have been (K-1)Ninc increments, leaving only T - (K-1)Ninc left to go when the Kth cycle starts. Then the minimum number of cards that can be drawn in the Kth cycle to hit T is just T - (K-1)Ninc. Therefore the minimum total number of cards that can set off the timer is Ndeck(K-1) + T - (K-1)Ninc. So, bringing it back to turn count, the earliest the game could end due to the timer is ceiling((Ndeck(K-1) + T - (K-1)Ninc ) / f). An example timer, deck and event rate are shown in Figure 2, which results in a lower bound of 22 turns and an average game length of 30.5 turns. I’ll spare you the upper bound calculation, but the finite size of the deck makes it possible for the designer to control the maximum possible turn limit before the timer goes off, too.
Narrowing the range
In the above example, the timer can go off in a range of 22 to 39 turns, which is a very large window and is perhaps too unpredictable to be enjoyable. One way to narrow the window is to replace the constant number of cards drawn per turn, f, with a time-varying function f(t), where t is the current state of the timer. One of the simplest forms of f(t) is a step function, which has f(t) = f1 when t < T1 and f(t) = f2 when t ≥ T2, with f1 < f2. Of course, you could add as many steps as there are increments possible, but 1 or 2 (as we chose to do in Countervirus) has a big impact on the game length range, as you can see in Figure 3. These steps also complicate the calculation of the bounds, but are worthwhile to consider, especially when you take into account the impact of intensifying the event rate on the other aspects of the game.
Figure 3. Game length distributions for 4 different types of event rules, decks and thresholds. They all have similar means, but have very different experiences. The constant draw rate games are much more likely to be very long or very short compared to those with step increases. The 2-step event rate function with increment cards spaced uniformly throughout the deck gives the narrowest range and most controlled experience while still being probabilistic.
Another way to tightly control the timer with a deck is to (roughly) evenly space the increment cards in the deck with each shuffle, similar to the initial setup of Pandemic (also shown in Figure 3). This would be a cumbersome from a gameplay perspective, but it ensures a repeatable process of ending the game in a very narrow range of turns. For Countervirus, the additional complexity of spacing the increment cards was not worth the gain in control, but for other games it may add value and be worthwhile.
What has been your experience with timer mechanics in co-op games? Did we miss any? Can you think of any innovative alternatives to achieve the same purpose?
Now that we have set the stage for this suspenseful scenario with an imminent end, our next post will analyze the path to victory.