OpenPAL3 is an open-source reimplementation of Chinese Paladin 3

A 2003 role playing game, rebuilt in Rust

OpenPAL3 is an open-source implementation of Chinese Paladin 3, and the README states its own status with no hedging. The project is still in an early development stage, with many unimplemented features and bugs, and there is no polished gameplay experience yet.

That framing is the most important thing in the document, and it should be read before anything else. This is not a re-release of a finished game and not a fan remake that aims to be indistinguishable from the original. It is an engine and asset pipeline written to run someone else's data, and the authors are explicit that it is a work in progress.

The technology choices are visible in the repository. The primary language is Rust, the topics name vulkan, and the licence is GPL-3.0. There is a second licence file, LICENSE_RADIANCE, next to the main one, which points to the structure of the repository: a layer called Radiance that is the engine, and a layer called yaobow that is the editor and tooling around it.

The releases carry alpha version numbers with names attached, v0.4-alpha titled Shout your soul from 2026-05-26, v0.3-alpha from November 2021 and v0.2-alpha from March 2021. The last push to the repository was on 2026-09-17, and the repository is not archived, so the alpha line is still moving.

The audience is a preservation community and the engine developers around it, not a player looking for a game to install.

No game data ships with it, and it has to stay that way

The README carries a statement section with two points, and the first is the one that shapes every use of the project.

The first is that OpenPAL3 does not bundle any of the original game's data, so you must own a legitimate copy of Chinese Paladin 3 for it to run at all. The second is that the project is not an official work of Softstar or Daewoo, the companies behind the original.

The split between engine and data is the whole legal structure of the project. The code is open under GPL-3.0, and the data stays with the person who bought it. That is why the first run is not a download-and-play: you have to point the project at your own installation, which the README describes as configuring the resource directories for the game through the settings button in the yaobow editor.

For the community, the consequence is visible in the related material the README points to. There is a link to a tool for unpacking the game's archives, a tieba thread with discussion of the directory structure and contents of the data files, another post analysing part of the structure of the pol files, and a post on another forum analysing the cpk and sce file formats. Those are research inputs, and the project is downstream of the people doing the analysis.

The same reasoning explains the licence choice. An engine that reads files the user already has, distributed under a copyleft licence, keeps the community's improvements in the open while leaving the proprietary data where it was.

Two engines in one Cargo workspace

The Cargo manifest is the clearest map of the project, and it is a workspace with a long member list. The Radiance side takes five crates:

[workspace]
members = [
    "crosscom/ccidl-rs",
    "crosscom/runtime/protosept",
    "crosscom/runtime/rust",
    "radiance/radiance",
    "radiance/radiance_editor",

and then the yaobow crates, which are the yaobow binary itself, the yaobow editor, the yaobow asset patcher, the asset project, agent server, common, fileformats, macros, packfs and shared. There is also a set of tools crates, and a third party mini-fs crate vendored under radiance/3rdparty.

The naming tells you the design. Radiance is the engine: the runtime that interprets the game. The crosscom directory is the cross-platform component, with a Rust runtime, a protosept runtime and a ccidl-rs crate, which suggests a layered design where the engine core is isolated from the platform layer.

yaobow is the editor and the asset pipeline, and it is what the user actually runs first. The yaobow editor is where you configure the game's resource directories, and the yaobow asset patcher and the packfs crate handle the game's package format, while fileformats is where the format knowledge lives.

The tools directory is the most interesting part for an engineer, because it is a set of focused binaries: pol_exporter, pal4_plot_dump, pal4_gob_inspect, csb_inspect, repacker and scn_inspect, with two more, asdebug and dbexp, commented out in the manifest. Names like inspect and dump are the vocabulary of reverse engineering, and a tool called repacker is the write side of the same knowledge.

Patched dependencies and a compiler workaround

The workspace does not use the crates.io versions of several dependencies, and the manifest is explicit about it. There is a patch section for crates.io that points filetime, chlorine, vcpkg and xxhash-rust at forks under the same author's account, each on a yaobow branch, and cty at a fork on a loongarch branch. The comment on the cty entry explains that it is only pulled into the crate graph on the LoongArch target and that Cargo emits a harmless warning about an unused patch on other hosts, and asks that it be kept for LoongArch.

That is a significant maintenance commitment for anyone depending on the project. Four dependencies are tracked as forks, so an upstream security fix in those crates does not arrive automatically, and a rebuild against a newer upstream can change behaviour.

The last part of the manifest is the most interesting, because it is a compiler bug rather than a design choice. The comment describes a workaround that builds the lua50-32-sys C library, which wraps Lua 5.0.3, unoptimized. The root cause is given precisely: the MSVC toolset 14.51.36231, identified as VS 18 from 2026, has a code generation bug that miscompiles Lua 5.0.3 at /O2 on x86_64, corrupting a table's array and sizearray pair so that the first luaopen_base faults with an access violation.

The lesson in it is worth extracting for any project that vendors an old C library on Windows. A language runtime from 2003 does not build cleanly with a 2026 optimiser, and the fix is to compile it unoptimized rather than to patch it.

Configuration, controls and the OpenAL dependency

The first run needs configuration, and the project tells you exactly where the file goes. The settings are written to a yaobow.toml file in the standard per-user configuration directory of the operating system:

| Platform | Path | | --- | --- | | Windows | %APPDATA%\yaobow\yaobow.toml | | macOS | ~/Library/Application Support/yaobow/yaobow.toml | | Linux | ~/.config/yaobow/yaobow.toml |

There is also an example file, docs/yaobow.toml.example, that you can edit by hand, and the YAOBOW_CONFIG environment variable can override the path. The README flags a migration detail that would otherwise bite: the older root-level openpal3.toml is deprecated and is not migrated automatically, so you have to respecify the directories through the editor's settings interface.

After that you run openpal3.exe. If the runtime reports an OpenAL error, the fix is to download and install OpenAL, which is a separate audio runtime that has to be present on the machine.

The controls are listed and are short: the spacebar advances dialogue, A and D adjust the camera, Escape skips a cutscene, F interacts, the arrow keys run, and 1 through 4 save to the first through fourth save slots.

A demo build of the latest development version is produced by Azure Pipelines, while the v0.3 release is downloaded from the Releases page, and the community runs on a QQ group. The README also links the local build instructions in docs/BUILD_INSTRUCTIONS.md and the contributing guide.

Five platforms in continuous integration

The badge row at the top of the README is a small but informative map of the project's ambitions: Windows, Linux, macOS, Android and the PlayStation Vita each have their own workflow, with a separate ci-windows.yml, ci-linux.yml, ci-macos.yml, ci-android.yml and ci-psvita.yml.

Building for a handheld from a desktop project in Rust and Vulkan is an unusual ambition, and the toolchain in the manifest backs it up, with a vcpkg.json at the root and patched vcpkg bindings, since the native dependencies for a Vulkan and audio stack have to come from somewhere on each platform.

The repository also carries the small things that a long-lived project accumulates: a rustfmt.toml, a Cargo.lock, a .cargo directory, a .gitmodules file, a packaging directory, a docs directory, a CONTRIBUTING.md, a pal5_grass_re.md file whose name suggests reverse engineering notes on the fifth game's grass format, and a tools directory that doubles as a record of the format work.

For a reader trying to judge the project, the combination tells a consistent story. It is a serious reimplementation with a proper workspace structure, a purpose-built editor, an in-house asset pipeline, dedicated tools for reverse engineering the original formats, and continuous integration across five platforms. The open question is not whether the work is serious, since it plainly is, but how much of the game is playable, which is exactly what the alpha status says.

Editorial conclusion

OpenPAL3 fits a preservation-minded player or engine developer who owns a legitimate copy of Chinese Paladin 3 and wants to run it on modern hardware with an open, inspectable implementation, or who wants to study how a 2003 era RPG was built. It is the wrong tool if you want a finished game, because the project states plainly that it is in early development with many unimplemented features and bugs and no polished gameplay experience, and it is the wrong tool if you do not own the original game, since the project ships no data at all. Before building it, read the build instructions in docs, expect to configure asset directories through the editor before the first run, and budget for the fact that the workspace patches several crates to forks.

Frequently asked questions

Official sources

1. dontpanic92/OpenPAL3 on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases