Tyranor Next: a multi-engine visual novel launcher for Android

The problem: one Android launcher instead of five sideloaded engines

Visual novel players on Android have traditionally juggled separate apps. Kirikiri titles need Kirikiroid2, ONScripter titles need their own build, Artemis and Siglus titles need yet another runtime, and each app has its own scan behaviour, its own cover handling and its own save location. Tyranor Next is a reverse-engineered rewrite of the Tyranor emulator that puts those runtimes behind a single library interface. The README describes it as an aggregation launcher aimed at Android, with a stated design goal of staying light, simple and free of extra features.

The target user is someone with a local collection of Japanese-style visual novels who wants one place to scan, label, launch and back up saves. It is not aimed at developers shipping a game, and it is not a general Android emulator front end. The scope is deliberately narrow: five engines run in-process, and everything else is delegated.

How the three-layer architecture maps a game folder to an engine

The repository splits into two Gradle modules. `app` holds the Android shell: Compose UI, the functional abstraction layer, configuration, covers, saves, permissions and background updates. `engine` holds the runtime core: SDL2/SDL3, Kirikiri TVP, krkrsdl3, ONScripter, Artemis, Siglus, Tyrano, the JNI bridge and the host activities. The README fixes the dependency direction as UI interaction layer, then functional abstraction layer, then engine layer, and says that direction does not vary.

Inside `app`, `core/game/launch/EngineLauncher` takes a scan result and maps it to the matching engine activity, converting a SAF URI into a real file path. Detection is signature based rather than name based. A Kirikiri folder is recognised by `.xp3` or `startup.tjs`; ONScripter by `nscript.dat` or `.nsa`; Artemis by `system.ini` or `.pfs`; Siglus by `Gameexe.dat` or `Gameexe.ini` plus `Scene.pck` in the root or under `Data/`; TyranoBuilder by `index.html` and a `tyrano/` directory. For the web runtime the app looks at `js/rpg_core.js`, `js/rmmz_core.js`, `globalData.vndata` or a generic `index.html`, and it also inspects `app.asar` archives to decide what an NW.js package actually is.

Native engine plugins ship as `.so` files inside the APK under `nativeplugins/`. On first launch `NativePluginManager` unpacks and installs them into the app's private directory. The shared plugin sources live in `engine/src/main/nativeplugins`, and Gradle merges them into `app/build/generated/assets/nativeplugins/*.zip`, so the app module only carries a `manifest.json` and app-only plugins. The same pattern applies to RPG Maker injection scripts, which are synced from `engine/src/main/assets` at build time.

Installing Tyranor Next and running a first Kirikiri game

The README does not contain a build or install walkthrough; it points to the repository's releases, where the current line is published as beta-1.39 (Tyranor Next 1.39, dated 2026-09-16). There is no F-Droid listing or package manager command documented, so the practical route is to take the APK from the releases page and sideload it. The README states Android 8.0 (API 26) or higher is required, and that the native engine libraries currently ship only for `arm64-v8a`, so a 64-bit ARM device is mandatory.

After installing, grant the app access to your game directory. The README says game folders must sit in Android-accessible local storage and be authorised through the system file picker (SAF), and that at launch the directory must be mappable to a real file path. Some engines on external storage may additionally need the all-files access permission.

If you build from source rather than taking a release, the toolchain in the README is Gradle 9.5.1, AGP 9.2.1, Kotlin 2.x with the Compose compiler, `compileSdk 37`, `minSdk 26` and `targetSdk 36`. The repository ships a Gradle wrapper, so a build from the repository root starts with the wrapper script:

./gradlew

The generated native plugin archives appear at `app/build/generated/assets/nativeplugins/*.zip` after the build runs, and the README notes that the `engine` module holds the native sources, so a build without the Android NDK configured for `arm64-v8a` will not produce usable engine libraries.

For the first real use, drop a Kirikiri game folder containing `.xp3` files or `startup.tjs` somewhere under the storage you granted, then rescan the library. The scanner should classify it as Kirikiri and offer it as a launchable entry. Ren'Py and RPG Maker titles will not launch from the built-in runtimes: the README says they run through external APK modules, and the engine page marks an engine item with a cross when the target module is not installed, with a prompt to download and install it.

What Tyranor Next deliberately does not manage

The clearest limitation is the delegation boundary. Ren'Py and RPG Maker XP, VX, VX Ace and mkxp-z titles run through external APK modules that the user installs separately. Tyranor Next supports Ren'Py 8.5 and 7.7.1, and the engine version can be chosen globally or per game; automatic mode reads Ren'Py's `script_version` and Python 2 runtime markers to pick between the two modules. That is a real convenience, but it also means the launcher is only as good as the module you installed, and an uninstalled module leaves the engine entry unusable.

PSP and Nintendo Switch games are a different case again. They are scanned by ROM extension (`.iso`, `.cso`, `.pbp`, `.chd` for PSP; `.nsp`, `.xci`, `.nca`, `.nro` for Switch) and launched by handing off to PPSSPP or Eden through an explicit component plus read grant using a SAF content URI, with a file fallback path converted through FileProvider. The README states plainly that saves and settings for these two categories are managed by the emulator itself and the main app does not take them over. Anyone expecting unified save management across the whole library will be disappointed here.

The README also warns that actual compatibility depends on the engine version, the packaging and encryption, and the script features a given game uses, and that modified releases may need engine setting changes or patches. That is an honest admission that signature detection gets a game into the library, not necessarily into a running state. Finally, the arm64-only native library excludes 32-bit devices entirely, and the project has no iOS build yet; the README says an iOS version is planned and points to a separate macOS port.

How it differs from running Kirikiroid2 and PPSSPP side by side

The obvious alternative is the manual stack: Kirikiroid2 for Kirikiri titles, a standalone ONScripter build, PPSSPP for PSP, and separate Ren'Py and RPG Maker apps, each with its own folder browser. The difference in approach is where the work happens. In that stack, every runtime owns its own discovery and its own settings, and the user is the integration layer.

Tyranor Next inverts that by making scanning, classification and launch orchestration the core product. The functional abstraction layer owns game models, scanning, launch orchestration, cover fetching, save management, online patches, per-app and per-engine and per-game configuration, authorisation and background updates. The README lists a KRKR online patch module and a Hikarinagi OAuth flow for cover or metadata authorisation, both of which have no equivalent in a hand-assembled set of single-engine apps.

The trade-off is coupling. Bundling five runtimes into one APK means the app's release cadence is the engine cadence. The three most recent releases, beta-1.36, beta-1.38 and beta-1.39, all landed between 2026-09-14 and 2026-09-16, which suggests fast iteration on a beta line rather than a stable channel. If you want a runtime you can pin and forget, a single-purpose emulator gives you that. If you want per-game engine parameters in one settings tree, Tyranor Next is the only one of the two that offers it.

Licence and the cost of tracking a fast beta line

The repository is licensed GPL-2.0. That matters for anyone planning to redistribute a modified build or bundle it into another product, because the copyleft terms attach to derivative distributions. It also matters if you intend to link the engine module into a closed-source app. This is a description of the licence identifier, not legal advice; if redistribution is part of your plan, have someone qualified read the LICENSE file and the contribution guide before you build on it.

Upgrade cost is the practical concern. The README documents a build that merges shared native plugins and RPG Maker injection scripts from `engine/` into generated app assets, which keeps the two sides from drifting but means any engine-level change requires a full rebuild. The CONTRIBUTING.md is referenced as mandatory reading before a pull request, and the README says submissions must pass the review method described in the project's AGENT.md, with non-conforming code refused. For a user rather than a contributor, the relevant cost is simpler: engine fixes arrive only when a new APK does. The last push to the repository was on 2026-09-16, so the project is moving, but it is moving on a beta channel. Keep the previous APK around before updating, because the README does not document a rollback path.

Editorial conclusion

Adopt Tyranor Next if you have an arm64 Android device, a local game folder you can grant through SAF, and a library dominated by Kirikiri, ONScripter, Artemis, Siglus or Tyrano titles. Do not adopt it if you need 32-bit support, if you expect the app to manage PSP or Switch saves, or if your Ren'Py and RPG Maker titles are your main use case, because those run through separately installed APK modules. Before committing, verify that the specific engine version and packaging of each game you care about appears in the support table, and confirm that the Ren'Py 8.5 or 7.7.1 module is installed, since the engine page marks an uninstalled module with a cross.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. Weiss-UltimateSavior/Tyranor-Next on GitHub