Archive vs. Raw Assets: Choosing the Right Deployment Strategy in Ren'Py

Short answer

Ship release builds with .rpa archives and keep the game/ directory as an override layer. Ren'Py resolves a path by looking in the raw game/ tree first and only then in the archives, so a loose file at the same relative path wins. That one rule answers both halves of the question: archives for code protection and tidier distribution, raw files for hot-reload and for patching a shipped build without repacking.

Override priority: raw beats archive

Duplicates between game/ and an archive are not an error — they are the supported override mechanism. The practical consequences cut both ways:

• You can patch one asset by dropping a replacement in game/; the archive stays untouched.
• A stray file left behind during development silently shadows the archived copy in the release build if you forget to remove it.

Which paths end up archived versus loose is decided by the build rules in the build section of options.rpy (the build.classify / build.archive pattern rules). If you want a path to stay patchable, make that decision there rather than by hand-editing archives.

Case sensitivity is a path problem, not an archive problem

Archives store entry names exactly as they appeared on disk at build time. On Linux and other case-sensitive file systems, a script reference to images/bg.png will not match an archive entry named images/BG.png. Windows and macOS hide this because their default file systems are case-insensitive, so the same build works locally and fails on a Linux target.

Two details make this harder to diagnose than it looks:

• The failure surfaces as a generic missing-file error, not a case warning.
• A loose override with the wrong case will not rescue it either — the override must match the reference, not the archive.

Marked for review: image tag lookups such as show eileen happy go through Ren'Py's image registry rather than the file loader, so case rules there may differ from file-path rules. I have not verified that distinction here.

Patching a production build without rebuilding archives

1. Place the replacement at the exact relative path and exact case the script references, for example game/images/bg.png.
2. Leave the archive in place; other assets still load from it.
3. If you later repack, check whether your build rules swept the patched path into the new archive. Two copies are harmless because the loose one still wins, but the duplication is confusing — decide deliberately which paths are archive-classified.

Avoid renaming an .rpa to .zip and editing it in place. That is not a supported workflow and risks corrupting the archive. Use the SDK's build/distribute flow, or a maintained third-party reader if you only need to inspect entries.

Verification

# 1. Read-only: list paths that differ only by case
find game -type f | tr 'A-Z' 'a-z' | sort | uniq -d

# 2. Confirm the exact case of a referenced file
ls -l game/images/bg.png

# 3. Static check of loadable references
/path/to/renpy.sh /path/to/project lint

Run the lint step on Linux or in a Linux container — that is where the mismatch reproduces. Then launch the build on Linux and confirm the patched asset appears without repacking.

What would change the recommendation

If you only ever target Windows and macOS, the case issue largely disappears and the archive decision reduces to load behavior and code protection. If you need frequent per-asset patches, keep a dedicated loose directory and add build rules that keep it out of archives.

Version assumption: this describes Ren'Py 7.4+/8.x behavior. Exact CLI subcommand names vary slightly between releases, so confirm against your installed SDK's launcher.