EMAH Ensemble of Machine And Human

Experiments

Critz Arcade

A browser-native probe into trainer control, game feel, and cleaner foundations for Critz.

Critz Arcade is a browser-native experiment built to answer two questions that sit underneath Critz. First: can we use the Fitness Machine side of Web Bluetooth to control ERG mode properly, rather than just reading power in level mode? Second: can we build something visually stronger than the original Critz world, in a form that is easier to extend and less dependent on Three.js?

The point is not just to make a game. It is to isolate the browser, input, and visual layer from the rest of the mess. The original Critz codebase carries too much baggage: hacky websocket management, too many accumulated decisions, and too little confidence in the structure.

Critz Arcade is the clean-room version. New stack. TDD from the outset. AI-assisted development in a Kairo style, with a smaller scope and a tighter feedback loop.

That makes it less of a product and more of a probe. If it works, it does not prove that Critz is solved. It proves that the hard parts can be attacked more cleanly than before, and that the browser still feels like the right place to build.

Interview

What is Critz Arcade in one blunt sentence?

Critz Arcade is an AI-assisted browser experiment designed to test smart-trainer control, visual feel, and cleaner build discipline for a future rebuild of Critz.

What question is it actually trying to answer?

Two questions, really. Can we use the Fitness Machine standards on Web Bluetooth to control ERG mode properly? And can we build something visually stronger that might become the basis of a new version of Critz, potentially without going back to pure 3D?

Why split it out from Critz instead of fixing Critz directly?

Because the original Critz codebase is messy and carries a lot of hacky websocket management with it. This needed a cleaner environment and a different UI stack. The point was to start again with something minimal, TDD-first, and AI-developed from the outset rather than dragging all the old baggage into the next attempt.

What stack shift does that imply?

This rebuild drops the old Three.js path in favour of Phaser 3, Vite, and TypeScript. That matters because the experiment is partly about finding a rendering and interaction model that is easier to reason about and easier to evolve.

What is actually built today?

At the moment there is an avatar moving around the screen and following Bluetooth power measures. That sounds small, but it is already enough to expose one of the real interaction problems: you only get power readings once per second, so movement smoothing matters a lot.

Right now the lerping still feels wrong, and getting that to feel responsive without looking jumpy is part of the current work.

What has felt promising so far?

The encouraging bit is that we have at least rendered something on screen that follows live Bluetooth power readings without falling over. That is not the whole game, but it is a real signal: the browser/input path is at least behaving like a plausible foundation.

What still feels weak or unproven?

Too early to say with much honesty. The work is still at the stage where basic motion feel and control smoothing are being tuned, so it would be premature to claim any real conclusions about the game itself.

What would success actually mean?

If it works, it gives confidence that Critz is worth rebuilding from the ground up. It would also be a useful proof point for Kairo-style agentic development: not just that an agent can generate code, but that a smaller, test-driven, well-scoped build can actually teach you something real.

What I'm Trying to Learn

This experiment is not trying to prove that a trainer-controlled arcade game is a business. It is trying to prove that the browser can still be the right medium for this category of interaction, and that a cleaner build process can get further than the first attempt did.

There are two layers to that. One is technical: Web Bluetooth, Fitness Machine support, power-driven control, smoothing, and visual responsiveness. The other is process: can a Kairo-style, TDD-heavy, AI-assisted workflow produce something cleaner, faster, and more reusable than the older code-first grind?

If the answer is yes, the real value is not Critz Arcade itself. The value is what it unlocks for the next version of Critz.

Experiment Facts

  • Status: In Progress
  • Type: Experiment
  • Parent context: Critz
  • Stack: Browser, Phaser 3, Vite, TypeScript, Web Bluetooth
  • Question being tested: ERG control over Web Bluetooth plus a cleaner visual/input foundation for a Critz rebuild
  • Current signal: Live Bluetooth power can already drive on-screen motion
  • Success signal: Enough confidence to rebuild Critz cleanly and sharpen the Kairo agent workflow