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

Rocky — Sat, 10 Oct 2026 06:10:35 +0000

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.

What actually mattered building a small SEO site from scratch

Rocky — Fri, 09 Oct 2026 06:10:15 +0000

For the last few weeks I've been building a fan wiki for a three-player co-op game — nine pages, English, no backend, no accounts, no CMS. It exists for one reason: when someone gets stuck and searches for the answer, this should be the thing that shows up.
I'm a developer, not an SEO person, so I wrote down what actually seemed to matter. Some of it is obvious in hindsight. Some of it surprised me.
A static site is not a compromise for this
The whole thing is static HTML on a CDN. I generate the pages in a build step and push a directory. There is nothing to scale, nothing to keep warm, and the pages load before anyone can decide to leave.
The reason I'd pick it again isn't speed, though. It's that there is nothing standing between the reader and the answer. No login wall, no cookie interstitial, no modal asking for an email. If a page exists to answer one question, then every click you add before the answer is a click that costs you the visit.
Structured data was the highest-leverage hour of the project
I added JSON-LD before I had a single visitor, which felt premature at the time. It wasn't.
Most of a page is written for a person. Structured data is the only part written for a machine, and if you don't write it, a machine has to guess what your page is about. It will guess worse than you would.
The other half is that almost nobody fills it in properly. That's not an advantage you have to be clever to earn — it's the one you get for doing the boring thing your competitors skipped.
For a page describing a game, that meant marking up the game itself, the organization behind the site, and the questions as questions — not as a heading that happens to end in a question mark.
Title, description and heading order are most of the work and none of the fun
Every page needs a title written for a search result, a description written to be clicked, and exactly one H1. This is unglamorous, and it is the bulk of the actual effort.
The one rule I'd pass on: write the outline before you write the page. If you can't list the H2s, you don't know what the page is about yet, and no amount of prose will fix that afterwards.
The surprise: being late didn't mean the topic was closed
We started about two weeks after the game launched. When I looked at the results page there were already a dozen sites covering it, several of them far bigger than us. My first instinct was that we'd missed it entirely.
Then I actually read the top results. Most of them answered the same first question and stopped. Sitting right next to it was a second question nobody had written up.
Being late to a topic is not the same as being late to every question inside it. A small site doesn't win the head term. It wins the sentence nobody else bothered to finish.
Tools get linked to. Pages don't.
This is the part that changed how I plan content.
A guide page, however good, is something people read and close. A tool is something people keep open, and occasionally send to a friend. If pages are your only asset, search is your only distribution. If you have one small useful tool, you get a second and weaker channel — people passing the thing around.
So I stopped planning more pages and started planning things that do something. The smallest interaction that turns "I think it says five" into "it says five".
What I don't know yet
I want to be clear that this is a process report, not a results report. The site has almost no visibility right now and I genuinely don't know whether any of it will work.
What I can say is that the checklist turned out to be short and unexciting. Static pages. One clear question per page. Real structured data. An outline before prose. Something interactive that's worth keeping open. Then wait.
There's no trick in there. That was the part I wasn't expecting.

DEV Community: Rocky

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

What actually mattered building a small SEO site from scratch