UKKO

UKKO is a browser-based game engine where the body is the controller. The player stands in front of a webcam; MediaPipe pose and hand landmarkers run entirely in the browser tab and fire gesture triggers; the SvelteKit frontend answers by sequencing video clips while a Go gateway keeps sessions, packs, and scores. No 3D rendering, no controllers, no app — a game is a content pack of clips, transitions, and pose-trigger rules.

The "games are content, not code" thesis

Most game engines ship a runtime and a level editor; UKKO flips that — the runtime is the engine plus a clip library plus a small DSL of pose-to-clip rules. New experiences don't ship new builds; they ship a new pack. The bet is that for the target use case (event installs, museum kiosks, brand activations) the bottleneck is rarely "we need a custom engine," it's "we need this whole thing to ship by Friday with different art." UKKO is the version of that loop that lets non-engineers iterate on the experience.

Architecture

• Frontend — SvelteKit 2 + Svelte 5 + Tailwind v4 + shadcn-svelte. Renders the clip player and runs the whole vision loop locally with @mediapipe/tasks-vision — pose/hand landmarks, motion windows, trigger rules — so no frames ever leave the machine. Built to run as a kiosk full-screen tab.
• Gateway — Go 1.24 with chi for HTTP routing, SQLite (WAL) under sqlc-generated query layer, goose for migrations. Owns sessions, content packs, scoreboards, WebAuthn admin login, and the WebSocket fan-out to the play surface; serves the vision models as static assets.
• Worker — Python 3.12 + FastAPI. Authoring side only: clip transcoding, server-side MediaPipe / RTMO for pack analysis, loop-seam detection, and the AI provider abstraction. The play loop never calls it, which is what lets it drop out of the offline build.
• Deploy — systemd services behind Apache with Let's Encrypt SSL on the public install. No Docker in production; the offline build (see below) collapses the whole stack into one executable.
• Kiosk extras — a smile-photo capture that prints winner photos on the spot (Windows GDI+ print chain with an operator-side layout editor for photo + sponsor logo placement), a mirror-box pose overlay, and a bank of keyboard-chord operator panels for tuning gesture sensitivity live at the event without a rebuild.

Offline-first by design

UKKO was built for a fully air-gapped event deployment in May 2026. The just offline-kit recipes cross-compile the Go gateway with the SvelteKit static export embedded, CGO-free with a pure-Go SQLite, into a single windows/amd64 executable — plus a Raspberry Pi build — and wrap the Windows drop in an NSIS setup installer that the public site serves as a version-pinned download. Browser-side MediaPipe handles pose detection in the offline build, so the kiosk needs no Python and no GPU. The smoke-test recipe rehearses the full one-command bring-up on real hardware. The architecture rationale lives in docs/offline/feasibility-windows.md; the constraints those binding guardrails enforce live in the repo's CLAUDE.md.

Why "UKKO"

Ukko is the Finnish god of weather, sky, and thunder — a deity whose business is making things happen at scale by waving his hands. That's the metaphor. The engine doesn't care what the gesture is; it cares that the gesture happened, and that the world responds.