DEVLOG · 4 OCTOBER 2026 · NISSAN DOOKERAN

Before the phone, we put a tiny slice in an emulator.

A first look at the smallest slice of BattleBlocks AI running in an Android emulator, and the problems we are trying to find while it is still small.

We now have a very small slice of the game running in an Android emulator. It is not a phone, not an app and not the game. We built it to find problems early, while they are cheap to fix.

What changed: a tiny slice running in an emulator

The slice is a Builder-only sandbox. Its controls move a falling piece left and right, turn it, drop it, and restart. It is not available to the public. The pieces come from a fixed, scripted sequence, and the page says so: "Engine touch sandbox — scripted piece sequence". There is no Chooser and no opponent yet.

Under the page sits the same Rust engine the rest of the project uses, compiled to WASM. Before the buttons work, the page checks the engine's identity and the WASM file's digest. If either does not match, it stays disabled.

The footage below was captured on 3 October 2026. It shows Chrome 124 in an Android 15 emulator on a Mac, loading the sandbox from a CI-built package. A script sent the taps, not a person's thumbs.

What the clip shows. It runs for 28 seconds, with no sound. Pieces fall one at a time and are shifted left and right, turned and dropped onto a growing stack of blocks. A dashed outline marks where each piece would land. The status line counts pieces, from piece 1 (T) near the start to piece 9 (I) near the end, and the Climb timer keeps running. The row 8 target line stays in place. Nothing in it is edited apart from a crop, a smaller size and a lower frame rate.

What exists today

The sandbox is built, reviewed and merged, and hosted browser checks passed in CI. That covers moving, dropping, restarting, the identity checks, and a hidden app pausing without catching up on lost time when you return. This footage does not show that last case. The emulator run is a separate look at the same build.

One requirement shaped the setup. The engine's checks need a secure page, and a phone's browser only gives you one over HTTPS or from the phone's own localhost. So the emulator reaches the build through a forwarded localhost. A plain address on the Mac's network would fail the check.

Evidence snapshot: PR #131 merge c18ae660dc496ffd85f58c1da8834cf1f85fd597; source a85c6a0ade3036ad7f0831cdf749b98395d53213; WASM sha256 bf90a3a04f7686f03952fe805824eac72065b577e6dce86c44a87d765f265a57; Foundation run 37114251673; emulator capture record of 3 October 2026. The images and clip are from an Android emulator on a Mac, not a physical phone. A physical Seeker test has not been run. This update does not claim a public download, an app package or a playable release.

Next: the questions an emulator cannot settle

We plan to hand the same build to a physical Seeker next, and we have not yet done that. Our questions are about thumbs, not code. Can you reach every button comfortably? Do you tap the wrong one by accident? Does it feel laggy?

We also plan to try the same page inside an app shell, to see whether a WebView behaves like the browser does. The emulator can answer some of this. A real device has to answer the rest.

Later: two roles

After that we plan to add the second role. None of this is in the sandbox yet: Chooser play, a full two-round match and an opponent are on the roadmap, and the touch interface for them is still to be built.

Follow the next drop

We’re sharing progress through our Colosseum project and this devlog. Newsletter signup and playtest news will follow when they’re ready.