I stopped writing guides for a co-op game and built solvers instead

#javascript #gamedev #webdev #showdev

I play BOMBANANA! with two friends. It's a three-player co-op bomb-defusal game, and its entire design premise is that no player can verify anyone else's information. The three roles are labeled Blind, Deaf and Mute — one player can't see the panel, one player can't hear the sequence, one player can't say anything out loud.

We lost seven runs in a row on the same module. Not because we didn't understand it. We understood it completely. We were each reading our own version of it, differently, and by the time we agreed on what it said the panel had already moved on.

That's the moment I stopped writing guide pages.

A guide page assumes the problem is knowledge. You don't know how the module works, so you read about it, then you apply it. That model breaks here, because all three of us already knew how the module worked. The problem was that the three of us were holding three different fragments of the same puzzle, with no shared place to put them.

A guide can't fix that. A tool can.

So I built the site the other way around: instead of explaining each module, it resolves each one into a single action. You count the cables, read the LED, get the exact wire to cut. You combine the raised Braille number with the light color and get one arrow. The output is never a paragraph — it's one instruction, because that's the only thing that survives the moment of panic.

A few things I got wrong on the way, in case you're building something similar.

A static site was the right call, but not for the reason I expected. I picked it for cost and speed, which was fine, but the real win was that there's no account and no install. The defuser has one hand free and about four seconds. Anything with a login screen is already too slow.

The page that got used the most wasn't the clever one. I built a resolver that collapses a whole module into one action, and I was proud of it. But the page people actually sit on is a drill for reading Braille digits. The resolver assumes you can already read the input. Most of our failures were in the reading, not the resolving.

Sharing needs to be built in from the start. The drill pages accept a seed in the URL, so the same set of prompts can be replayed by someone else, and the result can be copied as a short challenge line. Without that, nobody has any reason to send the page to a teammate — and a tool nobody sends is a tool nobody finds.

The manual changes between patches, and that is the actual maintenance problem. Lookup tables go stale. I'd rather be corrected than be confidently wrong, so every page carries a note asking to be told when something is off.

If you're building for a game with asymmetric information, the shape I'd reach for is: same inputs as the game, one output, no accounts, shareable state. The content you'd normally put in a guide is still useful — put it next to the tool, not instead of it.

The tools are at https://bombananaguide.xyz/tools/ — the module resolvers are there, and the Braille drill I mentioned is linked from that hub.

It's a fan-made site for a game I just play badly. If a lookup table is wrong for your patch, tell me and I'll fix it the same day.