Pastry Pirates

Pastry Pirates is a board game about sailing the Caribbean to collect baking ingredients. You choose a recipe, sail the archipelago to gather what it needs, trade or fight the other captains for the crates you can't reach, and race home to Tortuga to bake. It's free, it runs in a browser, and you can play it right now at playpastrypirates.com. Play solo against bot captains, pass one phone around a table, or sail online with friends each in their own browser. No login, no download, one to four players.

I designed and launched it in one month. It exists in two forms now: the online game, and a laser-cut wooden set with a printed rulebook that spells out every job the computer otherwise does for you.

A board game is a system small enough to hold in your hands, and complete enough to be both fun and meaningful. It has stocks you can count, flows you can trace, feedback loops that run away from you, and a designer who decided which parts of the world were worth modeling and which parts could be left out. That makes it the best instrument I know of for learning to think about systems. Unlike a city, a supply chain, or a climate, you can change one number in a board game on Tuesday and watch what it does to a hundred people by Friday.

Building this one taught me that so directly that I turned it into a course. Board Games as Designed Systems: Modeling the World in Cardboard and Code is proposed for the Tufts Experimental College, and Pastry Pirates is its open case study: the tabletop rulebook, the simulation engine I used to tune it, the source of the browser version, the version history, the playtest notes, and the failures. Three of its systems come up all semester, because each one illustrates a different problem.

One fun line of research yielded the insight that random chance feels different if it comes at the beginning versus end of a turn. In early versions of the game, the wind changed direction every turn and you had no idea where it would go. But real sailors can read and predict the wind. Later versions of the game included a forecast which places the wind's randomness before your turn. Suddenly, you can incorporate the random wind it into your strategy – and the decision space of the entire game deepens.

One number runs the entire late game. Each island stocks players-minus-one crates of its ingredient. With four captains that's three, and since roughly everyone needs roughly everything, somebody is guaranteed to be locked out of an ingredient they need and forced to trade or plunder for it. That is a leverage point in Donella Meadows' precise sense: one parameter, buried in setup, that decides whether the last third of the game is a race or a negotiation. I didn't design it and then notice this. I ran the model several thousand times to find out.

And a mechanic argues something about the world whether its designer meant it to or not. Lizzie Magie patented The Landlord's Game in 1904 to demonstrate that land monopoly impoverishes everyone it touches, and the world now plays her system as Monopoly, cheerfully, as a celebration of the thing she was attacking. You can take Pastry Pirates apart the same way in the rules lab, where every rule is exposed as a control, four bots play it out, the timeline scrubs back and forth, and a 400-game balance check runs on demand.

It started with two high schoolers. Luca and Amelia were taught by Nick Lesko how to design their own board game, and seeing their bridge-building game Seafarers is what started this one. I wrote a first ruleset on paper in July 2026.

The first thing I built was not the game. The first commit contains three instruments and no game at all: a Python simulation engine, a rules lab, and a design report. Before you can tune a system you usually have to build something else first, something no player will ever see and that you cannot do the work without.

I ran 40,000 games across four bot strategies, and the paper game I thought I had turned out to be broken in two ways I could never have seen at a table.

Battles were pure luck. The attacker won exactly 50.0% of the time, verified analytically, and in 55% of games the winner was also the table's luckiest flipper. Once two aggressive players met, the game stopped containing decisions.

And trade was structurally impossible, about a quarter of a trade per game even between bots built to trade. Players only ever collected ingredients they needed, so nobody ever held anything anyone else could buy. There was no surplus, so there was no market. No incentive tweak fixes that. It needed a rule that lets you carry cargo you don't need.

Eight rule changes came out of that report. Attacking cost two coins, so aggression is an investment instead of a reflex. The attacker may reflip one tails, which moves them to a 58.8% edge: favored, never safe. Islands stock scarce crates. A heads at any port gets you the crate even when it isn't on your recipe, which is the structural fix for the missing market. Simulated as a package, all four strategies land between 21% and 30%, and battles drop from twelve a game to six, each one mattering more.

But simulations are only that – simulations. Since actually playing the game, playtesting with others, and running hundreds of full games, the rules have progressed even more. Always in search of balance, strategic depth, and elegance over complexity.

Then battles got their own simulator, because the wind question needed its own answer. Twenty thousand battles per run, win rate broken out by who has the wind, so I could see what the advantage was actually worth before I put it in the game. Ultimately, the battle simulator was a helpful tool that missed an imporant real-world insight: flipping a coin – even a virtual one – gets annoying after a while. Battles were often 10+ flips. Their ultimate shape settles the whole battle in one momentous coinflip, where the defender may end up winning an ingredient from the attacker. Same chance, same risk, less hassle, more fun.

It didn't look like this at the start. At first, I created a simulator. Then I created a GUI so I could watch the simulator run. Then I thought... well hey this looks fun, I want to play. So I let one of the seats be playable by a human. And we had a game.

Then I designed a pipeline to generate art using Claude artifacts and Gemini image generation, and created, audited, iterated, and scaled 70+ images in a consistent style.

And here it is now. The wind and its forecast sit at the top because they're the decision you're actually making, your route draws itself across the water as a dotted line, and the recipe you're chasing is a card you can pick up.

Then real people played it, which is a different instrument. Xavaar worked out how wind should affect movement based on real sailing and playtested with an obsession that matched my own. Luis spent his last day in Boston imagining mechanics for it in his head, and later made the game's sound effects. Robin and Cathy were the first two multiplayer testers. I ran three live sessions and came out with punch lists of 15, then 17, then 9 items.

Here's the part worth admitting: for the game's first month, every session was with people who know me. But they are all designers, so they gave brutal, honest critique. The most humbling moment for me came when I showed it to a new friend afrer a month of full time work, and she gave up before her second turn. Watching her inspired me to redesign the game entirely to be mobile-first, deeply interactive, and bake in a tutorial parrot named Polly who seamlessly drops the right information at the right time, then steps back.

I directed the build. I didn't write it. The game is 3,072 commits made in about eight weeks. I wrote the design decisions, the specifications and the reviews, and Claude wrote the code. The most useful thing to come out of this project has been an understanding of how to manage a team – my team are just as fraught, lazy, error-prone and silly as any other team; they just happen to have no ego and work 24/7 because they're agents. Half of this project's work has been on Pastry Pirates itself; the other half has been designing the team-org structure of managing Claude, creating automation pipelines, learning git best practices when things run off the rails, and becoming a hobbyist software architect in charge of an organization who would always rather patch faulty code than architect durable solutions – unless I tell them otherwise.

The automation, which I named after the ship. By late August I was directing work that ran while I slept, and the thing I actually needed wasn't more output. It was to never wonder whether the work had quietly stopped. What I said I wanted was "a dependable agent that never stops building, that I can see is making progress whenever I check in on it, and I never have to worry is shut down or stalled." Everything below is built to answer that sentence.

The Watch is the working session: not one long-running agent but a relay of fresh runs, each one picking up where the last left off. Sessions get tired, lose the thread, and start believing their own summaries. A relay of fresh ones doesn't.

The Bell is the scheduler that rings a new watch when none is on deck. It lives outside Claude, as an operating-system scheduled task, and that placement is the whole point. Every in-session supervisor I tried died with the session it was supervising. The liveness layer has to sit outside the thing whose liveness it's checking.

The Glass is one published status page, regenerated every time anything closes: what's running now, when progress last happened so the page can show its own staleness, what shipped today in terms a player would recognize, and the queue of things blocked on me, each with a recommendation. It's a URL I can open on my phone. Only one thing is allowed to publish it, because two writers keeping a page in step by discipline is a page that drifts.

The Chart is one plan file, worked backwards from the launch date, with an inbox for ideas. Every idea gets a visible fate within a day: shipped, scheduled, or parked with a reason. Before it existed I had a roadmap, a state file, a backlog and a set of wave lists, and the four of them disagreed.

The Door is the single entry command for every session. Sync, read the Chart and the memory index, state the situation in five lines, then continue the top unblocked item or take instruction. One way in means a session can't start by improvising its own orientation.

The CEO is the review that runs after every item, before I see it. It's a fresh agent with no memory of doing the work, and it answers exactly one question: did the thing I asked for happen? Not "is this good work." Adjacent, competent, impressive work that misses the ask is precisely what it exists to catch.

It gets three things and they're non-negotiable: my request verbatim rather than a summary, because the summary is where the drift already happened; what was actually done, with commits and measurements and an explicit list of what wasn't; and the previous CEO's verdict, so it can say whether the same fault is recurring in new clothes. Its verdict reaches me in its own words, especially when it's bad, because whoever paraphrases it is the one with a motive to soften it. The verdicts are append-only and a wrong one stays on the record exactly as written, since that's evidence about the reviewer.

The first one opened by saying the unit had shipped a process that day and its very first output was a lie. That sentence is the product. A recent one told me flatly that one of my three named bugs was not done, in a week where everything else was.

The CTO is the long-running worker, and its rule is about which decisions it may make without me. I said it should ask for my input at critical junctures and, if I don't answer within ten minutes, make its best call and keep working. Then I realized that if every question defaults, its best call quietly becomes the design of the game while I'm asleep.

So questions come in two kinds. Mechanism questions, which function and which file and what order, take the stated default after ten minutes and get logged so I can undo them. Taste questions, meaning anything a player sees and cannot un-see, never default. They get parked and I come back to a batch of questions rather than a batch of decisions somebody made for me. Taste, placement, wording and how-much-is-enough are mine. Mechanism is the machine's. A ten-minute timer doesn't transfer taste, it only hides who made the call.

The Mentor is my coach. It reads every prompt I write and tells me how to improve. The honest reason I built all this isn't Pastry Pirates. It's that one day I'd like to lead a blended team of people and agents, and lead them skillfully, compassionately, and clearly. The skills this practices on me are that job's skills, so I designed them in rather than bolting them on: decisions arrive in executive shape with options and trade-offs and a recommendation, every term gets defined once, and there's one short lesson a day tied to whatever is actually live. A separate mentor coaches how I ask; the log records what I decided and what I now understand. Once a month I review how I directed the work, not what shipped.

The art is 143 generated images, which is not the same as getting them free. The work is upstream and downstream of the generator: a reference set so the game looks like one game, briefs specific enough to execute and loose enough to surprise you, and reviewing each batch as a set on one contact sheet. Individually good images that don't belong together are the standard failure of generated art, and it's invisible one image at a time. The sound effects are the counter-example. Luis made those, and briefing a person is a different craft: a person pushes back, asks what you actually meant, and often hands you something better than you asked for.

Then I put it back on a table. The physical set is a laser-cut board in four jigsaw quadrants, 409mm across, about the size of a Scrabble board, with Tortuga as a separate piece that sits on top. Almost none of the artwork was redrawn. The ingredient tokens are the game's own drawings, cut along their own outlines with the ink engraved. Every word on the wood is the game's own typeface, extracted to outlines. The wind chevrons are rotated by the same function that lays out the ring on screen. It's the same design expressed in a second material, and everything that was ambiguous in the rulebook became obvious the moment a person had to do the bookkeeping that the online version does silently.

It's live, it's free, and it's still being tuned. Come and sail it, and if you'd rather see the whole machine with its lid off, the rules lab is right here.