By Greg Nowak. Last updated 2026-09-03.
KotobaMon (コトバモン, “Word Monster Safari”) is a small 3D game for learning Japanese. Players explore an island, meet creatures and answer vocabulary questions while trying to catch them. It runs in the browser, requires no account and saves progress on the player’s device.
For a business owner or agency team, the useful story is not simply that somebody made a browser game. It is how deliberately limiting the architecture made a polished interactive idea practical to launch: no application backend, no runtime voice API, no conventional build pipeline and very few external assets.
Those decisions are not universally better. They are examples of matching technical complexity to the job instead of automatically adopting the stack of a much larger product.
A complete idea, not just a technical demo
KotobaMon has five explorable biomes, third-person movement, turn-based encounters, six missions and a twelve-species KotobaDex. Each monster represents a Japanese word. During a capture attempt, the player answers a vocabulary question and receives a bonus for getting it right.
Spoken Japanese is paired with Japanese writing, romaji and an English meaning. That combination matters because it puts sound, spelling and meaning inside the same action. The learning mechanic is part of the game loop rather than a quiz pasted onto an unrelated experience.
This distinction applies to commercial prototypes too. A credible prototype should let stakeholders experience the central proposition. It does not need every future feature, but it does need enough design, feedback and content to answer, “Does this idea work?”
No build step was a scope decision
The 3D layer uses Three.js, with JavaScript delivered as native ES modules. The files in the project are effectively the files deployed to the web server; there is no bundling or transpilation stage.
That is a reasonable choice for a small application with a controlled dependency graph. It reduces CI configuration and avoids having to reproduce a discontinued toolchain during a future handover. It also makes individual production files straightforward to inspect.
However, “no build step” does not mean “no dependency management.” The current Three.js installation guidance recommends npm and a build tool for most projects, particularly as dependencies multiply. It also documents a no-build route using browser modules and import maps.
KotobaMon keeps its library files with the project rather than depending on a public CDN at runtime. The trade-off is that upgrades, module paths and compatibility testing remain the project owner’s responsibility. For a larger team, TypeScript, automated asset optimisation or dozens of packages can quickly make a build pipeline worth its cost.
Procedural art reduces the asset operation
The island, trainer and monsters are assembled from simple shapes in code instead of imported character models. That helped produce a consistent low-poly style without creating a separate modelling workflow or maintaining a large catalogue of binary files.
For client work, procedural visuals can be effective in configurators, simulations, maps, teaching tools and early product demonstrations. They make variations easier and reduce reliance on third-party asset marketplaces. They do not automatically make a project legally risk-free: libraries, fonts, reference material, generated media and brand resemblance still need review.
Generate voice once when the script is stable
KotobaMon uses the open-weight Kokoro-82M text-to-speech model in a self-hosted generation workflow. The dialogue is rendered into audio files ahead of release, and the browser receives ordinary static audio rather than calling an AI service every time somebody plays.
This is a useful pattern for fixed material such as guided tours, onboarding lessons, pronunciation examples and product walkthroughs. It removes per-play inference, keeps playback latency predictable and allows the finished audio to be reviewed before publication.
The review step is important. Self-hosting changes where generation happens; it does not guarantee correct pronunciation, natural delivery or unrestricted use. A production workflow should pin the model version, record its licence, check important names and phrases with a qualified speaker, and retain the source script so clips can be regenerated consistently.
Local saves are convenient—but intentionally limited
Progress is stored with the browser’s localStorage. It normally persists between sessions and is scoped to the site’s origin, making it suitable for low-risk preferences and game progress without requiring accounts or a database.
It is not durable customer storage. A player can clear it, browsers may prevent persistence, private-browsing data is temporary, and progress does not automatically follow the user to another device. If a training product needs completion reports, regulated records, team administration or reliable recovery, that requirement changes the architecture: use authenticated server-side storage.
| Project requirement | Lean browser-first choice | When to add infrastructure |
|---|---|---|
| Small, controlled codebase | Native modules and vendored dependencies | Add a build system for many packages, TypeScript or automated optimisation |
| Fixed narration | Generate and review audio before release | Use runtime speech when text must be personalised or frequently changed |
| Disposable or personal progress | Save in the browser | Add accounts and a database for sync, reporting or recovery |
| Stylised, repeatable visuals | Generate geometry in code | Use an asset pipeline when art direction requires detailed models or animation |
| Static release | Serve versioned files through a CDN | Add application services only for genuinely dynamic features |
Static deployment still needs release discipline
Fewer moving parts do not remove operational work. Releases still need version control, a repeatable upload process, browser testing and a rollback copy. Cache behaviour needs particular attention: HTML should revalidate so it can discover a new release, while versioned JavaScript, audio and other immutable assets can be cached for much longer. This is the cache-busting pattern documented by MDN.
A sensible release checklist is short: test keyboard and touch controls, open a clean browser profile, confirm saved progress survives a reload, verify every audio file, deploy versioned assets, publish the HTML entry point and run one live smoke test. Small systems benefit from boring procedures just as much as large ones do.
Where this approach earns its keep
This architecture fits an interactive product demonstration, campaign experience, lightweight teaching game, trade-show installation or proof of concept that must feel real without becoming a permanent software platform. It is less suitable when the brief already demands shared accounts, sensitive data, live collaboration, detailed analytics or constantly changing generated content.
The lesson from KotobaMon is not to avoid modern tooling. It is to identify which moving parts create user value and decline the rest until they are justified.
Planning an interactive web project?
If you need to turn an idea into a credible prototype or low-maintenance production experience, talk to Greg about the scope and technical trade-offs. You can also play KotobaMon in your browser to see the approach in practice.
Related on GrN.dk
- Why Your Website’s Third-Party Stack Needs a Real Owner
- AI Crawler Control for Business Websites: Protect Content Without Vanishing from Search
- Background AI Tasks Need Queues—not Just Longer API Calls
Need help with this kind of work?
Discuss an interactive web project Get in touch with Greg.
