Irrational Bakery

The idea

Overcooked gives you a kitchen and not enough time. This gives you a kitchen, not enough time, and no single person who knows what they are making.

Every cook holds a receipt card with a few lines on it. Yours says who is allowed to open the oven. Somebody else's says what temperature it needs. A third says pies 3 and 7 need a fresh batch of dough. Nobody can see anyone else's card. That is the Keep Talking and Nobody Explodes half — the obstacle is the conversation, not the controls — bolted onto a kitchen that will not wait for you to have it.

π is the difficulty curve

The theme is not a coat of puns over a generic bakery. The number does real work: day n has as many rules as the nth digit of π.

Day    1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20
Rules  3  1  4  1  5  9  2  6  5  3  5  8  9  7  9  3  2  3  8  4

Day 2 is a breather. Day 6 is a nine-rule wall that lands far earlier than any sane difficulty curve would put it, and you have to get good to pass it. Day 12 and 13 are back-to-back punishment. Day 33 is a zero, and you will have earned it.

Two things make this better than a smooth ramp. It is memorable — people talk about day 6 the way they talk about a boss — and it is honest, because the irregularity is not a designer's whim you can argue with. It is the number.

Order volume rises steadily underneath the digits, so the two curves stay separable: day 20 with four rules is still harder than day 3 with four rules. Without that, the dips would feel like the game going backwards.

Scoring is out of 3.14 stars, which is the only defensible maximum.

A day is a constraint problem

A day is not a random draw. The generator refuses to return one that breaks any of four invariants:

1. Solvable — every gated action has somebody allowed to do it, the bowl order admits a topological sort, and no physical puzzle asks for more bodies than are in the room.
2. Fully known — every clause is on exactly one card.
3. No card suffices — knowledge comes in groups and nobody holds a whole one. The moment one person does, they work alone and everybody else is a courier.
4. No self-sufficiency — you are never handed the clause about yourself, so everyone has to be told something.

make sweep deals ten thousand days across every cook count and checks all four on each.

The apron wall

You get ready by taking an apron off a peg on the kitchen wall. Taking one says you have read your card; taking a different free one changes your colour and says the same thing.

That is one gesture rather than a colour picker plus a ready button, and it is in the room rather than on a panel. A cook who has not taken one yet is drawn in kitchen whites, so you can see who everybody is waiting for without reading anything. Once half the room is ready the rest get fifteen seconds.

The reason this is careful rather than cute: the cards name people by colour. "Only the cook in blue may open the oven" means two people if two cooks are in blue, and somebody else entirely if an apron changes underneath it. So no two cooks can share a colour, and nobody can change once the clock is running.

Playing on your own

One person cannot make a pie here — the walk-in only opens while somebody stands on the pad — so a solo kitchen comes with Tau, a helper who holds pads, staffs the far side of the press and bins the burnt ones. It never touches the recipe. A bot that could solve the cards would make the game pointless.

The cards invert instead. The day is still dealt for three hands and you hold all three, but you see one at a time and turning one over costs about a second. Information cost in place of information asymmetry — same kitchen, same clock, same panic.

Playing it on paper first

The whole game lives or dies on whether a handful of cards make a good conversation, and that is answerable in one evening with a terminal and some scissors:

go run . -deal 4 -day 6 -seed 314159 -answers

Print it, cut the cards out, deal one each, set a timer for 3:14 and try to talk each other through a pie. Building the kitchen first would have meant finding out months later.

Testing the halves together

Go on the server, a browser client over WebSockets, and one dependency.

The useful lesson is about what the test suites could not see. The Go tests drive the simulation with a synthetic client; the client's own harness drives the renderer with synthetic frames. Both can pass while the pair is broken, and the pair is what ships.

Which is exactly what happened: both halves independently used the number of cooks in the room where the number of players was meant. A solo kitchen stopped being solo the moment the helper stood in it, and the card carousel switched itself off for the one mode it exists for. Neither suite could catch it — the server's tests have no client, the client's harness has no helper. The fix was a target that runs the real client against the real server in headless Chrome.

Two other silent failures are now pinned by tests, both worth knowing if you ship a Go binary with an embedded web root:

• //go:embed public drops every path beginning with a dot. Without all:, .well-known/security.txt sits in the repo, is served perfectly in development, and simply does not exist in production.
• .webmanifest is not in Go's content-type table, so it goes out as text/plain and Chrome quietly declines to install anything. The file is there, it returns 200, and the prompt just never appears.

Every icon and the social card are generated from one SVG in headless Chrome — the renderer the images are actually for. There is not one hand-made binary asset in the repo.