This post focuses on the challenge of finding an abstraction that describes social deduction games in general. These games (e.g. werewolves, two rooms and a boom, spyfall) seem to require the sort of twisted thinking needed for security protocol design: a problem famously likened to programming Satan’s computer. What they tend to have in common is that they are played face-to-face with other people, but crucial information is hidden from those who need it, in an environment where players cannot necessarily be trusted. In the case of my own offering (Spy Thriller), the hidden information is the identity of your team mates.
I’m guessing if you’re still reading at this point, that you’re a programmer. So I’m going to outline the problem as we encountered it, and give you an opportunity to solve it yourself before revealing how I got there. There may well be better solutions that work for more games, but finding them would require a concrete specification of the problem. In the real world, specifications are somewhat fuzzy, and half the problem is refining them.
Spy Thriller’s original inspiration was a fully offline role-play in which players were assigned to teams and given a simple mission of delivering an object to a target. The catch is that nobody is told who their teammates are, nor all the information they need to complete the mission; instead you must find out these things through various antics involving meeting places and passwords. As teams raced to compete there was plenty of scope for trusting the wrong people either by mistake or through (friendly) malicious play, and to complete the wrong mission meant losing the game. Intriguing though all this was, setting up the game was a nightmare, and I have memories of standing outdoors in the freezing cold while we worked out who was supposed to be told what. Still, we enjoyed it enough to want more!
The original instructions went something like this:
Randomly divide players into teams consisting of a captain, a mate and one or more yeomen. In secret, tell each player their role. Give a matching password to the captain and yeomen, and a matching meeting place to captain and mate. Tell the mate what their team target is, and tell the yeomen what their object is. (There were also some additional rules concerning locations of jails).
The following year I hacked together a few lines of code to automate this, the game went much more smoothly and players had fun stumbling through the intentional confusion that entailed. After this and numerous other playtests, however, we had identified the following flaws in game play:
- After 6 or 7 rounds, people got familiar with the structure and it became more of a race to the finish line. This killed the uncertainty/deception elements of the game which made it unique in the first place. We managed to discourage racing a little by limiting the number of teams to two: with multiple teams each team is incentivized to race to the finish while with only two teams, effort spent deceiving the enemy pays off equally well. But that meant…
- …any players beyond the initial 6 were redundant, as their team mission could be completed without them
- As players became familiar with the game, newcomers could rarely pull off deceptive tactics as their lack of familiarity with the setup rules gave them away
- Not a flaw, but friends started to suggest interesting changes, such as introducing a ‘double agent’ who had enough information to infiltrate the opposing team. But what information should they be given, and how could other players defend against them?
We wanted to somehow abstract away from the original instructions and pick working, logically consistent game setups at random from a larger space of possibilities. But how to do this, and how to make sure each game was inclusive of all players and ‘solvable’? And how to introduce more deception in the form of double agents? In hindsight the answer seems obvious, but I’m slightly embarrassed to admit that at the time it wasn’t (this is often a feature of correct notation). I’m going to split this post now so the programmers among you can have the satisfaction of arriving at an answer for yourselves, and reveal the solution in part 2.