A randomized puzzle game has to prove its random rules can be won before anyone plays them. Bomb Appétit does that per module: each new rule set plays up to 1,000 random sample bombs by following its own manual, and any strike sends it back. Only a rule set that defuses every sample reaches the printed page.
Why a randomized puzzle game can deal an unwinnable rule
Random rules are drawn by a program, not checked by a person, so nothing stops a draw from contradicting itself. A generated table can point at a wire that is not there, leave a case with no answer, or hand two different answers to the same situation. Each of those would make a bomb that no team could defuse.
Consider how a module's rules are made. A generator picks conditions, targets and tables from a grammar the designer wrote. Each pick is reasonable alone. The trouble comes from combinations. A rule that says to cut a wire of some color is fine when that color is guaranteed to be present, and broken when it might not be.
Edgework adds more combinations. The bomb's casing carries a serial number, batteries, indicators and ports, and many rules depend on them. A generated rule set has to work for every casing a bomb can be dealt, not just the ones a designer happened to imagine. The number of possible bombs is too large for anyone to check by hand.
Timing adds another layer. Some modules depend on the clock. Big Button can ask the Defuser to release when the timer shows a particular digit. Needy modules wake on their own and strike if left too long. A rule set that works when a team is fast but has no answer at some moment would also be unwinnable.
The usual fix in games with random rules is to settle the rules before play, so everyone reads the same thing. The guide on why games with random rules must fix the rules before play covers that side. Fixing rules early solves fairness between players. It does not solve a rule set that was broken from the start, and that is the job of the solvability test.
How the 1,000-bomb solvability test plays a manual
The solvability test is a function in the engine called checkModuleSolvable. It takes one module and one candidate rule set, deals a run of random sample bombs, and plays each one by asking the module for the correct move under those rules. If every sample ends solved without a strike, the rule set passes.
Each sample gets its own random edgework and a random number of strikes already on the bomb, from zero to two. Then the module builds one instance of itself under the candidate rules, the way a real bomb would.
The test then plays the instance in simulated time. At each step it asks the module's hint function for the one correct action right now. The project's module guide requires that hint to come from the same rule lookup the module uses to judge a move. So the test is asking the rules what to do, then checking that doing it works.
Four things end a sample:
- A strike. If the hinted action, or a timed event the module fires, causes a strike, the whole rule set fails.
- Solved. A regular module that reaches solved passes that sample.
- Survival. A needy module never gets solved, so it passes by lasting 90 seconds of simulated time without a strike.
- A stall. A regular module with no correct action for three simulated minutes fails, and so does any sample that runs past 5,000 steps.
The default is 1,000 samples per candidate. Five modules ask for 200: Blinker, Tangled Wires and Wire Panels among the regular modules, and the needy modules Pressure Vent and Dial Alignment. Discharge Lever has no generated rules to test.
Here is one candidate rule set going through the check, as a step list. The candidate and its result are an invented example, not a real seed's rules.
- Draw. The Glyph Keypad generator draws six columns of seven symbols from its fork of the seed.
- Filter. The draw must have distinct columns that overlap enough with each other. In this example it does.
- Play. The test deals 1,000 sample keypads under those columns, each with random edgework, and presses keys in the order the hint gives.
- Reject on any strike. In this example, sample 612 strikes, so the candidate is thrown out.
- Retry. The generator draws a new candidate from the next try's fork. It may retry up to 200 times.
- Accept. The next candidate clears all 1,000 samples without a strike, and it becomes the Glyph Keypad page for that seed.
For where this check sits in the whole chain from seed to page, the procedural generation guide traces the path from one rule seed to fourteen module generators.
What happens when a randomized rule set fails?
A failed rule set is discarded and the generator draws a new one. Each new draw comes from its own named fork of the seed, labelled by its try number, so the replacement is still decided by the seed alone. The generator gets 200 tries. If none passes, the engine stops with an error instead of printing a manual.
The retry order matters for reproducibility. Try 0 always uses the same fork for a given seed, try 1 the next, and so on. If try 0 fails and try 1 passes on one computer, the same happens on every computer. So the accepted rules for a seed are the same everywhere, even though some candidates were thrown away on the way.
A player never sees a rejected candidate. The manual page only ever renders the accepted rule set. There is no partial page, no warning and no "this seed is broken" message, because a seed that could not produce a passing set would not produce a page at all.
The error case is a safety net for developers rather than something players should expect. The engine's rule tests run a sweep of seeds 2 to 500 in continuous integration, checking every module under every one of those seeds. A generator change that made some seed impossible would show up there before it reached the site.
The interesting-rules filter: no dead branches
Passing the solvability test proves the rules can be followed. It does not prove they are worth following. So several modules run a second check before the test: a filter that rejects rules with dead branches, repeated lines or answers that never vary. A rule set must pass both.
A dead branch is a rule that never matters. It might never fire, or it might give the same answer as everything around it. Such a rule wastes an Expert's reading time, and a manual full of them would make some modules trivial. The filters vary by module:
| Module | What its filter rejects |
|---|---|
| Wires | A line whose conditions name the same wire color twice |
| Big Button | Repeated condition lines, every line giving the same move, or a last line that matches the fallback |
| Glyph Keypad | Columns that repeat, or that share too few symbols with the other columns |
| Color Echo | A color table that changes nothing, or two tables that are identical |
| Word Grid | Rules that never send the Defuser to some button position |
| Recall | A stage with fewer than three different instructions, or a later stage that never looks back |
| Pressure Vent | A prompt set with fewer than two yes answers or fewer than two no answers |
| Dial Alignment | Two light patterns that look the same |
The other modules rely on the solvability test alone. Labyrinth, Passcode, Blinker, Tangled Wires and Wire Panels have no extra filter, and Discharge Lever has no rules at all. Their generators are built so that a dull draw is unlikely in the first place, such as Passcode sampling a fixed number of words from a larger pool.
The filter runs first because it is cheap. It looks at the rules as data, without dealing any bombs. Only a candidate that passes the filter goes on to the slower step of playing sample bombs.
Does the solvability test make every seed equally hard?
No. The test is pass or fail. It confirms every sample bomb can be defused by following the rules, but it does not measure how long that takes, how many lines an Expert must read or how easy the symbols are to describe. Two seeds that both pass can feel quite different at the table.
The generators leave room for variety in size. A Wires list has three or four if-lines. A Big Button page has four or five lines, and some lines check two conditions at once. Which glyphs sit in which column, how the mazes are carved and which words land in the Passcode list all change with the seed. Some of those draws will be easier to talk through than others.
Nothing in the code ranks seeds by difficulty, and no seed is labelled easy or hard. Seed 1 is the standard manual because it is stored and shared, not because it was picked for being gentle. The missions use it for that reason, so times on one board are comparable.
If a group finds one seed harder than another, the honest explanation is usually a mix of the draw and familiarity. A seed the group has never read takes longer to search. The breakdown of what each module redraws when the seed changes shows which pages move the most, which is where a new seed tends to slow people down.
The randomized rules mistake: blaming the seed for a strike
When a strike lands on an unfamiliar seed, it is tempting to call the rules broken. They almost never are. Every accepted rule set has defused every one of its sample bombs by following its own hints. A strike is far more likely to come from a mismatch between manual and bomb, a misread detail or a skipped line.
Here is a short checklist to run after a surprise strike, before blaming the seed:
- Same number on both sides? The bomb's seed shows on the setup or briefing screen. The manual's seed shows at the top of its first page. If they differ, every instruction is suspect.
- Edgework read correctly? A wrong battery count or a missed lit indicator changes many answers. Re-read the casing.
- Right list or table? Many pages split by a count, such as the number of wires. Reading the four-wire list for a five-wire module gives a confident wrong answer.
- First matching line? Lists are read from the top and stop at the first true line. Skipping one changes the result.
- Strikes already on the bomb? Some pages depend on the strike count, which goes up after every mistake.
The first item is the one that catches groups most. A seed is just a number, and two numbers can look alike when typed in a hurry. For what a seed is and why the same number always gives the same rules, read what a seed is in games. For the fuller story of how seeds keep a manual fair, see the games with random rules guide.
You can try the standard rules any time at manual 1. Pair it with a freeplay bomb on the same seed, and if a strike still lands, the checklist above is the place to start.