Turing Designer’s Diary Part 3 – Hiding and scoring

Turing is, mechanically speaking, a relatively simple game. That’s to say, it has only a few moving parts. This is a conscious design choice in relation to a more limited play-testing regime thanks to lockdown due to the Coronavirus pandemic. However, it does have a few interesting design challenges with very specific mechanics that I think explaining and examining might be useful to others. Specifically, the nature of obscuring choices and scoring the game, which I’m going to write about in this designer diary entry.

Obscure choices

In Turing a player is given a hand of cards showing abstract images. The game automatically selects one while the player picks one out as their intentional choice. The game is based around an interrogator inspecting those choices and attempting to identify a human intelligence behind one as opposed to the other. The intention of the game is to drive players to create connections between disconnected and abstract images. Clearly, if players are able to identify chosen cards by more mechanical means this would short circuit the game in a highly unsatisfying manner. As such we’ve had to obscure the choice in a couple of mechanical ways, in their timing and the physical position.

Timing wise is a simple fix but one that might not be immediately obvious. The game selects its card by simply always choosing the leftmost or rightmost card in a player’s hand when drawn, meanwhile the player selects their card by examining the remaining images and actively choosing one. If players were allowed to hand over cards as and when they were chosen it would be almost instantly obvious that the card most quickly handed across each round would be that chosen by the game. As such it was vital to make it clear that the two cards chosen would be handed across simultaneously.

Additionally, it is vital that players not be able to communicate anything by the fashion or order of handing over cards, were players given any control over the ordering of handing cards it would be too simple of an ability to always hand over the game’s choice first, or second, and so again, cut out the value of the game. The solution here is that each round the choosing player draws their hand, views their cards as a whole, then hands both cards over to the interrogator in a small pile, leftmost card on top, rightmost card beneath for the interrogator to them place out. This has a handy side effect in that it means the cards are re-aligned such that those on the right and left have that alignment maintained however players are actually arranged around the table.

The other issue was to disguise the physical positioning of cards. Clearly, again, if a player draws four cards and selects one of the righthand three cards while the game claims the leftmost it would become quickly obvious which was the player’s cards and which the game’s. This meant that the game necessitated some form of shield. Cards are drawn and placed in order from right to left behind the screen, selected and stacked before being handed to the interrogator. The one issue with this simple solution is that Turing is designed to be a low-price pocket game and player shields result in a significant production cost increase both directly due to being made of heavy card and indirectly due to increasing shipping weight and box size. However, the box is a necessity to a produced game and is inevitably constructed from a heavier grade of card. As such the solution was created to use the box as the player shield with the lid being flipped up and secured by slotting the base into it. The box lid will then be printed inside and out with guides for card stacking and unstacking allowing it to serve multiple purposes, completing the mechanical needs of the game while keeping costs down.

Scoring

One of the trickier problems with scoring oppositional image interpretation games is how to encourage players to make their best efforts when doing something that provides their opponents with points. Party games solve this issue with the simple introduction of teams. If two players are on a team then they will naturally put forth their best efforts to guess each other’s attempts. However, this limits a game’s player count to four as an absolute minimum which I very much wanted to avoid, firstly for a small pocket game, secondly due to releasing in an environment where large player groups may be unlikely for some time to come and thirdly because when releasing a small game in an environment like Kickstarter the broader the player count the wider the net.

The simple and brilliant scoring innovation here is one that I can call brilliant because it isn’t really mine. In Turing players score a point for guessing correctly and one point for each correct guess of their images, immediately pushing players to co-operate while in opposition. The one issue with this system is that since it’s a zero-sum gain between two specific players it requires at least three players. This isn’t a huge issue, but to allow the game to be played at a count of two it necessitated a couple of alternative play options. The simplest was to create a co-operative score attack mode for a pair of players to attempt to average a score sufficient to beat a pre-set level, a second mode was provided for players to score based on failure to identify the sequence. This rather subverts the basic process of the game, but it does allow for an alternative play mode at any player count and a non-score attack for two players, which I think significantly increases re-play value.

Development on Turing is going very smoothly, we have the majority of pre-production complete and are cautiously confident of a summer release. If you’re interested it now has a full page on the website with print and play (quite ink-heavy unfortunately, but there really is no way of producing a low ink version due to the image heavy nature of the play) and Tabletop Simulator version to try out. If you take a look, we’d love to hear your feedback on the game and the various play modes.