Athena Crisis Open Source Architecture and Development Setup

What Athena Crisis Makes Available

Athena Crisis addresses two related needs: exposing the non-content technical foundations of a turn-based strategy game, and giving developers code they can reuse in another project. Nakazawa Tech describes more than 100,000 lines of non-content code as open source. The repository includes map data structures and algorithms, game-state manipulation, rendering, AI, campaign-related structures, code generation, internationalization, a design system, and end-to-end tests.

This is an open-core project rather than a fully open-source game. The single-player campaign, multiplayer implementation, art, music, story content, and other game content remain proprietary. Backend systems such as user management, databases, APIs, realtime spectating, server configuration, and wrappers for Steam or application stores are also excluded. The repository is therefore most relevant to engineers studying game architecture or extracting reusable libraries, not to users looking for every component required to operate the commercial game.

The public repository is also a selective view of the company’s internal monorepo. The README says code merged here is synchronized automatically with the internal monorepo, and changes flow in both directions. Athena Crisis production runs the latest version of code from this repository. That arrangement makes it possible to inspect systems used by the actual game while withholding operational services and content that support the commercial product.

Package Boundaries Map to Client and Server Concerns

The repository is divided into packages so that developers can start with the layer that matches their task. The `athena` package handles map-state structures and algorithms, while `apollo` handles game-state structures and algorithms. Both are intended for client and server use. That separation matters when a project needs deterministic game logic without immediately adopting the browser-oriented rendering stack.

`hera` contains the client game engine and rendering. `ui` provides the client design system, and `docs` supplies the browser documentation and playground site. Secondary packages cover narrower domains. `dionysus` contains AI code, `hermes` handles campaign-related data structures and algorithms, `codegen` generates encoded actions and formatters after changes to game actions or action responses, and `art` handles assets during client builds. The `i18n` package covers internationalization, `offline` supplies the app splash screen, and `tests` contains end-to-end tests.

Based on the repository layout, the intended dependency direction separates portable state logic from rendering and build concerns. A server-side or library-oriented project can begin with `athena`, `apollo`, `dionysus`, or `hermes`. A visual project can add `hera`, `ui`, `docs`, `i18n`, and related client packages. The names follow Greek deities, but the README says the naming began when packages needed distinct identities for sharing code between client and server. The names are not a technical taxonomy.

Some public package files and the lockfile are included primarily to simplify dependency management with pnpm. Placeholder packages such as `ares` and `artemis` can be ignored when examining this repository.

Running the Documentation Playground Locally

The README documents the shortest supported local setup. It requires Node.js and the latest major version of pnpm. The installation and setup scripts prepare the workspace and development environment, after which the documentation process starts the local site. According to the README, the result is available at `localhost:3003`.

Run the documented installation and setup command from the repository root. The combined command installs workspace dependencies and runs `dev:setup`.

pnpm install && pnpm dev:setup

Then start the documentation application. The README expects the docs page to become available through the following local address.

pnpm dev:docs

Open `localhost:3003` in a browser to inspect the Open Source Docs & Playground. This first use is more useful for developers than for players because the commercial assets are absent. The README says art and other assets are loaded remotely from Athena Crisis servers during testing and development, so local development can still depend on network access to those servers.

The repository documentation does not describe a first workflow that launches a complete local campaign. It directs developers to the browser playground and the public documentation site instead.

Assets and Generated Actions Define the Open-Core Boundary

The asset pipeline exposes one of the repository’s clearest constraints. Athena Crisis does not include its art or other game assets in the open-source codebase. During development, those files are fetched remotely from Athena Crisis servers. A developer creating an independent game can use the source as a starting point, but the README explicitly expects such a developer to replace the assets.

This arrangement allows the technical code to remain inspectable without distributing proprietary content. It also means the repository is not self-contained for offline development of the full presentation layer. Network availability, server-side asset delivery, and the licensing status of downloaded content become adoption considerations even though the asset files themselves are outside the repository.

The `codegen` package addresses another source of generated consistency. The README says `pnpm codegen` should be run when game `Action`s or `ActionResponse`s change. That process generates encoded actions and formatters. This avoids requiring developers to hand-maintain related serialization and display logic every time the underlying action model changes.

The repository lists separate build scripts for client assets, client code, documentation, offline screens, splash screens, and Docker server images. Those script names show the intended build boundaries, but the available project documentation does not provide a complete release procedure. The commercial backend and store wrappers remain outside the open-source scope, so successfully building a public package does not amount to reproducing a deployable copy of the full product.

Tests, Linting, and Monorepo Contribution Checks

The contribution workflow treats linting and tests as prerequisites for a pull request. The README states that the project enforces its style guide through tests and linting and instructs contributors to run `pnpm test`. A successful run is presented as the condition for submitting changes.

Run the documented check before opening a pull request. This invokes the repository’s combined test command rather than a package-specific test command.

pnpm test

The repository also points contributors to the `tests` folder for examples of end-to-end tests and encourages pull requests to add coverage. Requested contribution areas include bug fixes, AI improvements, features, balancing, experimental technical work, tests, performance improvements to core data structures, and extraction of smaller libraries for npm publication.

This is more demanding than treating the repository as a loose collection of reference snippets. Shared code is synchronized with an internal monorepo, so changes can affect both the public repository and the company’s development environment. The repository does not document the exact review path or approval requirements for synchronizing changes, but it does state that synchronization occurs automatically and that production runs the latest repository code.

The private root package is marked `"private": true`, so it is not itself published as an npm package. The README says some reusable pieces may eventually be moved into a `packages` folder and published under the `@nkzw` organization. Existing contributors are asked to propose that extraction in a pull request.

Choosing a Package Path Instead of Adopting the Full Stack

A real alternative to adopting the whole Athena Crisis stack is to use `athena` and `apollo` as libraries for map and game-state work, then supply a separate interface. The difference is architectural. The full documentation path leads toward the client engine, design system, assets, internationalization, and application tooling associated with the existing game. The narrower path begins with state manipulation algorithms and omits the presentation stack unless it is needed.

This choice suits a command-line tool, server-side rules service, simulation, educational project, or new game that agrees with Athena Crisis state models but does not need its renderer. It also avoids treating the commercial game’s content as part of the reusable implementation. The trade-off is direct: narrowing the adoption avoids unrelated client dependencies, but it also removes the engine and UI components that provide a path toward a graphical tactical game.

The README says code can be used to improve Athena Crisis, build additional tools, study game development with JavaScript, or create new turn-based strategy games. It also states that commercial projects may use the codebase, while excluding content such as art, music, story, characters, and their descriptions from the open-source grant. Any evaluation should therefore inspect `LICENSE.md` rather than treating the repository’s “Other” classification as a complete description of permitted use.

The last push was on 2026-09-06, and the repository is not archived. No GitHub releases are published, so there is no release-based upgrade path documented in the repository metadata. Upgrades must instead be assessed through repository history, package changes, tests, and the custom `LICENSE.md`.

Editorial conclusion

Adopt this repository if you want to study or extend Athena Crisis TypeScript systems, or use its map and game-state packages as foundations for a related tactical game. Do not adopt it expecting a complete open-source remake, because the campaign, multiplayer, backend services, art, music, and other content are excluded. Verify first that the relevant package APIs meet your needs, that remote asset loading is acceptable for local development, and that the custom MIT terms in `LICENSE.md` cover your intended use.

Frequently asked questions

Official sources

1. Issues
2. nkzw-tech/athena-crisis on GitHub
3. Project website
4. README