Ancient Beast: an open source browser strategy game with a server you can run

What the game is

Ancient Beast is a turn based strategy indie game project played online against other people, featuring a wide variety of creatures to acquire and put to use in order to defeat your opponents. The project says it was carefully designed to be easy to learn, fun to play and hard to master.

The gameplay loop is unit collection and tactical combat. You create an army out of a variety of units, each with their own unique abilities and stats, and control them in 1v1 or 2v2 combat against bots or other players. Alternate game modes allow different rulesets to mix up matches, or to try playing in a new way.

The setting is a dystopian future where people have excelled in power through advanced 3d printers, and the world is split into 7 factions based on the seven deadly sins, Avarice, Envy, Gluttony, Lust, Pride, Sloth and Wrath, fighting each other for resources, land and supremacy. And the README is emphatic that this is not a chance based game, that it is a matter of skill.

The technical pitch is in the hardware section, and it is the reason a browser project is interesting to look at. The game is designed to be lightweight and to run on most devices, as it adjusts on the fly thanks to various optimizations, and it is playable with mouse, keyboard and touchscreens, with gamepads, voice commands, AR and VR glasses and brainwave headbands promised as pretty soon.

The project is hosted at AncientBeast.com, the licence is AGPL-3.0 for the code, and the last push to the repository was on 2026-10-16.

The stack behind a browser strategy game

The package manifest describes a game that has moved from a jQuery era codebase to a modern one, and both are visible in the dependencies.

The rendering is Phaser at 4.2.1, and the keyword list in the manifest ends with phaser, so the engine is the centre of the front end. Around it sit jQuery 3.5 with jquery.transit for transitions, js-cookie for cookie handling and node-emoji.

The server side is a deliberate change of shape. Instead of the Node http module, the dependencies list hono at 4.12.28 with @hono/node-server at 2.0.8, and compression. Running Hono under the Node server adapter keeps the deployment story ordinary.

Multiplayer is peerjs at 1.5.4, which is the peer to peer networking layer, and that is the piece that makes the online against other people part of the design rather than an afterthought.

The newest dependency is devvit at 0.13.7 with @devvit/web, and the repository makes clear what it is for. There is a devvit.json at the root, a tsconfig.devvit-client.json alongside the other TypeScript configs. Devvit thus appears to be part of the architecture rather than an experiment.

So the current stack is a Phaser client, a Hono server and peer to peer networking, in a project whose primary language is TypeScript.

Running it: Bun, Docker and the debug flags

The Dockerfile is short, and it tells you the runtime the project has settled on.

FROM oven/bun:1.4.2

WORKDIR /usr/src/app
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun run build:dev
CMD ["bun", "run", "start"]

Bun provides the runtime, the lockfile is bun.lock, and the frozen lockfile flag makes the install reproducible. The image builds the development bundle and then starts the server.

The environment file is where the developer's controls live, and the .env.example is heavily commented, which is a sign that these flags are used daily.

ENABLE_SERVICE_WORKER=false
DEBUG_MODE=true
DEBUG_DISABLE_GAME_STATUS_CONSOLE_LOG=false
DEBUG_AUTO_START_GAME=false
DEBUG_GAME_LOG=false
DEBUG_DISABLE_MUSIC=false

Each flag does something specific. DEBUG_MODE is the global flag, and the file warns that if it is not set to true, yes or 1, the other DEBUG_ settings are set to false in game. DEBUG_DISABLE_GAME_STATUS_CONSOLE_LOG turns off the logging of gameplay updates, useful for keeping the console clean. DEBUG_AUTO_START_GAME loads a game with default settings, which saves a button click on the home screen. DEBUG_GAME_LOG, when set to a game log, starts a match automatically and replays that log, and the file explains that logs are generated by typing AB.getLog() in the browser console. DEBUG_DISABLE_MUSIC disables music but not sound effects, for when you want to listen to your own audio.

The service worker flag is separate from the debug ones, since it changes how the game is delivered to the browser.

Testing, and the simulation baseline

The repository has more testing infrastructure than most browser games, and the file names tell you what it is.

There are two Jest configurations, jest.config.js and jest.simulation.config.js, and a check.ts at the root, plus a simulation-baseline.json and a test directory and a tools directory.

A simulation test suite with a baseline file is an interesting pattern for a game. The idea is that the game engine can be run headlessly over a set of inputs, and the resulting state or replay is compared against a recorded baseline, so a change that alters the game behaviour shows up as a diff rather than as a subtle imbalance that a human notices weeks later. The baseline file is the recorded expectation, and it is committed, which means a change in behaviour has to be a deliberate act.

The TypeScript side of the project is equally deliberate. There are three tsconfig files, tsconfig.json, tsconfig.devvit-client.json and tsconfig.typecheck.json, so type checking is separated from the build, and there is a.babelrc.js alongside the Vite configuration, which is the residue of a build pipeline that was migrated and now carries both. The eslint and prettier configurations, the husky directory and the.prettierrc are the usual pre-commit machinery, and the check.ts file at the root is likely the entry point for the checks the tooling runs.

The.kilo directory, the tools directory and the scripts directory cover the parts of the project that are not the game itself, and the demos directory holds the examples.

The licence is three different things at once

The licence section of the README is a table rather than a sentence, and the split is unusual enough to read carefully.

The name and the logo are trademarks of Freezing Moon, with a request to respect the developers and their work. The artwork and audio are under CC-BY-SA 4.0, so they can be remixed and shared under the same licence provided you credit and link the project and the authors of the respective works. The codebase, or parts of it, are under AGPL 3.0, which permits remixing and sharing under the same licence provided you credit and link the project.

The package manifest expresses this as a single field, the licence of (CC-BY-SA-4.0 OR AGPL-3.0), and the repository has both an AGPL.txt and a LICENSE.md.

For a contributor, the practical rule is that the distinction is not academic. Code you write lands in the AGPL side, which carries the copyleft obligation for the program, while the art and the sound files stay in the Creative Commons share-alike side. A fork that wants to rebrand the game cannot use the name or the logo, and a fork that ships the game as a service inherits the AGPL obligations, which is the part that matters for a hosted instance.

The repository also carries a SECURITY.md and a CODE_OF_CONDUCT.md, which is a sign of a project with a community function rather than a solo hobby.

Release rhythm, funding and the state of the project

The release history is the clearest signal about the project's pace.

The tagged releases are v0.5 from 2026-06-06, v0.4 from 2023-02-03 and v0.3, with the codename Bouncer, from 2017-03-14. The package manifest version is 0.6.0. The last push to the repository was on 2026-10-16.

So the project is very much alive in the repository while the version numbers have moved slowly, with a three year gap between v0.4 and v0.5. For a volunteer game, that pattern is normal, and for anyone planning to depend on it, it means the master branch is where the current work is and the tags are milestones rather than a release train.

The funding model is Open Collective, and the README advertises the tiers with some humour, with Divine, Sponsors and Backers. Sponsors get their brand featured in game, which is a real incentive for a project with an audience, and backers support it monthly. There is also a sponsor link in the package manifest funding field pointing at the same collective.

Two smaller things are worth noting. The README asks contributors to read the repository's CONTRIBUTING.md for setting up a local copy, and links a broader contribution guide on the website. And there is a Gitpod badge, so the project expects people to get a running instance in a browser based workspace rather than assembling a local toolchain by hand, which is a sensible default for a game with this many build steps.

Editorial conclusion

Adopt Ancient Beast if you want to host your own instance of an open strategy game, or if you want to contribute to a browser game with a real TypeScript codebase, because the server, the build and the environment flags are all in the repository. Do not adopt it expecting a steady release cadence, since the tagged versions run from 2023 and 2017 to June 2026, and the code is at 0.6.0 with the major version still at zero. Before you deploy a fork, read the licence table, because the code, the artwork and the name are under three different terms.

Frequently asked questions

Official sources

1. FreezingMoon/AncientBeast on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases