You have built a game you play with your body: a webcam, a pose model, maybe MediaPipe or TensorFlow.js, and a canvas that reacts when you jump. Now where do you put it? For most indie games the answer is obvious — itch.io, the default home of indie games, with a built-in audience, game jams and payments. For webcam motion games the answer is less obvious, because the camera, the ML model and anything multiplayer push against what a static HTML5 upload does well. We shipped CamPlay, a set of five body-controlled browser games, on our own site. This is what we weighed, so you can make the call for your game.
What itch.io gives an indie game for free
- An audience. People browse itch.io looking for new indie games, and tags, collections and jams put small games in front of them. Your own domain starts at zero visitors.
- Payments with a revenue share you choose. Free, pay-what-you-want or paid, and you decide how much of each sale goes to itch.io.
- HTML5 hosting. Upload a zip with an index.html and players run it in the browser, embedded in the project page. No server to run.
- Community tools. Devlogs, comments, ratings and game jams — the jam route is how many motion-control prototypes find their first players.
Where a webcam game rubs against an HTML5 upload
None of these are dealbreakers; they are the things to test before you commit.
- Camera permission inside an iframe. HTML5 games on itch.io run in an iframe on a different domain from the page. Browsers only let a cross-origin iframe call getUserMedia if the parent page delegates the camera permission, so test on the live project page, not just locally. If the prompt never appears, a fullscreen or open-in-new-window launch is your fallback — and a keyboard fallback is worth building anyway.
- Model download size. A pose model plus its WASM runtime is several megabytes before your game’s own assets. CamPlay loads MediaPipe’s lite pose landmarker from Google’s CDN at runtime rather than bundling it; on itch.io you would either do the same or ship it inside the zip.
- Performance in someone else’s page. Your game shares the tab with the itch.io page around it. Pose inference and rendering already compete for the main thread — CamPlay runs inference at about 22 Hz instead of every frame, and keeps ads and third-party scripts completely off game routes for this reason.
- Static only. HTML5 uploads are static files. Leaderboards, accounts and multiplayer need a backend you host yourself (Firebase, Supabase, your own server), called from the game. That works from inside itch.io too, but at that point you are running infrastructure either way.
- Trust. Players are rightly cautious about granting camera access. Say clearly on the page whether video leaves the device. CamPlay’s answer — it doesn’t; inference runs locally — is explained in how CamPlay tracks your body without uploading video.
Why we chose our own site for CamPlay
CamPlay is not one game; it is five games on one shared pose engine, with accounts, leaderboards, stats and live rooms for up to eight players. Once you have that much platform, the game is no longer a self-contained zip, and three things tipped us toward our own domain:
- One engine, many games. Every game polls the same input snapshot — speed, jump, duck, lean — and shares the same frame coach and keyboard fallback. Players set up once and every game behaves the same way. That is a platform, and a platform wants its own URL. The architecture is in building motion-controlled games for the browser.
- Multiplayer that needs a backend anyway. Race and party rooms share a random seed and a synced start time, so every machine builds the identical course; only small progress updates go through a realtime database. With the backend already required, hosting the game next to it was simpler.
- Control of the page. We decide what loads next to the game (nothing, on play routes), how the camera prompt is introduced, and what the share links look like.
The cost is real: discovery. Nobody browses our domain by accident, so we write articles like this one, make videos, and rely on search. If your game is a single jam-sized idea, that cost is probably not worth paying.
How to decide
| Your game | Start on |
|---|---|
| Jam prototype or single small game | itch.io — audience and feedback beat everything else |
| Paid game, or you want tips | itch.io — payments are solved |
| Needs accounts, leaderboards or live multiplayer | your own site, or itch.io plus your own backend |
| Several games on one shared engine | your own site |
| You are unsure | both — itch.io page for discovery, linking to your site |
The hybrid is underrated. An itch.io project page with screenshots, a video, a devlog and a playable demo collects the audience itch.io is good at, and points players to the full experience on your own domain. You keep the community and you keep control of the platform.
A checklist before you publish a webcam game anywhere
- Serve over HTTPS — browsers block camera access on insecure pages.
- Ask for the camera after a click, with a sentence explaining why, never on page load.
- Handle “permission denied” and “no camera” gracefully: keyboard controls or a clear message, not a frozen canvas.
- Pause when tracking is lost, instead of replaying the last input forever. CamPlay treats a pose stream silent for 350 ms as lost.
- Design for real rooms: average lighting, a laptop on a desk, the player a metre away. Upper-body signals are far more robust there than full-body ones — see how we detect jumps, ducks and jogging.
- Show a 20-second video on the page. Body-controlled games are hard to understand from screenshots; seeing someone play sells it instantly.
If you are a player rather than a developer, the companion piece is CamPlay vs itch.io for body-controlled games. And if you have built a webcam game, we would love to play it — send it via our feedback page.