siglus_rs

siglus_rs is an unofficial full Rust reimplementation of UK2, AVG32, RealLive, and SiglusEngine, with a primary focus on SiglusEngine.

This project is non-commercial and intended for research purposes.

Example screenshots

UK2 Engine

1993–1997 · AyPio

Sorcer Kingdom Title screen.

Sorcer Kingdom Dialogue scene.

Sorcer Kingdom Map exploration.

AVG32

1996–2001 · VisualArt's

AIR The title of AIR.

AIR Air opening.

Kanon Kanon opening.

RealLive

2001–2022 · VisualArt's

Little Busters! A screenshot of Little Busters!

Little Busters! The baseball minigame in Little Busters! (implemented in bt00.dll)

Tomoyo After: It's a Wonderful Life The Dungeons & Takafumis minigame in Tomoyo After ~It's a Wonderful Life~ (dt00.dll)

SiglusEngine

2010–now · VisualArt's

macOS SiglusEngine running natively on macOS.

iOS SiglusEngine running on iOS.

WebAssembly SiglusEngine running in a web browser.

Chihaya Rolling WE Official SiglusEngine benchmark released by Key to measure Rewrite performance.

Summer Pockets REFLECTION BLUE Key’s expanded version of Summer Pockets, adding new routes and a new heroine.

anemoi Key’s 2026 romance adventure title.

On game consoles

PS Vita Summer Pockets REFLECTION BLUE for PS Vita.

Nintendo Switch Anemoi for Nintendo Switch.

• siglus_rs works on a wide range of platforms, including Windows, Linux, macOS, iOS, Android, and WebAssembly.

Platform	Targets
Linux	x86_64, aarch64
FreeBSD	x86_64
Windows	x86_64, ARM64
macOS	aarch64 app, x86_64 app, universal DMG app bundle
iOS	arm64 device, arm64 simulator, x86_64 simulator
Android	arm64-v8a, x86_64
WebAssembly	wasm32-unknown-unknown
PS Vita	armv7
Nintendo Switch	aarch64

The app launchers (macOS bundle, iOS, Android, WebAssembly) import one game or many games at once, detect the engine (SiglusEngine, RealLive, AVG32, UK2), show cover art or the game icon, and let you pick the text encoding for non-Siglus games. See crates/game_launcher.

Pre-built binaries

• See preview releases on GitHub Releases

Documentation Availability

• API documentation is available at docs
• PS Vita port — experimental SiglusEngine player (siglus-psvita.vpk on the releases page); installing it and a game is described there. Roadmap.

Run

cargo run --release -p siglus_scene_vm --bin siglus_engine -- --project-dir ~/Documents/siglus_rs-main/testcase

Closing the desktop game window prefers the game's own exit confirmation. The engine looks for a unique, parameterless exit action in shared script commands, the configured cancel-menu scene, and the active title menu's local button actions. Title actions are available only after the title buttons are ready. Scripts that require EXCALL menu storage, unsupported or ambiguous scripts, and already active system menus use the built-in confirmation instead. An optional #CLOSE_SCENE = "scene_name", label entry in Gameexe.ini overrides discovery: that scene must handle confirmation and call syscom.end_game on acceptance; returning resumes the game.

Desktop windows use icon.png, icon.ico, or the first readable .ico file (in filename order) from the game directory, falling back to the Siglus icon. The engine uses winit 0.31.0-beta.3 to send window icons directly through xdg_toplevel_icon_v1 on Wayland compositors that support it. No desktop entry is generated. Each game retains a separate Wayland application ID.

Community

If you want to join the development and discussion of this project, you can join the following Discord server:

• Discord: https://discord.gg/g4rXucPZz3
• Personally, I only able to speak English, Chinese, Japanese, and very limited French.

The key.toml configuration file

The key.toml file is used to specify different configuration options for siglus_rs. The file should be placed in the root directory of the game project.

Resource decryption key

• This configuration key for this element is key. It is an array of 16 bytes (128 bits) that represents the secondary key.

• SiglusEngine games require a secondary key to decrypt protected resources.

siglus_rs can automatically brute-force the secondary key, but if you want specify the key manually, you can create a key.toml file in the game root directory.

There are several practical ways to obtain the key:

1. Static extraction, when the game executable is not encrypted or obfuscated (recommended). The general idea can be found in this repository:

   https://github.com/xmoezzz/siglus_static_key_tool

2. Dynamic extraction. The general idea can be found in this older repository:

   https://github.com/xmoezzz/SiglusExtract

3. Known-key databases maintained by some extractor tools.

Brute-force will be attempted in the following situations:

1. If the key is not specified in the key.toml file, siglus_rs will try to brute-force the key.
2. Users specify a wrong key in the key.toml file. siglus_rs will try to override the key.
3. If siglus_rs fails to save or overwrite the key.toml file, the engine will still execute.

Trial games may not require a secondary key, and in that case, you can specify all-zero key in the key.toml file. Here is an example of key.toml:

key = [
  0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00,
]

String Encryption

• This configuration key for this element is override_string_encryption. The value of this key can be xor, none, or mdl. The default value is xor.
• In very earlier versions of SiglusEngine, string encryption was not used.
• However, in later versions (for the most cases), string encryption is enabled by default.

Explanation of each value:

• xor: Enbales the string encryption. This is the default value even if the override_string_encryption key is not specified in the key.toml file.
• none: Disables the string encryption. If you are sure that the game does not use string encryption.
• mdl: Automatically detects the string encryption method by using the MDL approach (also see the paper: https://arxiv.org/abs/cs/0312044). It does introduce a performance overhead, but IMO, it's minor.

License

This project is licensed under the MPL-2.0 License. See LICENSE for details.