studio / July 9, 2023

Building a Tabletop Heist Game from Scratch

What happens when a software engineer applies systems thinking to game design — dice mechanics, emergent strategy, and the surprising lessons from playtesting with strangers.

Where the idea came from

I’ve been fascinated by heist films for a long time — not the action, but the planning phase. The part where the crew stands around a table covered in blueprints and figures out how all the pieces fit together. It occurred to me that this is essentially a systems design problem, and systems design is something I think about every day.

So I started sketching. What would a board game look like that captured that tension — where the preparation mattered as much as execution, and where things going wrong mid-heist was a feature, not a bug?

The best heist games aren’t about luck. They’re about anticipating failure and building systems resilient enough to survive it.

Core mechanics

The game is built around three phases that repeat each round:

  1. Intel — players gather information about the target, each card revealing something new about the layout or security.
  2. Planning — a hidden simultaneous action selection round where each player commits their role for the next phase.
  3. Execution — dice resolve actions, but outcome is heavily modified by planning quality.

The interesting design constraint I set for myself early on: no player should ever feel like they lost because of a bad dice roll. Dice introduce variance, but good planning should be able to absorb most bad outcomes.

The role system

Each player takes one of five roles per heist. Roles aren’t permanent — the same player might be the Driver in one heist and the Grifter in the next. This creates interesting meta-game dynamics around team composition.

Role Primary ability Weakness
Driver Fast extraction, ignores traffic dice Useless indoors
Grifter Can re-roll social encounters No combat bonus
Safecracker Bypasses vault difficulty by 2 Slow movement
Muscle +3 to combat, intimidation Alerts on entry
Ghost Invisible to cameras this round Can’t carry loot

What playtesting taught me

The first playtest was a disaster — in the best possible way. Three things broke immediately:

  • The intel phase took too long. Players were analysis-paralysed by too much information.
  • The Muscle role was too dominant. Every group picked it.
  • Nobody understood what the Ghost was for until round three.

All of these were fixable — and fixing them led to better design than I started with. The intel phase got capped at three cards. The Muscle got a noisy entry penalty that made stealth runs harder. The Ghost got an early-game reveal ability that made its value obvious from the first turn.

Current state

The game is in its third iteration. I have a working prototype printed on card stock and laminated, which is more effort than it sounds. Playtesting continues. The plan is to get to a point where I can run a blind playtest — strangers who’ve never seen the rules — and see if the game teaches itself.

If that goes well, the next step is figuring out what a small production run looks like.