Steffen Benndorf’s The Game is an incredibly simple cooperative card game. It’s so ridiculously easy to learn, I had a group of people playing it less than five minutes after I opened the box. Beating the game, however, is just as difficult as finding information about it using the phrase “the game” in a search engine.
Four cards are laid on the table, two cards that start at 1 and go up and two that start at 100Â and go down. There are 98 cards in a deck with the numbers 2 through 99. Each player is dealt six cards and they take turns laying their cards on the piles. The game ends when there are no more cards in the deck or players can’t make a move. The goal is to have no cards left. The catch? Players can’t tell each other which cards they are holding.
The game allows what is called “permissible communication” in the form of phrases like “don’t lay a card on that pile” or “don’t make any big jumps on this pile.” I noticed every time I’ve played, less than 10 cards are left, which the instructions notes is a great outcome. I wondered if the game is just set up in a way that makes it difficult to fail miserably. Turns out communication (and probably letting communication that isn’t permissible slip occassionally) may just be an essential component.
Simulating a Game of The Game
Simulating a game of The Game isn’t easy. In fact, I had to rewrite portions of the function more than once. But I’ve done my best. First I created a deck, distributed six random cards to each player (three in this simulation), and then set up two ascend piles and two descend piles. Then I created a function called
round in which each player takes turns using a function called
play.cards. It’s basically a long if, else if, else statement that tells players what to do with, at minimum, two of their cards (as stated in the rules).
So the first round looks like this:
##  "96 was played on descend.1 by player1" ##  "13 was played on ascend.1 by player1" ##  "2 was played on ascend.2 by player2" ##  "24 was played on ascend.1 by player2" ##  "26 was played on ascend.1 by player3" ##  "29 was played on ascend.1 by player3"
At the end of the round, players are dealt new cards, so they always hold six â€“ unless the deck is empty, then they play what’s left in their hand.
The Game allows one trick to reset a pile. As you can see in the first round, player 1 played a 13 on one of the ascend piles. That’s a pretty crappy move, but players are often faced with those decisions because you have to play at least two cards. And it’s better to play 13 than, say, 99.
However, if another player has a card that is equal to 10 plus whatever is showing on the descend piles or 10 minus whatever is showing on the ascend piles, they can help the group out. In this case, if player two or three had been holding a 3, they could have reversed ascend.1.
As a reminder, this is where the piles stand after the first round:
##  "Ascend 1: 29"
##  "Ascend 2: 2"
##  "Descend 1: 96"
##  "Descend 2: 99"
In round two you can see how the trick described above plays out:
##  "82 was played on descend.1 by player1" ##  "18 was played on ascend.2 by player1" ##  "22 was played on ascend.2 by player1" ##  "33 was played on ascend.1 by player2" ##  "34 was played on ascend.1 by player2" ##  "81 was played on descend.1 by player3" ##  "91 was played on descend.1 by player3"
Player 1 apparently had crappy cards. Player 1 put an 82 on descend.1 and an 18 on ascend.2, which are pretty bad jumps. But then player 3 did something cool. Player 3 played an 81 on descend.1 and then played a 91, reversing the pile.
Now when I’m describing these “players'” actions, I’m really just talking about the output of a function that attempts to mimic player behavior. Player 3, obviously, did not make a choice to reverse the pile because it was cool. He/she/it made the choice because it was one of many if/else if actions available to he/she/it. Player 3, in fact, did not know that player 1 was going to jump the pile down to 82. It was a coincidence. If that had not happened, player 3 may have just played the 91 on descend.1 and saved the 81 for later.
But this is the whole purpose of my experiment: to see if communication is really necessary.
Let’s skip ahead, 23 rounds or so later, and check out the outcome of this game. By the end, all the players can no longer make any moves and there are 25 cards left. That’s not a great outcome. Because of the randomness involved in the game (the probability of certain cards being dealt and played), one simulation is not enough.
I ran 999 more games.
The players (a.k.a. the function) performed terribly. The results follow what’s called a multimodal distribution, see plot below. It’s when two results pop up frequently, in this case the major mode (or big hump) is 16 and the minor mode is around 35.
Why? With such a large number of simulations, it seems that the highest probability scores fall between two groups, one group that does fairly well (16 ain’t bad) and another group that does terribly.
“But why?” you continue to ask. I honestly don’t know. Maybe it’s flawed behavior programmed into my script. People are hard to simulate, guys. And maybe that’s why overall the function I wrote does a poor job of winning The Game. To be more accurate, 92.8% of the time it’s terrible. The best score was 3, which is impressive, but a great outcome only happens 7.2% of the time because those outcomes rely on the probability of players being dealt great hands.
In a perfect world, I could compare 1,000 actual games with human players to these 1,000. In an even better than perfect world, I could compare my simulated games to two sets of games using randomly selected human players, with one set where communication is allowed and another where communication is not allowed.
My hypothesis is that communication â€“ permissible and not permissible, for you cheaters â€“ is the key to winning the game, and until I get a research grant (see: never) to conduct further testing, we’ll just have to settle for that answer.