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?
Started · Updated
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.
What we learned
Findings so far.
- 01
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.
- 02
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.
- 03
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.