Shipping the real engine, not a recreation
Does letting a visitor play the actual game — the same engine that runs in the app — prove more than any screenshot gallery can?
·
Studio sites usually show products as stills. A still cannot demonstrate feel, and feel is most of what a game is. The alternative is normally a recreation: a simplified browser version that approximates the product. We think a recreation is the worst of both worlds, because it is expensive to build and it is not the thing.
ZUPI turned out to be the case where neither compromise was necessary. Its physics and level generation live in a self-contained module with no third-party runtime dependencies, written against a plain 390×600 coordinate space. That module is the same source of truth the iOS and Android builds run. So the demo on this site does not approximate ZUPI — it imports ZUPI’s engine, level generation, difficulty curve and the three-second stillness rule, and draws them with a renderer written for the web.
The experiment is whether that distinction is worth the engineering, and whether it generalises: how many of our products have a genuine engine boundary we could expose this way, versus how many would need a recreation we have already decided we do not want to build.
Answered, 3 October 2026, and not the way the question expected. ZUPI stopped being the case: the app on the App Store became ZUPI: Pulse Shield on 30 September, a different game, so the module this demo imported is the previous one. The vendoring never drifted — the hash matched to the end — and that is the finding. A hash answers whether a copy is faithful to the repository it came from. Nobody had asked whether that repository was still the product. /try/zupi is a recreation now, built from the public store listing: the thing this experiment set out to avoid building, and the honest answer once the source of truth is gone.
What we learned
Findings so far.
- 01
A vendored copy needs its upstream re-identified, not just re-hashed. The hash answers whether the copy drifted from the repository it came from. It cannot answer whether that repository is still the product, which is the question that actually failed here.
- 02
The engine ported without a single change to its source. A clean boundary between rules and rendering, built for the app’s own reasons, turned out to be exactly what a web demo needs.
- 03
Determinism matters more than expected: because levels derive from a per-level seed, the demo and the shipped app produce identical boards, so what a visitor plays is genuinely level 1 and not a lookalike.
- 04
It does not generalise for free. Products whose logic is entangled with a native UI layer cannot be exposed this way, which makes "is there an engine boundary?" a question worth asking during a build rather than after it.
See it working
A recreation, written for this site. It is not ZUPI’s code and does not claim to be: the shipped game’s source is not in the studio’s repository, so this was built from the public App Store listing — the Pulse Core, the three-second stillness rule, deflections charging a Pulse, six of them per Pulse, armour-plated threats that only the Pulse breaks, splitters, trackers and guard bands. The numbers and behaviours come from that listing and its screenshots; the levels, the difficulty curve and the feel are this site’s, not the game’s. Until 2026-10-03 this page ran the previous game’s engine and said it was the shipped one.