# Kaetram: a BrowserQuest rewrite that its own author has abandoned > Kaetram is an open-source 2D HTML5 MMORPG and game engine built on TypeScript, derived from Little Workshop's BrowserQuest and rewritten from scratch, with chunked regions, dynamic lighting, trading, guilds and a plugin system. Its README now states plainly that the open-source version has not been updated for years, that the game is no longer open source, and that anyone using this version is on their own. **Kaetram/Kaetram-Open** — Kaetram is an open-source 2D HTML5 MMORPG. It is an extended version of BrowserQuest (BQ). - Repository: https://github.com/Kaetram/Kaetram-Open - Website: https://kaetram.com - Stars: 748 · Forks: 203 - Language: TypeScript - License: MPL-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/kaetram-kaetram-open ## The README opens by telling you not to expect support The first thing in the Kaetram README is not a feature list. It is a notice in capitals: Kaetram Open-Source has not been updated for years, Kaetram is no longer open source, please do not join the Discord asking for open-source support. It goes on to say that the community is welcome to look at the site to see how the game evolved, that the author will not be helping anyone with this version, and that you are entirely on your own. That notice is the most important fact in the repository, and it changes what kind of project this is. What remains on GitHub is a snapshot of a codebase that was open at one point, with the live game having moved on to a closed model. The history the README gives is useful context. Kaetram is an open-source 2D MMORPG that expands on the original idea created by Little Workshop's BrowserQuest, a game that was itself written as an HTML5 experiment in 2012 to showcase what web technologies could do. Kaetram first started development in 2015 under the name Tap Tap Adventure, and in 2017 it was restarted as a complete rewrite of the BrowserQuest-based code. The package metadata repeats the story in its own words: the assets have remained the same, but the code itself has been completely wiped and redone from the ground up. The README says the entire code base was re-written from scratch, optimized and documented, and that the project aimed to provide both a collaborative gaming experience and a game engine for people who wanted to make their own version. The repository is not archived and the last push was on 2026-10-13, with the default branch being develop. The release list is old: an alpha tagged Kaetram alpha-2.5.1 in May 2023, a legacy tag from 2020, and v1.2.1 from May 2020. The root package.json version is 0.5.5, which is lower than any of those, so the version in the tree and the tagged releases are not tracking each other. ## Two licences and an environment toggle that gates the whole server Kaetram ships with two licence files in the repository root, LICENSE and LICENSE_OPL, and the README describes both the MPL-2.0 terms and an OPL licensing agreement. The instructions are explicit that you must accept the MPL2.0 and OPL licensing agreement by toggling ACCEPT_LICENSE in the environment variable file, and that the server and client are disabled until you have done so. That is a deliberate design decision rather than an oversight. The code under MPL-2.0 is the reusable part, the file-based copyleft, and the assets are separately licensed under CC-BY-SA3.0, with the aim being to hold onto the original BrowserQuest assets while expanding on them. A separate Open Publication Licence file suggests the assets or the game content are published under terms that let them be remixed but require the same terms in derivative work. For someone reusing the code, the practical questions are which parts of the tree carry which terms, and the answer is that the code and the assets are under different licences and the repository makes that visible rather than burying it. The MPL-2.0 badge on the README and the dual file layout in the root is the mechanism. The configuration itself is a two-file arrangement. A .env.defaults file holds the values used unless overridden, and a new .env file overrides them, with the .env.defaults copy-and-rename step documented. There is a separate .env.e2e file for the end-to-end tests, and a .gitignore that keeps local environment files out of version control. For an engine that people are expected to fork, having a single switch that both satisfies the licence and enables the software, with defaults checked into the repository, is a sensible design. It also means the first thing that will fail for a new user is not a missing dependency but an unset flag. ## Yarn workspaces, four scripts and a Node version floor The prerequisites are Node.js and, optionally, MongoDB. The Node version is called out in detail. You need a version greater than or equal to v16.17.1 following the Long Term Support schedule for the most stable experience, and the README says older versions would not work with the current dependencies and package manager. Yarn is enabled through Corepack, and the documented command to do it is: ```bash corepack enable ``` After that, installing the dependencies is a single command: ```bash yarn ``` And the three build commands are equally short: ```bash yarn dev ``` ```bash yarn build ``` ```bash yarn start ``` The dev command runs live development builds, the build command creates production builds, and the start command runs a production build. The package.json shows how these fan out, since each is a wrapper over a workspaces foreach that runs the same script across every non-private workspace package in parallel, with a job count of four. There are separate hub, map and replacer scripts, which map onto the hub and world map parts of the game, and test:run and test:open for the test suite. The toolchain is from a specific moment. The root package.json pins yarn@4.0.0-rc.40, that is, a Yarn 4 release candidate, and the README lists Yarn v3 with workspaces for monorepo packaging among the project features. The linting setup is a split of script and style linting, eslint over TypeScript and Astro files and stylelint over SCSS and Astro files, with a lint-staged configuration wiring both into the pre-commit path. There is a .husky directory, a .commitlintrc and an .editorconfig. The build and end-to-end badges in the README point at separate workflows, so the two are checked independently on the develop branch. ## Region chunking is the piece that makes a browser MMORPG feasible The technology list is where the engineering is described, and the first item on it is the one that matters most for a browser game. Multiplayer runs over microWebSockets. The rendering engine is enhanced, with dynamic lighting, overlays and animated tiles. And there is a region and chunking system, described as the client caching and saving data from the server as needed, with dynamic tiles that change depending on the player's progress in achievements and quests, and global objects such as trees that the player can interact with. That chunking system is the answer to the question every HTML5 MMORPG has to answer, which is how you avoid shipping the whole world to a browser. The client holds a region at a time and asks the server for what it needs, and the map parsing supports compressed tilemaps, so the data transferred per region is smaller as well as bounded. Around that core there is a lot of game. Trading between players, a guild system with chat and multi-world support, an enchantment system for weapons, a quest and achievement system, a skilling system, an attack style system, and a minigame system for special in-game events. The plugin approach appears in three places, which tells you it is a core architectural idea rather than an add-on. Mob behaviour is plugin-based, used for special mobs such as bosses. Item interaction is plugin-based. And there is a hub system for cross-server communication and synchronisation, covering private messages and global messages, plus player synchronisation between servers for friend lists, guilds and login status, and in-game leaderboards served through a REST API. Discord integration is there too, so the in-game chat and the Discord server can talk to each other. For an engine meant to be forked, the plugin system is the part most worth studying, since it is where a fork adds content without touching the core. ## What the code is worth now that the game is closed With the support question answered, the interesting question is what the repository is still good for, and the answer is the engine half of the project rather than the game half. The README states the goal as providing a collaborative gaming experience as well as a game engine for those interested in creating their own version. The engine half survives the notice at the top, because a snapshot of a working browser MMORPG is a useful reference implementation for anyone writing their own, and because the licence permits reuse. MPL-2.0 is file-based copyleft, so a fork of the code in your own project stays MPL-2.0 in those files while the rest of your project is unaffected. The parts most worth studying are the region and chunking system, since that is where the hardest browser-specific problems were solved, and the plugin architecture for mob behaviour and item interaction, since that determines how easily a fork can add content. The parts most likely to age badly are the build toolchain and the dependency versions, which belong to a period when Yarn 4 was a release candidate and the linting stack was on a specific major version of eslint. A fork on a current Node and a current package manager would be a porting project, and the README's own note about the Node floor hints at how far the dependencies have drifted. There is a live version at kaetram.com, and the README invites readers to visit it to see how the game evolved. The development documentation is on the GitHub wiki rather than in the repository, which is another reminder that the living documentation of this project lives outside the code. ## Conclusion Kaetram is worth reading and reusing if you want to build a browser MMORPG, because the chunked region system, the plugin model for mob behaviour and the Yarn workspace layout are a lot of solved design for a project that started as a demo, and the code is MPL-2.0 licensed so pieces can be lifted into a project of your own. It is not worth adopting as a live base for a game you intend to ship, because the author has stated the open-source version is unmaintained and unsupported. Before you commit time to it, verify three things yourself: that the license acceptance toggle in the environment file has been set, since the server and client stay disabled until you do, that your Node.js version is at least 16.17.1 on a Long Term Support release, and that the packages you intend to fork still build with the pinned Yarn release recorded in the root package.json, since the tooling is from a period when Yarn 4 was still a release candidate. ## FAQ ### Is Kaetram still maintained? No. The README states in capitals that Kaetram Open-Source has not been updated for years, that Kaetram is no longer open source, that the author will not be helping anyone with this version and that you are entirely on your own. The repository is not archived and the last push was on 2026-10-13. ### How do I run Kaetram locally? Install Node.js 16.17.1 or newer on a Long Term Support release, enable Yarn with corepack enable, then run yarn to install, yarn dev for development builds, yarn build for production builds and yarn start to run a production build. You must also toggle ACCEPT_LICENSE in the environment file, since the server and client stay disabled until you do. ### What is the relationship between Kaetram and BrowserQuest? Kaetram expands on the original idea created by Little Workshop's BrowserQuest, which was written as an HTML5 experiment in 2012. The assets have remained the same while the code was completely rewritten from the ground up, first as Tap Tap Adventure in 2015 and then as a full rewrite in 2017. ### What licences apply to Kaetram? The code is under MPL-2.0, the assets are licensed under CC-BY-SA3.0, and the repository carries a separate LICENSE_OPL file alongside LICENSE. The README requires accepting both the MPL2.0 and the OPL licensing agreement by setting ACCEPT_LICENSE in the environment variable file. ### Does Kaetram need MongoDB? No. The README says MongoDB is not a requirement for Kaetram to run, but you can store and save user data if you install it and run an online environment with all features enabled, which means setting SKIP_DATABASE=false. Authentication is optional even then, via the MONGODB_AUTH setting. ## Sources - [Kaetram/Kaetram-Open on GitHub](https://github.com/Kaetram/Kaetram-Open) - [License: MPL-2.0](https://github.com/Kaetram/Kaetram-Open/blob/develop/LICENSE) - [Project website](https://kaetram.com) - [README](https://github.com/Kaetram/Kaetram-Open/blob/develop/README.md) - [Releases](https://github.com/Kaetram/Kaetram-Open/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kaetram-kaetram-open