WarriorJS: a Node.js game where JavaScript and TypeScript are the strategy

What WarriorJS actually solves, and who it is for

Most introductory programming material gives you a function signature and an expected return value. WarriorJS gives you a floor plan, some enemies, and a warrior that only moves when your code tells it to. The README describes the premise directly: you write JavaScript or TypeScript "to guide a warrior through towers full of enemies," and each floor is a puzzle where you battle sludge, dodge archers, rescue captives, and reach the stairs alive. The code you write is the strategy, and the README is explicit that there is no clicking and no dragging.

That framing matters because it changes what a beginner is asked to do. Instead of implementing a function to satisfy a test, you decide what the warrior should do this turn, and the game tells you what happened. The audience the README names is broad: people writing a first if statement, and people refactoring for a perfect score. Those are two different products sharing one engine. A beginner gets immediate, visual cause and effect. An experienced developer gets a constrained optimization problem, because the scoring rewards efficient solutions.

The repository itself is a pnpm and Turborepo monorepo. The top level contains apps, libs, and towers, plus a docs directory and a logo directory. The package.json is marked private, uses pnpm@10.11.0 as its package manager, and sets engines.node to >=24. That is the toolchain for contributing to the project, not for playing it. The README's Quick Start asks players for Node.js 22 or later, and the CLI is distributed on npm. Those two numbers differ, and the distinction is worth keeping straight before you file a bug about your Node version.

How the game loop works: Player.js, towers, and the Player API

The mechanism is a file the game generates and then reads back. After you launch the game and create a warrior, WarriorJS writes a README.md containing your first level's instructions, and a Player.js file where your solution goes. You edit Player.js, run warriorjs again, and watch the result. There is no build step described for players, no test runner, and no separate simulator command. The CLI is the loop.

The level instructions live in a README rather than in a console prompt, which is a deliberate choice with consequences. It means the puzzle statement is a file you can keep open next to your code, and it means the instructions are versioned alongside your solution. It also means the first thing a new player does is read Markdown, not a tutorial screen.

The API surface is documented separately. The README points to a Player API page under warrior.js.org/docs/player/space-api, alongside gameplay and towers pages. The name "space-api" is a hint about the model: your warrior exists in a space, and the API is how you query and act on that space. The README does not enumerate the individual methods or the exact shape of the warrior object, so treat the docs site as the source for method names rather than guessing them from the level README.

Towers are the content unit. The README says the best way to contribute is to build a tower, described as a set of levels that other players can install and play. That is the extension point: abilities and units can be added, but a tower is how you package a sequence of floors. The towers directory at the repository root is where those live in the monorepo, and the docs site has a towers page covering them.

Installing the CLI and playing your first floor

The README gives a three-step Quick Start. First, install Node.js 22 or later. Second, install the CLI globally from npm. Third, launch the game.

npm install --global @warriorjs/cli

The package name is scoped, so the unscoped warriorjs name on npm is not what you want. After the install completes, the warriorjs command should be on your path.

warriorjs

On first run the game walks you through creating a warrior and choosing a tower, according to the README. What you should see is an interactive prompt, not a level. Once you have answered it, the game generates a README.md for your first level and a Player.js file. Open the README.md first; it holds the instructions for that floor.

warriorjs

After you write a solution in Player.js, run warriorjs a second time. This is the entire iteration cycle: edit, run, read the outcome. The README does not describe a watch mode, a hot reload, or a way to step through a floor turn by turn, so expect to run the command repeatedly and read the output each time.

If you would rather not install anything, the README offers a browser option at warriorjs.com. It does not say whether browser progress and local progress are shared, so do not assume you can start on the web and continue in the CLI.

Where WarriorJS is the wrong tool

The most obvious limitation is that the README does not document rollback, undo, or a way to reset a single floor. If your Player.js edit makes things worse, the documented recovery path is to edit the file again. There is no described checkpoint system, and no mention of saving a solution before trying an alternative. For a learner, that is mostly fine. For someone treating a tower as a scored challenge, it means keeping your own copies of working solutions outside the game directory.

The second limitation is the documentation boundary. The README points to the docs site for gameplay, towers, and the Player API, and it does not restate the API in the repository README. If warrior.js.org is unavailable or a page has drifted from the CLI version you installed, you have a generated level README and not much else. The repository does contain a docs directory, so the source is in the tree, but the README does not tell you how to build or serve it locally.

Third, this is not a course. There is no syllabus, no assessment, and no notion of completing a track. A tower is a set of levels, and the README's framing of contribution is building more of them. If you need graded progression or a certificate, this is the wrong shape of product.

Finally, the repository's last push was on 2026-03-27. That is recent enough that calling it abandoned would be wrong, but the README does not publish a support policy, and no releases were retrieved for this review. If you are building a tower that other people will install, you are depending on an interface whose versioning the README does not describe.

How WarriorJS compares with Screeps, CodeCombat, and ruby-warrior

The README states plainly that WarriorJS was born as a port of ruby-warrior, with credit for the original idea going to Ryan Bates. That lineage explains the design. ruby-warrior is a terminal game where you write a Ruby player class and run it against a tower of levels. WarriorJS keeps that structure and moves the language to JavaScript and TypeScript, which is the whole point of the port.

Screeps is the closest comparison people search for, and the difference is scope. Screeps is a persistent, multiplayer world where your code runs continuously against other players' code. WarriorJS is a single-player sequence of puzzle floors that you run on demand. If you want an always-on simulation with resource management across a shared map, WarriorJS is not that. If you want to finish a floor in one sitting and see the result immediately, the persistent model is a much heavier commitment.

CodeCombat sits on the other side: it wraps programming in a game with a graphical interface and a guided progression, aimed at classrooms and younger learners. WarriorJS has no described graphical editor. Your interface is the terminal and a text editor, and the README's promise is logic and sharp thinking rather than a story campaign. That makes WarriorJS less approachable for a complete beginner and more comfortable for someone who already lives in an editor.

Codewars and freeCodeCamp are the other names that come up. Both give you discrete exercises with automated checks, and neither asks you to write a program that persists across turns. WarriorJS's distinguishing feature is state: the warrior has a position, the enemies have positions, and your code runs repeatedly against a changing board. That is closer to writing a small agent than to solving a kata.

Maintenance, the monorepo, and what the MIT licence means here

WarriorJS is licensed under MIT, and the LICENSE file is at the repository root. For players, that is a permissive licence with few practical constraints: you can read the source, fork it, and use it in your own material. For anyone building a tower, the MIT grant covers the project's code, but the README does not discuss how a tower you author should be licensed or how it is distributed. That is a question to settle yourself rather than assume.

Contributing has a different cost profile from playing. The root package.json declares pnpm@10.11.0 and engines.node >=24, while the player-facing README asks for Node.js 22 or later. The build script runs turbo run build with a filter excluding the website, and there are separate lint, typecheck, test, and test:coverage scripts. Biome handles linting, Vitest handles tests, and lefthook installs git hooks through the prepare script. None of that is needed to play a tower.

The upgrade surface for players is the CLI package. The README does not describe version pinning, a changelog policy for the CLI, or how towers declare compatibility with a CLI version. A CHANGELOG.md exists at the repository root, and that is the place to look before upgrading, since the README itself gives no migration guidance. If you maintain a tower that others install, treat the CLI version as an interface you do not control and check the changelog on each upgrade.

Editorial conclusion

Adopt WarriorJS if you want a self-paced JavaScript or TypeScript exercise where the feedback loop is a game run rather than a test suite, and if you already have Node.js 22 or later. Skip it if you need a structured curriculum with graded assessments, or if you want a browser-first experience with nothing installed locally, in which case the web version at warriorjs.com is the only path the README offers. Before committing time, verify the generated README.md for your first level, the Player API page at warrior.js.org/docs/player/space-api, and whether the tower you choose is one of the bundled towers or a community tower you install separately. The repository's last push was on 2026-03-27, so if you plan to build a tower on top of it, check the towers directory and the contribution guide first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. olistic/warriorjs on GitHub
4. Project website
5. README