For the Chalmers reception 2025, we decided to iterate on a popular event from last year: a two-party bomb defusal game. Obviously inspired by Keep Talking and Nobody Explodes (KTANE), it turned out to be a great twisted lesson in UX design. Setting out to make a frustrating but fair experience, we learnt quite a few things along the way.

Credits

• Me: Bomb logic, puzzle design, writing, backend/network, acting, lighting, media playback system, sound design
• Gustav Bardun: electronics design & programming, writing, acting
• Stella Hiscoke: Music, SFX/sound design, acting

We decided on a couple of design pillars:

• Focus on the experience. A good puzzle is an important foundation, but what then really sells it is the atmosphere, the tactile feel, the interactions between the players and their eventual hard-fought triumph.
• The puzzles should put the complexity in communication, not only obtuse logic riddles.
• We expected groups of around 6 people - a bit on the high side - but we need to ensure everyone feels involved.

The final bomb, powered down

While designing and most importantly playtesting, we ran into a bunch of interesting twists:

This is the first and only time they will play it

KTANE is a game where you repeatedly attempt to defuse the same bomb, iteratively refining you and your accomplice's methods of communication to beat the clock. Here instead it's a completely different challenge of quick thinking and improvisation. Optimising puzzles (and particularly systems) for replayability versus first-time golden path experience are very different tasks, and the two are sometimes even at odds.

As game masters we would like the games to be a good mix of failures and successes, but for the players only this specific round matters. Ideally all players would feel like they managed just by the skin of their teeth, which means the challenges should not be completely fair but rather somewhat favour the players which we'll get to later.

To have some replayability we didn't want to hard code the logic (also because that would be too easy). To make for a good first playthrough, we seed the bomb generator and pick out a couple good seeds that feel right to play.

Playtesting, playtesting, playtesting...

If you sit down and think a bit you can actually catch a lot of sharp edges. Players however always find new corners to stub their toes on that you have already memorised from your own hours of designing and testing. You always need completely new people to try it out, and you must listen to their feedback. No "ah but you just do this..." or "read that more closely". It's the experience that matters.

Progress is very random

How long it takes for a group to solve a submodule is very random, and good performance on one submodule doesn't mean they'll also solve the rest of them quickly. In the end I think we succeeded pretty well in building a bomb that compensates for this.

When solving a submodule, what takes time is figuring out how the module works and what the other person is seeing, which is arguably the deepest and most complex part. Once you get it, actually performing the steps to solve the puzzle should generally be pretty quick. The completion part is the test to prove the players have it nailed down and can perform under pressure, not 200 if-statements to manually execute - that's just tedious.

However, performing the solution takes a predictable amount of time as doing each mechanical action requires a fixed amount of time. The time it takes to arrive at a common understanding or insight varies much more with both luck. You can't really bank on it taking 4 minutes on average for a group to work out what the word maze module does. But since those puzzles are really interesting and fulfilling, it's good to have:

Time-expanding elements

The last puzzle, The Button, is a large red button is a bit of a hassle to solve correctly ("is the left 'RIGHT' light lit?"), but has a decent probability of succeeding if you just guess. This is pretty nice, because depending on if you have 3 minutes or 30 seconds left when the others are done, you can if you need to be rather approximate in reading the instructions and still probably work it out. This really serves the barely-managed feeling well, as long as it actually is/seems to have been actual luck or quick call that saved the day.

A fair, ridiculous manual

The core idea is to make logically relatively simple puzzles that are obfuscated through having to coordinate two groups of people with different information. The manual is the centerpiece for this.

Writing a manual that is funny while irritating and helpful while overly obtuse required a lot of balance. We found it very funny to write

If the leftmost “RIGHT” light is left lit and was alight, lift and release the left button at the right time, that is, when 5 seconds are left [...]

...but it's probably not as fun to parse when you have a timer ticking and people shouting at you. A more reasonable amount of silly fluff was added to occupy the attentions of 3-4 people reading the manual, so they wouldn't immediately get to the actually useful bits.

Architecture

Deciding to build a system that would be less of a bodge than that of last year, after some skepticism I managed to convince everyone that splitting the device into multiple parts was a good idea. A PC would run all bomb logic and all I/O (button presses, light blinks, text displays, sound) would be handled by nodes given commands via OSC. This seemed a bit overkill due to the dramatically increased complexity, but it quickly paid off as the project expanded.

Everything talks OSC over WiFi. You set up a known hotspot or a router, start up the so-called MainBrain running the logic, and the nodes automatically find it and connect. Each device has an ID associated, so that nodes with the same ID get I/O from a specific bomb.

We added both a music/SFX playback node and a light strip node. It required very little programming on the MainBrain as they just hooked into events that were already being transmitted. When doing a beta test at a board game night I had forgotten the LED strip at home. Instead we set up another laptop connected to a TV and a projector and used them as light sources by making a fullscreen app that just showed the current light colour.