Taisei Project: native and browser play for an open source danmaku game

Taisei Project's distinct place in the danmaku genre

Taisei Project addresses players who want a top-down vertical-scrolling shooting game without acquiring a commercial release. Its genre is commonly called a danmaku game, STG, or bullet hell, where pattern recognition and repeated practice drive progress. The README positions the game for fans of the Tōhō Project series, but it also states that prior knowledge of Tōhō is not required.

The project is not presented as a reproduction of a Tōhō title. Taisei has an original story, music, art, gameplay mechanics, and codebase. That distinction matters for players deciding whether they want an original fan project or a familiar commercial game with official support and predictable content. The project draws on the permissive Tōhō licensing model that permits derivative indie works, while keeping its own assets and implementation separate.

For engineers, Taisei is also a concrete open source game codebase rather than a collection of engines. The repository is primarily C11 and includes an SDL3 presentation layer, OpenGL rendering, source code, tests, translations, build definitions, packaging material, and platform-specific directories. This makes it more relevant to developers interested in examining or adapting a complete game than to users who only want a reusable graphics library.

SDL3, OpenGL, and the Taisei Project runtime

The documented technology stack starts with C11 for the game code. SDL3 handles the host-side application layer, while OpenGL provides the renderer. The official targets are Windows, Linux, macOS, and WebGL-capable browsers, including Firefox and Chromium-based browsers such as Chrome and Edge. The README also says that other operating systems can be compiled, although it does not identify them as equivalent to the officially supported set.

At the gameplay level, this stack supports a top-down game loop with vertically scrolling play and dense bullet patterns. Those are genre characteristics described by the project, not a claim about a particular internal frame scheduler. The repository layout does confirm several implementation surfaces: `src/` contains project source, `resources/` contains packaged resources, `atlas/` handles graphical material, `emscripten/` is dedicated to the browser target, and `meson.build` drives compilation. Translation files live under `po/`, while platform integration and supporting components have dedicated top-level directories.

That layout makes Taisei more than a single executable source directory. A build can depend on resource processing, translations, generated atlas data, platform support, and submodules. The build documentation is therefore the correct place to investigate optional dependencies and platform configuration before changing compiler or renderer settings.

Installing Taisei Project and completing the first source build

The simplest route is a precompiled release from the GitHub Releases page. The README lists Windows x64, Linux, and macOS binaries for the complete game. A separate Nintendo Switch homebrew build exists, but the project labels it experimental and tells users to use it at their own risk. The repository's generated `Download ZIP` source archive is explicitly documented as broken because GitHub does not include submodules in that package. Source users should not substitute that link for a release archive or a recursive Git clone.

Developers who want to build the current source on Linux or macOS are directed to use Meson. First clone the repository with its submodules:

git clone --recurse-submodules https://github.com/taisei-project/taisei

The recursive clone is important because the README requires submodule maintenance after pulls, branch changes, and other Git operations. From the repository directory, configure, compile, and install the host build with:

meson setup build/
meson compile -C build/
meson install -C build/

Meson creates the build directory, compiles the project through that build definition, and performs the requested installation. The README does not give one universal post-install launch command because installation paths and executable invocation are platform dependent. After installing, start the complete game as documented for that platform. Game controls and basic play instructions are separate from the build process and are provided in `doc/GAME.rst`.

For a first play session without a native setup, the experimental browser build is a distinct option at `https://play.taisei-project.org/`. The README supports Firefox and Chromium-based browsers, so the relevant first verification is whether the page loads and starts the game in the browser being used.

Storage paths, saves, and operational configuration

Taisei does not confine user data to the application directory in the same way on every platform. It defines a platform-specific Storage Directory for data such as settings and other persistent state. On Windows, the likely location is `%APPDATA%\taisei`. On macOS, it is `$HOME/Library/Application Support/taisei`. On Linux, BSD, and most other Unix-like systems, it is `$XDG_DATA_HOME/taisei` or `$HOME/.local/share/taisei`.

The environment variable `TAISEI_STORAGE_PATH` can override the default behavior. This is a path override, not a complete installation command. Its practical use is to place or locate the Storage Directory independently from the platform default. This can help with packaging, portable environments, or diagnosing configuration problems, although the README does not document backup or rollback procedures for that directory.

Build-time configurability should not be confused with this runtime storage setting. The project uses `meson_options.txt` and related Meson files for compilation choices, while `TAISEI_STORAGE_PATH` affects where Taisei keeps its data at runtime. The README directs developers who need detailed dependency and build switches to `doc/BUILD.rst`. It also points controller users and other troubleshooting cases to `doc/README.rst`. Those documents are the authoritative places to check supported devices and configuration behavior, because the top-level README does not enumerate controller models or every Meson option.

Submodules, release cadence, and custom license terms

The clearest upgrade cost comes from repository structure. Taisei requires Git submodules, and the README instructs developers to run `git submodule update` whenever they pull new code, switch branches, or perform other Git actions. It also offers `./pull` and `./checkout` helper scripts to handle that work automatically. A source build therefore has more moving parts than a self-contained source archive, and upgrades should account for submodules as part of the checkout rather than as optional local dependencies.

The project is not archived, and the last push was on 2026-10-15. The recent release history also includes v1.4.6 on 2026-08-02 and v1.4.5 on 2026-07-03. These records show current repository activity and recent tagged releases. They do not establish long-term API stability, and the README does not provide a compatibility policy for save files, replays, screenshots, or build options across releases.

License review requires direct attention to the repository's `LICENSE` file. GitHub classifies the license as a custom license that it cannot place in a standard category, while the repository also contains `COPYING.txt` and `COPYING_CN.txt`. The README does not summarize redistribution, modification, attribution, or asset-specific conditions, so no legal conclusion should be inferred from the short repository description. Engineers planning to redistribute builds or incorporate parts of Taisei must read those files and distinguish the game's custom terms from the licensing status of Tōhō Project itself.

Native Meson builds versus the experimental WebGL edition

The WebGL edition is the clearest alternative to compiling Taisei natively. It changes the delivery model rather than the underlying game identity. Native builds use SDL3 and OpenGL and are officially supported on Windows, Linux, and macOS. They require platform dependencies and a Meson build when compiling from source, but they also fit the project's conventional desktop release path.

The WebGL build moves execution to a browser page. That removes the native compilation step for the player and supports Firefox and Chromium-based browsers. In return, the README calls it experimental, so its status should not be equated with the precompiled desktop releases. Browser graphics capabilities, driver behavior, and platform differences can place constraints on graphics-heavy interactive software, but the README does not document a specific compatibility matrix or performance envelope. It only identifies WebGL-capable browsers.

For players, the browser route is the easiest documented first attempt when no native binary is available. For packagers and engine developers, the Meson route offers direct control over a host build and exposes the C11, SDL3, and OpenGL stack. For source users who need a simple archive, the release page is the documented alternative because the repository's automatic `Download ZIP` omits submodules. None of these routes should be selected on an assumption that the browser and native releases have identical support status.

Editorial conclusion

Players who want an original Touhou-inspired browser game should try the experimental WebGL edition first, while developers should assess the Meson build and native SDL3 runtime. It is a poor fit for anyone seeking an exact Tōhō remake, a commercial support commitment, or a stable console release. Verify the platform-specific build, custom LICENSE terms, controller support in `doc/README.rst`, and the completeness of submodules before committing to adoption. For a native source installation, the decisive first step is a clean recursive clone followed by the documented Meson build sequence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. taisei-project/taisei on GitHub