A browser demo for every product, and a four-rung ladder to keep it honest

Every product in this catalogue has something you can run in this browser, without installing anything, without an account. That is the strongest sentence on this site and it is the one most likely to quietly stop being true, because adding a product takes an afternoon and building its demo does not. So it is not a sentence anybody maintains: a test counts the products, counts the built demos, and fails the build if a product arrives without one. It failed three times the week the last three products landed, before it passed.

The harder problem was never building them. It was labelling them.

The word "playable" was carrying two different claims

The first set of labels was Playable, Interactive prototype and Guided demo. That looks like a scale of interactivity, and it is — which is why it was wrong. The question a visitor is actually asking is not "can I click this". It is "is any of this the real thing". Playable was sitting over the demos that run the product’s own source and over the one that plays the product’s shipped audio recordings, and those are not the same claim at all.

There are four rungs now, and each demo states which one it is standing on:

• Real product code — the product’s own source, vendored unmodified, with the SHA-256 of the copy recorded beside it.
• Real product assets — the product’s own shipped material, recordings, sprites, content files, driving a loop written for the browser.
• Interactive recreation — a mechanic rebuilt here, using the product’s real content wherever it has any.
• Guided demo — a walkthrough. Nothing is computed, and it says so.

The ladder only works as a set. "Real product code" means something precisely because "Guided demo" is used honestly one product over. Two demos stand on the top rung today. The number is derived from the demo catalogue rather than written into a sentence, for the same reason every other count here is.

What a hash actually proves

A demo on the top rung vendors the product’s source into this repository unmodified and records its hash. A test recomputes the hash on every build. If somebody edits the vendored copy to make a demo behave better on a phone, the build fails, which is exactly the protection it was built for.

On 30 September, ZUPI shipped a new game to the App Store. A different game: a Pulse Shield held over a Pulse Core, armour-plated threats, Wardens every fifth level. The game whose engine was vendored here was the previous one — a red balloon under an umbrella — and the hash check passed every single build throughout, because the copy was still a faithful copy of the repository it came from.

A hash proves a copy is faithful to the repository it came from. It cannot prove that repository is still the product.

For three days this site ran the wrong game under a sentence reading "the same engine the iOS and Android builds use". Nothing was broken. Every check was green. The vendored engine is deleted now and ZUPI’s demo is an Interactive recreation, written from the store listing and labelled as one — which is a weaker claim and a true one.

The rung that is more interesting than the top one

Forgotten Town is a Flutter and Flame game. A build of it cannot go in a web page at a weight this site would accept, so its merge loop is written for the browser. Everything that loop operates on is the game’s: the board, the chain, the sprites, and the first order with the item it asks for and the coins it pays, read out of the content file the shipped build loads rather than retyped.

Pivumo’s demo plays the app’s own voice files, the shipped ones. Swarm Kingdoms’ demo speaks the game’s own strings, in whichever of its ten languages you pick, falling back to English exactly the way the game’s own localisation function does — because a demo that rendered a raw key where the game renders English would be showing a bug the product does not have. A translation written for this website would have been a worse claim about the product than the product’s own words.

A bot plays all of them before a deploy

A demo that silently stops finishing is worse than no demo, so every one of them is driven in a real browser before a deployment: start it, interact, reach an outcome, report. It runs in several languages, because a demo can break in one and not the others.

It has been wrong about itself twice, and both times the fix was in the harness. Once it scrolled the page instead of playing, because the key it pressed never reached the focused canvas. Once it lost every round of a game it should have won, and the headless version of the same rules showed why: it was not looking at the screen. Writing a loss off as a flaky test would have been the cheap move, and would have left a bot that cannot play standing in for a visitor who can.

What this costs

Eleven demos is a real tax on adding a product, and it is paid deliberately. The alternative is a page of screenshots and a claim, and a studio asking a stranger to believe eleven claims about software they cannot open has to be believed on each one separately. A demo is the one argument that does not need to be believed.