WarriorJS: Write JavaScript to Survive a Tower

What WarriorJS Is and Who It Is For

WarriorJS presents programming as a literal battle. A warrior stands at the bottom of a tower, and each floor is a puzzle: enemies to defeat, captives to rescue, traps to avoid. The only way through is code. Players write JavaScript or TypeScript inside a generated Player.js file, describing how the warrior should behave each turn, and then run the CLI to watch the results play out.

The game originated as a port of ryan bates's ruby-warrior, which used Ruby. WarriorJS translates that concept to the JavaScript and TypeScript ecosystem, making it accessible to the much larger community of web developers. It targets developers who already know some JavaScript fundamentals and want practice in logical thinking, conditionals, and state management. Absolute beginners without any programming background will find the game's puzzle framing disorienting rather than helpful, because the game teaches strategy, not syntax.

The Floor-by-Floor Challenge Loop

Every floor is a self-contained puzzle. WarriorJS generates a README.md file describing the current level's layout, enemies, and objectives. The player reads that file, writes a solution inside Player.js, and then runs the CLI again. The game replays the warrior's moves and reports success or failure.

The code the player writes is the strategy. There is no mouse, no drag-and-drop, no visual editor. A warrior has abilities exposed through a Player API that the official documentation covers at warrior.js.org/docs/player/space-api. The warrior can sense adjacent spaces, move in a direction, attack, rest to recover health, or rescue a captive. Players who rely entirely on attack-forward patterns will fail floors with archers on the opposite wall. Floors reward players who think in terms of state: when is health low enough to rest? When is an enemy close enough to attack without taking unnecessary hits?

The tower structure means difficulty scales progressively. Early floors introduce a single enemy. Later floors combine enemy types with spatial constraints that force more complex logic. The game can also be played in a browser at warriorjs.com, which sidesteps the local Node.js setup for players who want to try it before committing.

Installing WarriorJS and Starting Your First Game

The package.json for the repository specifies Node.js 24 or later. Install the CLI globally through npm:

npm install --global @warriorjs/cli

Once installed, starting a new game is a single command:

warriorjs

The CLI walks through creating a warrior and choosing a tower. After setup, WarriorJS generates a project directory containing a README.md with the first level's instructions and a Player.js file where the player writes code. Running `warriorjs` again executes the solution against the current floor and prints the outcome. The cycle continues: read the floor description, write or revise logic, run, observe.

Towers are the collections of levels that form the game's progression. The official documentation at warrior.js.org describes both playing existing towers and building new ones.

Writing Solutions and the Player API

The player's entire interface is the Player API, which exposes methods on the warrior object. Every turn, WarriorJS calls a `playTurn` function that the player defines in Player.js. Inside that function, the player interrogates the world through the API and issues exactly one action.

The API design has a useful constraint: the warrior can only act once per turn. This forces players to think about priority. Should the warrior attack an adjacent enemy or step back to recover health first? The consequence of acting without checking state is immediate: a warrior that attacks an empty space wastes a turn.

Because the code is just JavaScript or TypeScript, players are free to use any language features they know: closures to carry state between turns, arrays to track history, conditional chains to model complex decision trees. The game validates the code by running it, not by grading a quiz, which means players learn through direct feedback from the simulation rather than a scoring rubric.

Where WarriorJS Falls Short

WarriorJS is thin on built-in towers. The repository's towers directory exists, but the README does not document which towers ship by default or how many floors each contains. Players interested in an extended campaign will need to find or build towers beyond the defaults, which is a non-trivial undertaking described at warrior.js.org/docs/player/towers.

The game is entirely single-player and offline. There is no multiplayer mode, no leaderboard, and no social comparison mechanism. Players who learn best through competition or collaborative challenge will find WarriorJS isolating.

The project's package.json requires Node.js 24 or later. Developers working in constrained environments with older Node.js versions will need to upgrade before they can run the CLI. The README mentions Node.js 22, but the package engines field states 24, which is the enforced constraint.

The last push to the repository was on 2026-03-27, which is just past the six-month threshold. There are no GitHub releases tagged for the project, and the pace of updates is unclear from the repository alone.

WarriorJS vs. Screeps and CodeCombat

Screeps is the closest in spirit to WarriorJS among the alternatives. Both games ask players to write JavaScript to control characters. The difference is the game model. Screeps runs a persistent server where bots compete in a shared world continuously, 24 hours a day. Players' code must handle dynamic, adversarial conditions from other players' bots. WarriorJS is a contained, sequential puzzle game. Each floor is a defined problem with a known solution space. WarriorJS is better for learning JavaScript fundamentals in a low-pressure context. Screeps is for developers who want competitive automation and are comfortable with continuous deployment.

CodeCombat appears in the WarriorJS related searches and operates as an interactive coding curriculum with teacher dashboards, classroom modes, and structured courses. CodeCombat has a commercial component and is aimed at educational institutions as much as individual developers. WarriorJS is MIT-licensed, runs entirely locally, and has no curriculum structure or progress tracking. Developers who need a certifiable learning path should look at CodeCombat. Developers who want an unstructured, open-ended coding challenge will find WarriorJS a better fit.

Maintenance, Tower Community, and the MIT License

WarriorJS is licensed under the MIT License, which permits use in personal and commercial projects without restriction. The codebase is a TypeScript monorepo managed with pnpm workspaces and built with turbo. It uses vitest for testing and biome for linting.

The most meaningful way to contribute, according to the README, is to build a tower: a set of levels that other players can install. This approach means the game's longevity depends partly on community-created content rather than only core maintenance.

The last push was on 2026-03-27. GitHub lists no releases for the repository, which means there is no versioned release history to consult for changelog information. Developers who need a stable, versioned dependency should verify the project's current state before integrating any part of it into a larger workflow.

Editorial conclusion

WarriorJS suits developers who want to practice JavaScript or TypeScript decision-making through a self-paced, offline challenge. It is not suitable for complete beginners who have never written an if statement, and it does not replace interactive platforms that provide instructor feedback or graded progress tracking. Before starting, confirm your Node.js version meets the package requirement of 24 or later, then verify whether the tower selection at warrior.js.org covers the skill level you are targeting.

Frequently asked questions

Official sources

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