By Greg Nowak. Last updated 2026-10-04.
KotobaMon is a small 3D game in which catching a monster means learning a Japanese word. Players explore an island, meet creatures and answer vocabulary questions during encounters. The game runs in a browser tab without an account. Its progress is saved on the player’s device.
For someone commissioning an interactive experience, the interesting part is how the game was delivered. KotobaMon uses native browser modules, a copy of Three.js kept with the project, artwork assembled in code and Japanese voice lines generated before release. It has no application backend or build step. Those choices kept a complete, playable idea within a small operating footprint, but each choice comes with a boundary worth understanding.
Build the experience around the point of the project
KotobaMon’s vocabulary questions affect a capture attempt. Spoken Japanese appears alongside Japanese writing, romaji and an English meaning, so a beginner can connect sound, spelling and meaning during play. The project case study describes five biomes, twelve species and six missions: enough material to experience the idea as a game rather than judge it from a static mock-up.
That is a useful standard for a client prototype. Identify the one interaction that must feel convincing, then give it enough content and feedback to test with real people. A larger feature list will not rescue a weak central loop. For a training game, also decide what success means: enjoyment, recall, completion or something else. KotobaMon teaches vocabulary; it does not claim to teach grammar or provide a formal assessment.
Why a build step was optional here
The game’s JavaScript is served as native ES modules, and its Three.js files live with the project. There is no bundling or transpilation stage between the files being edited and the files being deployed. For a small, controlled dependency set, that makes releases and handover simpler: a future maintainer can inspect the files the browser actually loads.
This still requires deliberate dependency management. Keep the Three.js core and any add-ons on the same version, record that version, and test upgrades. Use an import map where browser imports need package names resolved to local files. Run the project through a local web server while developing; opening the HTML directly from a file can behave differently. The current Three.js installation guide documents the no-build route while recommending npm and a build tool for most projects, especially as dependencies grow.
If the brief calls for many packages, TypeScript, automated asset processing or several developers changing the same codebase, a build pipeline may earn its upkeep. The useful question is whether that machinery solves a present delivery problem.
Make stable content once, then serve the result
KotobaMon’s terrain, trainer and monsters are assembled from simple shapes in code. That supports a consistent style without a separate 3D modelling workflow. It works well for a stylised prototype or teaching tool; detailed character art and complex animation would change the calculation.
The voice follows a similar pattern. The Japanese lines were generated using the self-hosted Kokoro-82M model, then saved as ordinary audio files. Playing the game does not trigger a text-to-speech request. For fixed dialogue, onboarding or guided tours, this makes playback predictable and allows every clip to be reviewed before publication. If text must change for each visitor, prerecorded clips will not cover that requirement.
For a production release, retain the source script and generation settings, pin the model version, check the model and voice licences, and have a qualified speaker review important pronunciation. Regenerate and version the affected clips when the script changes.
Choose storage according to what a lost save would cost
The game uses the browser’s localStorage for progress. It generally survives a normal browser restart and avoids an account flow. It does not automatically sync across devices. Private-browsing data is temporary, users can clear stored data, and browser settings can prevent writes.
That is a reasonable trade-off for personal game progress. It is a different decision for training records, customer work or anything a business must recover or report on. In those cases, plan for authenticated server-side storage. Even in a small game, handle storage failures gracefully so a player is not led to believe a session was saved when it was not.
| Requirement | Lean choice | Reason to add infrastructure |
|---|---|---|
| Small, stable codebase | Native modules and local dependencies | Many packages, TypeScript or automated builds |
| Fixed narration | Generate, review and serve audio files | Personalised or frequently changing speech |
| Personal progress | Browser storage | Device sync, recovery or completion reports |
| Stylised visuals | Geometry assembled in code | Detailed models or complex animation |
Static deployment still needs a release routine
Static files can produce a broken release when a browser or CDN mixes old and new versions. KotobaMon’s case study describes a stale module appearing after a partial cache purge; the project now applies a consistent version query to its imports and stylesheet.
For a similar site, give changed assets new URLs and publish them before updating the HTML that references them. Configure HTML to revalidate so visitors can discover a new release; versioned assets can be cached for longer. That follows MDN’s HTTP caching guidance. Before calling a release done, test a fresh session and a returning session, check keyboard and touch controls, play the audio, confirm a save survives reload, and open the live site once after deployment. Keep the previous release available for rollback.
Where this approach fits
A campaign experience, interactive demonstration, lightweight learning game or proof of concept can often start with this architecture. It is especially attractive when the content is mostly fixed and the central interaction matters more than accounts or reporting. If the brief already requires shared progress, sensitive records, live collaboration or frequently generated content, include those needs in the architecture from day one.
If you are shaping an interactive web project, talk to Greg about the scope and delivery choices. You can also play KotobaMon to see how these choices feel in a finished experience.
Related on GrN.dk
- AI Crawler Control for Business Websites: Protect Content Without Losing Search Visibility
- Locked Out of Your Apple Developer Account? Fix Access Before October 1
- Vegan Power: The Little Game About Eating Fruit, Not Friends
Need help with this kind of work?
Discuss your interactive web project Get in touch with Greg.
