Board Games as Secret Programs

Module 5 · Section 4 of 6

Board Games as Secret Programs

Ever opened a board game box to find a thick rulebook and thought “this looks like a foreign language”? Here’s the thing: those rules aren’t just instructions. They’re a program.

Every board game is a small computer system, complete with inputs, outputs, loops, and decision trees. Instead of electricity flowing through circuits, you have dice rolling across tables and cards shuffling between hands. The players become both the processor executing instructions and the memory storing the game state.

The Architecture of Fun

Think about Monopoly. When you roll the dice, that’s your input. The game processes it by moving your piece the corresponding number of spaces, then runs different functions depending on where you land. Land on property? Execute the “purchase or pay rent” subroutine. Pass GO? Run the “collect $200” function. Draw a Chance card? Trigger a random event generator.

This isn’t just a clever comparison — it’s literally how game designers think when creating board games. They’re writing programs that run on human hardware instead of computer processors.

Variables and Game State

Every board game maintains what programmers call “state” — all the information needed to understand the current situation. In a video game, state lives in the computer’s memory as numbers and text. In a board game, it’s physical: your money stack (an integer variable), your position on the board (coordinate data), the cards in your hand (an array), whether you own each property (boolean values — true or false).

The genius of physical board games is that they make this data visible and tangible. You can see your resources, count your cards, and observe other players’ positions. It’s like having a program where all the variables are displayed on screen at once.

Loops and Turns

Most board games operate on a “game loop” — a sequence of actions that repeats until a condition is met. In Scrabble, each player’s turn follows the same pattern: draw tiles, make a word, calculate points, refill your rack. This loop continues until someone uses all their tiles or no valid moves remain — these are the “exit conditions” that end the loop.

Some games have nested loops, like Risk, where you have the overall turn sequence (attack, fortify, draw card), but within the attack phase, you might run the same battle procedure multiple times. Loops within loops, exactly as in programming.

Conditional Logic in Action

Board game rules are packed with “if-then” statements. If you roll doubles in Monopoly, then you get another turn. If your Scrabble word uses all seven tiles, then you get a 50-point bonus. If another player has built a city in Catan where you wanted to expand, then you need to find an alternative strategy.

These conditional statements create the branching paths that make games interesting. Unlike computer programs that evaluate thousands of conditions per second, board games let you see and feel each decision point. You’re walking through a flowchart with every choice you make.

Random Number Generation and Probability

Dice are physical random number generators, and deck shuffling creates unpredictable sequences. Game designers are probability programmers, carefully crafting the odds to create excitement and balance. When you roll 2d6 in Monopoly, you’re not just generating random movement — you’re executing a probability distribution that makes landing on certain spaces more likely than others.

Error Handling and House Rules

Even the best-designed board games occasionally encounter edge cases — situations the designers didn’t fully anticipate. When this happens, players become programmers, developing “house rules” to handle the exception. It’s collaborative debugging in real time.

This reveals something important about how systems work: every program has gaps. When a rule doesn’t cover a situation, you don’t give up — you extend the program. House rules are patches. The game keeps running.

Designing Your Own Program

Understanding board games as programs opens up new ways of thinking about system design. Start simple — a game with clear inputs (dice rolls, card draws), obvious state (player positions, scores), and explicit win conditions. Test your “program” with others, watching where players get confused or where the game becomes unbalanced.

Each playtest is like running your program with a different data set. Players will find bugs you never anticipated and suggest features you hadn’t considered. The iterative process of game design mirrors software development more than most people expect.

The next time you sit down to play a board game, look at the rulebook differently. That thick booklet is source code. The pieces are hardware. The players are processors. And every move is the program running.

---

From Rulebooks to AI Workflows

An AI workflow is a board game: rules = logic, “off-script” = state without a rule.

Board games work smoothly as long as the rules cover the current situation. The game only breaks down when something happens that the rulebook doesn’t address — a player finds an edge case the designers never considered, and suddenly nobody knows what to do. The state exists. The rule doesn’t.

AI workflows have the exact same failure mode.

When you build a workflow — a sequence of prompts, a chain of instructions, an automated process — you’re writing a rulebook. AI executes it faithfully as long as the current state matches a rule you’ve written. But when the input falls outside your rules, AI doesn’t stop and flag the problem. It resolves the gap using its own defaults. Sometimes those defaults match your intent. Often they don’t.

The professionals who build reliable AI workflows treat every exception as a missing rule, not a one-off. They ask: what happens when the input is empty? When the text is in a different language? When the data is malformed? When the user asks something out of scope? Each of those is a state your workflow might reach. Each needs a rule.

The habit to build: After drafting any multi-step AI instruction set, walk through it as a player following a rulebook. Find the places where the rules run out. Write the missing cases before you deploy.