Turing Drive

In Turing Drive, players build their decks to simulate programs for a Turing machine to be the first player to get the drive head to their end of the drive tape. This game was a proof of concept of a purely deterministic card game and was designed to teach logic processes and help people become familiar with basic information technologies concepts. The game went through dozens of iterations before finally settling on a short game with alternative win conditions that allowed players to explore more space besides trying to move the drive head.

Game Concept

Turing Drive is a teaching tool to explain how a Turing machine would function. A Turing machine is defined as “a mathematical model of a hypothetical computing machine which can use a predefined set of rules to determine a result from a set of input variables.”1. This game is the result of a thought experiment as to how a purely deterministic card game would function.

In a nondeterministic game, there is some element of randomness by which you cannot determine the result simply by player agency. Any game where the game is randomized, either at the start point or later by rolling dice or shuffling cards, would be non-deterministic. Examples include everything from snakes and ladders to solitaire or poker. Conversely, a purely deterministic game has a set start state and is only altered by player agency. Popular games that are purely deterministic are chess, go, and checkers. In Turing Drive, all elements of randomness beyond player decisions are removed from the game. There were several reasons for this.

One reason is that many collectible card games, hereafter noted as “CCGs”, have a problem when deck manipulation is used to cheat a needed card to the top of the deck or hand. In Turing Drive, players prebuild their decks in the order of their choosing. This order is set and can only be altered by cards played and actions taken as a result of player choice during the game. Another reason is to enforce the concept of logical choices in planning. Each player’s deck should be designed to give both options and a direction to achieve a goal by going through their “code” and seeing how it resolves. Initially, the intent was to make one of several victory conditions optimal with players taking turns resolving the top card from their deck, called a “drive” in the game, interacting with the drive tape, until one player reaches one of those victory conditions, such as making it to the end of the tape to their right or completing a blue victory condition. Cards are meant to reflect computer concepts, such as sorting, checking the value represented on the tape, and the busy beaver function, and are either “procedures” or “sub-routines”.

As an aside, the busy beaver function inspired the tape mechanic for this game. While it is well defined, expanding on the nature of the busy beaver function is well outside the scope of this document, but, at its most fundamental, quantifies the maximum score attainable by a busy beaver on a given measure that aims at finding “a terminating program of a given size that produces the most output possible”2.

Genre

The game falls in between a traditional TCG and a deck builder, as the players purchase a full card set as opposed to randomized boosters. There are no collectible elements or need to trade to get what they need. Each game set has enough for a player to build any deck they want within the rules. Thematically, there is a sci-fi feel to the game, reminiscent of movies like TRON and TV shows like Reboot, or games like Cyberpunk 2077.

Target Audience

People who are interested in computational logic and coding. Teachers in STEM fields should also be interested in the game as a teaching tool. I would recommend this game for ages teens and up, as the complex logic of some deck design elements may be daunting to younger players. To be fair, I found the game daunting, mostly in creating "good" decks, and I made the game.

Project Scope

The game itself is designed to be compact once purchased and carriable. The cards are the standard poker size, so will fit in the most readily available protective sleeves. Players should be able to build any deck concept they have from the initial set purchase and run them against another player.

I expected this game to take me roughly four months to make. I vastly underestimated that amount given I was the only one working on the project and the amount of time my other classes were going to take.

Cards were first made in Magic Set Editor as it’s a good prototyping tool. Art is being made either in Blender, Daz3D, or a combination of both. I have struggled to make art that matches abstract concepts such as validating, an XOR gate, or stack overflow. "Turn the Light Off" proved problematic, though I’ve been considering doing more art with a “beaver” theme given the busy beaver function being one of the inspirations of the game and that I was able to find an inexpensive beaver asset.

The initial design of cards that could work and get a minimum viable product did fit in my initial plan of a month, but actual playtesting and iterating the game took almost twice as long as expected. Even then, I’m still trying to make art for the game. The game initially started with a tape size of eleven. That has now shrunk twice and is down to seven, three to each side of the initial state. In addition, I have realized that the games still feel like they take too long and implemented a rule to determine the winner after each deck has run through once. This has made “corrupting” far less useful, and it will need to be retooled. I also realized I named two cards the same thing.

Through different iterations, the main thing I come to realize is that I may not be smart enough to make good decks for this game. Then again, I’m not an amazing chess player, either. I still consider this a “proof of concept” game and an exercise to show that this is possible, to lay the groundwork for games in this genre, and to show that it can be done. That, in and of itself, has been a rewarding challenge. It’s also been an education in time management.

Gameplay

Players prebuild their decks in the order of their choosing and take turns resolving the top card from their deck, called a “drive” in the game, until one player reaches one of several victory conditions available in the game. “Procedure” cards stay in play across turns while “Sub-routine” cards happen once and then go into the “completed” or discard pile. Cards can also be moved to RAM through different green cards, which is effectively each player’s hand, and remain face-up while in RAM. Cards can affect the bit where the drive head is and/or can move where the drive head is..

The player who goes second chooses the starting value of the bit at the center of the tape, which is where the drive head starts. The tape extends three spaces to the left and right of the center bit.

While most of the win conditions are blue cards, the player can win by ending the turn with the drive head on the third spot on the “tape” on their right. Cards that move the drive head do so based on the player’s perspective, so player one’s left is player two's right and vice versa.

When a card is played, all procedures check to see if that card triggers any effect on the card, starting with the active player who can place the triggers in any order they choose on the stack. The non-active player then does the same and the stack resolves last in first out. Once all triggers have resolved, play continues to the next player.

Mechanics

Bits, the Drive Head, and the Tape

Red cards focus on the current bit value. The drive head tracks the location of where on the tape the player’s at. Only the bit where the drive head is located can be affected by cards. It is also the bit referenced when a card checks the value. The value will always be either a one or a zero, representing the standard bit. When the bit is changed, flip the bit accordingly from a zero to a one or vice versa.

If, at the end of a player’s turn, the drive head is on the active player’s rightmost location, that player wins. In addition, if both players’ code have been completed (they have no cards left in their deck), check the location of the drive head. If it is on that player’s right, they win. If the drive head is in the center, the game is a tie.

RAM

Green cards focus on RAM. Ram is both the player’s hand and an energy source. A card placed in RAM may be accessed later. Alternatively, some cards may check to see if the number of cards you have in RAM are less than, equal to, or greater than a specific number of cards to trigger specific abilities. RAM is also a potential way to rearrange parts of your deck during the game.

Win Conditions

Aside from the aforementioned method, there are blue cards that present unique win conditions, such as having enough things in RAM, a correct value on the tape, or resolving all variables by achieving a specific state. There are cards that “turn off” blue cards but are conditional themselves.

Corrupted Zone

What hasn’t been mentioned thus far is the “corrupted” zone. Effectively, these are cards that cannot normally be accessed. As the “completed” zone would flip over and become your drive if you could not otherwise draw a card from your drive, this is one way to remove a piece of code from your opponent’s drive entirely. Some cards move other cards to the “corrupted” zone. This is similar to the "exile zone" in games like Magic: the Gathering.

Game Elements and Assets

The primary game elements are the card in the players’ drives and play area, the “Tape” and the “drive head”. The art is meant to resemble abstract concepts, such as pathfinding, sorting, and specific win conditions. With the exception of the circuitry background, which was a stock image I then modified, all the art was created by me in either Blender or Daz3D.

Sources

1. Oxford Languages

2. Radó, Tibor (May 1962). "On non-computable functions" (PDF). Bell System Technical Journal. 41 (3): 877–884. doi:10.1002/j.1538-7305.1962.tb00480.x.

Page updated

Google Sites

Report abuse