OpenFrontIO: A Browser-Based RTS Fork That Puts Deterministic Simulation First

What Problem This Solves and Who It Is For

OpenFrontIO addresses the problem of building a real-time strategy game that runs entirely in a web browser without plugins. It is a fork and rewrite of WarFront.io, and it targets players who want territorial control, alliance building, and resource management on maps based on real-world geography. For developers, the project provides a complete codebase in TypeScript that separates the game simulation from the network and rendering layers. This structure is useful for anyone who wants to study how a deterministic RTS simulation works or who wants to create a custom browser-based game without starting from scratch. The intended audience is twofold: players who want a free, open source RTS they can run themselves, and developers who want a reference implementation for client-server game architecture.

The Architecture: Deterministic Core, Client, and Server

The repository layout reveals a clear separation of concerns. The /src/core directory contains the deterministic game simulation, which is the part of the game that must produce identical results on all machines. The /src/client directory holds the frontend, and /src/server holds the backend. This separation is not accidental. In an RTS, the simulation must be deterministic so that the server can validate player actions and so that replays work. The README mentions replaying production games, which implies that the core simulation can be re-run from a recorded input stream. The /zbin directory is described as a compact binary wire format for zod schemas, which suggests that the project uses zod for schema validation and has a custom serialization format for network messages. This is a pragmatic choice for a game where bandwidth and latency matter, but it adds a layer of complexity for contributors who need to understand the wire protocol.

Getting It Running: Commands That Are Not Standard

The installation process is deliberately different from typical npm projects. The README instructs you to run npm run inst, not npm install or npm i. The script runs npm ci --ignore-scripts, which installs dependencies exactly as specified in package-lock.json and skips any install scripts. The rationale is to reduce the risk of a supply chain attack, since malicious packages can hide in postinstall scripts. This is a sensible security measure, but it means you cannot use the standard npm install workflow. After installation, you run npm run dev to start both the client and server in development mode with live reloading. The dev server opens the game in your default browser unless you set SKIP_BROWSER_OPEN=true. For client-only work, use npm run start:client; for server-only, use npm run start:server-dev. The README also provides npm run dev:staging and npm run dev:prod to connect to remote backends, which is useful for testing login flows or replaying games from real servers.

Development Tools and Testing Workflow

The project includes a set of development tools that are common for a TypeScript project but with some specific choices. Formatting is done with npm run format, and linting uses both Oxlint and ESLint via npm run lint. Using two linters is unusual; most projects pick one. The README does not explain why both are used, but it suggests that Oxlint might be faster for initial checks while ESLint provides deeper rules. Tests are run with npm test, but the README does not describe what kind of tests exist. Given the deterministic core, one would expect unit tests for the simulation, but this is not confirmed from the material. The presence of a test command is a positive sign, but the lack of documentation means you have to inspect the test files to understand coverage.

Licensing and Asset Restrictions

The source code is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). This is a strong copyleft license that requires anyone who modifies the code and offers it over a network to make the modified source available to users. The README emphasizes that modified versions must preserve the copyright notices in the footer and loading screen. There is also a separate asset license file, LICENSE-ASSETS, which is not described in detail. This is important because game assets like images, maps, and sounds may have different licensing terms than the code. If you plan to use OpenFrontIO as a base for your own game, you must check the asset license before redistributing any graphical or audio content. The README also mentions a LICENSING.md for license history, which suggests that the project has changed licenses over time, adding another layer of complexity for compliance.

Limitations and Failure Modes

One limitation is the installation command itself. The README explicitly says not to use npm install, which could be a stumbling block for developers who are used to standard workflows. If you forget and run npm install, you might trigger scripts that could be harmful. Another limitation is the replay feature. The README says unfinished games cannot be replayed on localhost, and you must be on the same commit that the game was executed on to replay it. This is a significant constraint for debugging: if you want to analyze a production game, you need to check out the exact commit, which may not be the latest. The project's release activity shows a test release (v0.34.0-test-release) as the most recent tag, which suggests that the project is in active development but may not be stable. The last push date is 2026-08-28, but the version numbers indicate a pre-1.0 state. For a production deployment, you would need to evaluate stability yourself.

Alternatives and the Difference in Approach

A direct alternative is the original WarFront.io, from which OpenFrontIO is forked. The difference is that WarFront.io is the original project, while OpenFrontIO is a rewrite. The README gives credit to WarFrontIO, but it does not explain what was changed. You would need to compare the two codebases to see whether the rewrite improves performance, adds features, or changes the architecture. Another alternative is to build a custom RTS using a game engine like Three.js or Babylon.js, but that approach lacks the server-side simulation and networking that OpenFrontIO provides. The key difference is that OpenFrontIO offers a complete, integrated client-server solution with deterministic simulation, whereas a custom engine would require you to design the networking and simulation from scratch. For someone who wants to understand how a browser RTS works, OpenFrontIO is a more complete reference than a raw engine.

Maintenance and Upgrade Cost

The maintenance cost of OpenFrontIO is moderate but not trivial. The project uses a deterministic core, which means any change to the simulation logic must be carefully tested to avoid breaking replays or server-client consistency. The presence of a test command suggests there is some test coverage, but the README does not detail it. The project also uses a custom binary wire format in /zbin, which means that any change to the schema requires updating the format and ensuring backward compatibility. This is a hidden cost for contributors. The release history shows a test release, which indicates that the project uses a release process, but the frequency is not clear from the material. Upgrading to a new version likely requires reviewing the changelog for changes to the core simulation or wire format. The AGPL license also imposes obligations if you modify and host the game, which is a legal consideration that adds to the maintenance burden.

Editorial conclusion

Adopt OpenFrontIO if you want a playable, open source RTS game you can run locally, modify, and self-host, and if you accept the AGPL-3.0 license obligations. Do not adopt it if you need a stable production game server, a non-web client, or a project with frequent releases: the latest push is a test release and the README warns against using npm install. Before adopting, verify the current state of the test release, review the asset licensing in LICENSE-ASSETS, and check the CONTRIBUTING.md workflow for the approved-issue process. The project is best suited for developers who want to study or extend a deterministic game simulation, not for teams seeking a turnkey deployment.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes