KotobaMon: Shipping a 3D Browser Game With No Build Step and Self-Hosted Voice
By Greg Nowak. Last updated 2026-07-19.
KotobaMon (コトバモン, “Word Monster Safari”) is a small 3D game that runs entirely in a web browser. You walk a low-poly island, meet wild monsters and catch them — and because every monster is a Japanese word, catching them is how you pick up vocabulary. It is live at fantasy.grn.dk, needs no download, and was built as a self-contained side project.
The interesting part for anyone commissioning software is not the game itself but the constraints it was built under: no build step, no licensed art, no paid voice API and no backend to keep running. Those choices are what let a project like this ship quickly and cost almost nothing to host — and they are the same choices that decide whether a client prototype turns into a maintenance burden.
What the game actually does
KotobaMon drops you on an island with five biomes — meadow, forest, lake, volcano and snow — and lets you roam in third person with the keyboard or an on-screen joystick. Wild monsters wander the map. Walk into one and a turn-based battle starts, with a simple type chart deciding what is strong against what. Weaken a monster and you can throw a Kotodama Orb to catch it.
Catching is where the learning happens. Each attempt shows a short Japanese vocabulary quiz; answer correctly and you get a catch bonus and points. Progress runs through six missions and a KotobaDex of twelve species to complete, including a rare one you will not see often. The whole session saves to the browser, so there is no account to create and nothing to log into.
Every monster is a vocabulary word
The teaching idea is deliberately literal. A monster is not decorated with a Japanese label; the monster is the word. ヒバナ (hibana) is a spark, コダマ (kodama) is a tree spirit, and so on across the roster. Catching the creature and answering its quiz ties the sound, the writing and the meaning together in a single action, which sticks better than a flashcard on its own.
Every spoken line has full Japanese voice-over with simultaneous subtitles in Japanese, romaji and English. A learner can listen, read the kana, check the romaji reading and confirm the meaning without leaving the screen — the kind of scaffolding that makes the game usable by a genuine beginner rather than only by someone who already reads Japanese.
No build step, on purpose
KotobaMon is built on plain web technology. The 3D is handled by Three.js, vendored directly into the project, and the rest is vanilla JavaScript using native ES modules. There is no bundler, no transpiler and no build pipeline: the files that are written are the files that ship. That removes an entire category of tooling problems — dependency upgrades that break the build, lockfile drift, a CI step that has to be kept green — and it means the project will still run years from now without a toolchain to resurrect.
The visuals are procedural. The island terrain, the monsters and the trainer are all assembled from basic shapes in code rather than modelled in an external tool, so there are no art files to license, store or keep in sync. That keeps the whole thing small and legally clean — the monsters are, as the game puts it, one hundred per cent legally distinct — and it is a useful pattern well beyond games: generate what you need in code instead of managing a pile of binary assets.
Self-hosted AI voice instead of a metered API
The Japanese voice-over is generated with a self-hosted text-to-speech model (Kokoro) running on the same server, not a metered cloud voice API. A small script turns the script lines into audio files once, and those files are then served as static assets. There is no per-character billing, no third party receiving the text and no runtime dependency on an external service that could rate-limit or disappear.
For a hobby game the saving is trivial, but the shape of the decision is exactly what matters on client work. Any feature that calls a paid AI API on every use carries an open-ended cost and a privacy question. Where the output can be generated ahead of time — voice lines, canned responses, standard imagery — doing it once and self-hosting the result is often cheaper, faster at runtime and easier to reason about.
| Build decision | What it trades away | Why it matters on client work |
|---|---|---|
| No build step (vendored Three.js, native ES modules) | Some convenience of a modern bundler | Nothing to keep green; the project still runs in years without a toolchain |
| Procedural art, no external assets | The polish of hand-made models | No licensing, no asset store, small footprint, legally clean |
| Self-hosted TTS, generated once | The very latest cloud voices | No per-use billing, no data sent out, no runtime API dependency |
| Browser localStorage saves, no backend | Cross-device sync and accounts | No database or server to run, patch or secure |
| Static files behind a CDN | Server-side rendering and dynamic pages | Cheap to host, fast worldwide, little to attack |
How it ships and stays cheap to run
Because the game is just static files, hosting is deliberately boring. It sits behind a Cloudflare edge in front of a plain origin server, saves progress in the browser and has no database or application server to maintain. Deploys are a file copy plus a cache purge, with each release version-stamped so the browser never serves a stale mix of old and new code — a small discipline that heads off the maddening “it works on my machine but the live site is broken” class of caching bug.
The result is a product with almost no moving parts to fail. There is no server process to crash at 3am, no scaling to plan for a traffic spike and no secret to rotate. That is not the right architecture for everything, but for anything that can be expressed as static assets plus a little client-side state, it is remarkably robust for the effort involved.
What a build like this is good for
A game is an easy way to show these techniques, but the same approach fits plenty of ordinary client needs: an interactive product demo, a gamified onboarding or training module, a configurator, a teaching tool, or a proof of concept that has to look real without a large budget behind it. The common thread is shipping something interactive and self-contained quickly, then keeping it cheap and low-maintenance afterwards.
KotobaMon is a small, honest example of that: a complete, playable experience with 3D graphics, AI-generated voice and a real learning mechanic, built on ordinary web technology and running on infrastructure that costs almost nothing to keep alive.
Need something interactive built?
If you have an idea for an interactive tool, demo or teaching experience and want it built to ship fast and stay cheap to run, get in touch with Greg. You can play KotobaMon here.
Related on GrN.dk
- If the Facts Need JavaScript, AI Search May Miss the Full Page
- AI Voice Agents Need More Than a Number and a Realtime Model
- AI agents need a browser policy before they start clicking around