I run a free browser-games site with a few hundred HTML5 games, and most of them are originals I wrote or adapted myself. The pages for them were fine: a title, a description, controls, a few paragraphs. They were also forgettable, and nothing on them was something only I could say.
So I added one section to every game page: "Inside : what we checked". It holds a method line, two real screenshots, and four to six facts about the game. The rule is strict, and it turned out to be an excellent bug finder.
The rule
Every number in a fact has to be in the game's code. If I derive it rather than read it, the sentence says "about". Every screenshot caption describes only what is visible in that frame. And a fact must never advertise a bug: if I cannot write the sentence honestly, I fix the game or drop the sentence.
That last clause is where the work was. You cannot write "the snake can turn back on itself without dying" and publish it. You go and look at the input handler.
What writing the facts found
I did this for 118 games. These are the problems it surfaced, all fixed the same day:
- Snake let you reverse direction if you pressed two turns quickly.
- Hangman and word scramble swallowed the letter M (word scramble also dropped H and N).
- Blast Arena showed a 60-second clock that did nothing.
- Tangram: the twin pieces were not interchangeable.
- Pinball: the slingshot scored on every frame it was touched, not once per hit.
- FreeCell: the "Played" counter never counted.
- Road Cross: the game frame was wider than its canvas.
- Wreck Arena showed a DEMO badge during play.
- Three label typos (checkers, pool blitz, spider solitaire), and the Asteroids description promised a hyperspace button the game does not have.
None of these would have shown up in a test suite, because I have none. They showed up because I had to make a specific, checkable claim and then check it.
Why this works better than "write good descriptions"
A vague description can never be wrong, so nobody checks it. A sentence like "the clock runs for 60 seconds" is falsifiable, so you open the game and watch the clock. Forcing the copy to be checkable made the copy an audit.
It also gives the page something a template cannot: a sentence that is true of this game and no other.
What I would do again
- Make claims that can be wrong, then check them against the code, not against memory.
- Say "about" for derived numbers.
- Treat a fact you cannot honestly publish as a bug report.
- Keep screenshots to what is visible; do not caption what you remember.
The pages are on 360 PlayZone. If you want to see what a checked page looks like, Snake Arena and Hangman are two of them.
Written by an AI assistant from my own repo notes and commit history.
Top comments (1)
This is a strong argument for treating content assertions as tests rather than copy. The most valuable part is that the facts had to be independently checkable, which exposed defects in the surrounding code. I would preserve the source or rule next to every assertion so a future correction changes the evidence and the rendered claim together.