[VN]从代码层解决Password游玩时的疑难杂症

杨桃蜜饯_

编辑于 2026年09月25日 23:06

哈啰，这里是杨桃～从 2023 年至今，我在私信和评论区里经常收到这样的问题：“为什么剧情里明明拿到了奖牌，最后结算却说没拿齐？”

不少汉化组和大佬早就通过解包找到了答案，但这些机制对普通玩家来说，还是不太容易弄明白。为了集中回答这些老问题（虽然来得有点晚，也希望能让后来的大家少走弯路），这篇专栏会结合 PW 的 50 个 .rpy 脚本文件，看看游玩时的“疑难杂症”究竟是怎么回事。内容稍微硬核，建议用大屏幕查看～

声明：本文基于公开发行版本（b0.85）的脚本分析，仅作机制探讨与通关指引，版权归原作者 Grizz 所有。正文包含大量剧透，默认大家都已经看过我之前的专栏啦：[VN]Password剧情线路和细节梳理（攻略向）

感谢 GPT 帮忙在几万行 Ren'Py 代码里捉虫 owo

一、奖牌收集机制

奖牌收集是大家提问的重灾区。之前的专栏主要给了剧情位置，这次再把“系统到底什么时候算拿到了”讲清楚。

首先需要了解的有：

奖牌收集由 Ren'Py 的 `persistent` 持久变量记录，可以跨周目、跨结局累计。最终结算时，游戏会临时统计十二枚星座奖牌的标记：不足 12 枚时提示尚未集齐；满 12 枚时进入 full set 判定，并引出蛇夫座 Ophiuchus 的叙事提示。进入 P 线只需这十二枚奖牌，不用再找第十三枚，但集齐后仍要完成 Path A 结尾的检查。

奖牌变量的初始化在 `script.rpy`：

 代码块
Python
自动换行
复制代码
default MedalsFound = 0
default persistent.aries = False
default persistent.taurus = False
default persistent.gemini = False
default persistent.cancer = False
default persistent.leo = False
default persistent.virgo = False
default persistent.libra = False
default persistent.scorpio = False
default persistent.sagittarius = False
default persistent.capricorn = False
default persistent.aquarius = False
default persistent.pisces = False复制成功

（B站的代码块没有 Ren'Py 选项，这里使用 Python 语法高亮。）

这里最重要的是 `persistent`：它记录的是跨周目的收集进度，不只属于某个存档。玩家在不同路线、结局中取得的奖牌，都可以累计到这里。实际写入发生在剧情脚本执行 `$ persistent.xxx = True` 时；这些状态会保存在 saves 文件夹中的 persistent 文件里。Path A 的两处一次性剧情也使用了持久变量。

⚠️ 剧情里“看见拿到奖牌”，不等于系统已经正式记下了它。有些奖牌很早就被发现，却要推进到 D16 整理奖牌的场景，执行 `$ persistent.xxx = True` 后才算收集完成。下面说的“触发位置”，指的就是这个实际写入点。

解包时发现，有一些奖牌有两个甚至三个触发位置。请注意，如果一个奖牌有多个触发位置，并不意味着是“多个不同奖牌”，而是“同一个奖牌可以在不同剧情路径中被写入”。

下面这张表按实际写入点整理。“写入点”是执行 `$ persistent.xxx = True` 的位置；表中的脚本和行号方便定位，真正推进到对应场景才会触发记录。

同一奖牌出现多个代码位置时，通常是为了兼容不同路线、不同存活状态、不同结尾文本；只要任意一个 `$ persistent.xxx = True` 被执行，该奖牌就会进入全局收集状态。

明明拿到了，为什么系统没记上？

最终奖牌判定在 `Day24A_Redux.rpy:2732-2785`。代码不是检查某个“当前周目背包”，而是这样做：先 `$ MedalsFound = 0`，然后逐个看 12 个 `persistent.xxx` 是否为 `True`，每个为真就 `MedalsFound += 1`。最后如果 `MedalsFound < 12`，就返回；如果满 12，进入 full set / Ophiuchus / prime timeline 的文本。

这套机制有几个可能导致误判的地方：

水瓶座和金牛座的“发现日”与“写入日”不一定相同。前面看见找到奖牌的剧情，并不代表已记录；还要推进到 D16 A/B 整理奖牌、确认星座的场景。这就是“剧情发现”和“系统收集”的区别。
双鱼座、摩羯座和巨蟹座各有 D9 的直接写入点，也有 D16 A/B 的补写入口。分别走到 Dean、Sal、Roswell 线的 D9 对应场景，就能记录那枚奖牌；D16 A/B 也会根据角色线标记补写同一枚奖牌，不是额外再给一枚。
射手座和处女座各有六个写入点，并不是要你把六条角色线全部跑完，而是为了对应六种关系结局。完成任意角色线的 Path B，Florencia 都会交付射手座；Path A 则是处女座。
最终检查在 Path A 结尾，而且 `MedalsFound` 每次都会重置为 0 后重新统计 persistent。这个 `MedalsFound` 不是收集本体，只是临时计数器。真正的收集本体是 `persistent.aries` 到 `persistent.pisces` 这 12 个布尔值。所以玩家看到 “MedalsFound 不够” 时，不是某个计数器丢了，而是至少一个 `persistent.xxx` 仍然是 `False`。

乱七八糟说什么呢，我技术小白听不懂！

简而言之，如果发现自己“明明找到了某个奖牌但系统判定没有收集到”，请优先排查这几个问题：

是否只是看到剧情上发现，而还没推进到真正 `$ persistent.xxx = True` 的代码段。仔细查阅上表的触发位置，留意上下文定位具体文本。
是否完成了对应角色路线的 D9 或 D16 补写场景。
是否已经先走过 Path B 拿双子座和射手座，再回 Path A 结尾做 full set 检查。
是否把游戏持久数据清掉过，或者换设备/换版本导致 `persistent` 丢失。

二、好感度增加机制

好感度在 PW 中表现为 6 个独立计数器，没有统一计算公式，通常通过选项累加。不过有一个例外：Path C 的 Sal 泳池剧情会把 Sal 好感度直接设为 0。在一条角色线中，也可以增加其他角色的好感度；但游戏不会按谁的分数最高来自动换线，数值有没有作用，要看具体场景检查了谁的好感度。

好感度阈值

各角色的判定阈值不完全一致，但它们都实际参与剧情分支、对白差异、亲密事件或路线内状态判断。

不同角色使用的阈值并不相同，不能统一理解成“5 点是朋友、20 点是恋人”。有些检定只改变一句对白，有些会影响亲吻或关系是否成立；具体效果请结合下面的差异表查看。

好感度阈值指的是分数，不是剧情天数。各角色的好感度通常从 0 开始，通过选项累加；前面提到的 Sal 清零是例外。另外，D3 彩蛋密码 `THE LOVERS` 会给全员加 5 点。

好感度增加选项

我按六个角色分别整理了详细的加点选项和前提条件。长表在专栏里不方便查阅，这里先放一张预览图；完整版可查看《PW好感度阈值+增加选项.pdf》，分享入口见置顶评论。最新在线表也可以直接查：https://password.carambi.com/mechanics/affection.html。注意同一菜单的互斥选项不能叠加，表里的路线和前提条件也要一起看~

实际研究完代码后发现加好感度的剧情节点原来有这么多！完整版见评论区置顶

好感度检定带来的剧情文本差异

这些阈值不是剧情天数，而是 Grizz 在代码中写死的隐藏好感数值判定。例如 `if lionlove >= 12:` 就是“如果 Hoss 好感至少 12，执行这一段额外或替代剧情”。它们不直接决定“能不能通关”（这也是为什么好感度机制在 PW 流程中存在感很低），而是决定 Dave 的心理描写、角色是否主动亲近、是否能亲吻、是否能进入更明确的恋爱表达，少数后期阈值会影响是否出现正式 boyfriend / confession 分支。

完整差异表较长，这里只放预览。加点选项与剧情差异分别整理成两份 PDF，后者是《好感度检定带来的剧情文本差异.pdf》，完整版在评论区置顶网盘获取。也可以直接查网页版：https://password.carambi.com/mechanics/affection-differences.html。分数不是统一的“朋友→恋人”等级，是否出现某段剧情还要结合角色线、选项和此前经历。

完整版见评论区置顶

Hoss 线：好感度与 CG 解锁

Hoss 线的两张亲吻 CG 都要留意好感度：D8 需要至少 12 点；D19 达到 15—19 点后选择接受关系也能解锁，20 点及以上则自动进入关系。所以，D19 那张图并不是非得刷到 20 点。

在 Hoss 线的 `Day 8.rpy` 中，逻辑结构大致是：

 代码块
Python
自动换行
复制代码
if lionroute == True:
    if lionlove >= 12:
        $ HossKiss = True
        scene hosskiss with dissolve复制成功

也就是说，D8 图书馆亲吻 CG `hosskiss` 要求处于 Hoss 线（`lionroute == True`），并且 `lionlove >= 12`。这是实际的 CG 门槛，不只是多看几句隐藏对白。

另一张 CG `hosskiss2` 位于 `Day 19.rpy` 的 Hoss 关系剧情：`lionlove >= 20` 时自动进入 `HossBoyfriend`，没有接受或拒绝菜单；`15 <= lionlove < 20` 时会出现 `Try dating.`／`Stay friends.`，选择 `Try dating.` 接受关系，同样能进入 `HossBoyfriend` 并解锁这张 CG。低于 15 点则维持朋友关系。

《好感度检定带来的剧情文本差异.pdf》和上面的网页版都列出了这两张 CG 的完整条件，查表时别漏看选项和前提哦。

一个疑似代码笔误（？）

`Day16AB.rpy` Sal 线中有一处疑似少写了等号：

 代码块
Python
自动换行
复制代码
$ croclove + 2复制成功

⚠️ 这不是赋值，也不是自增。Python 中它只是计算表达式，结果会被丢弃，因此实际不会给 Sal 加 2 点好感。如果玩家按文本选择本以为这里会加点，但实际无效。正确的代码写法应该是：`$ croclove += 2`。

三、密码输入机制

虽然老专栏里已经讲过密码机制，但从代码层看会更清楚。下面隐藏了当前主流程的关键答案，代码中的相关变量名也做了示意替换；彩蛋和已失效的旧版密码则被保留。

这里讨论的是普通金库输入，不等于“所有出现输入框“的地方。`Vault.rpy` 里的 `label vaultInput` 会准备密码列表和对应日期、读取输入、去掉首尾空格并转成大写，再检查密码及日期。如果两者匹配，就跳转到 `vaultPasswordX`，其中 X 是该密码在列表中首次出现的位置。

关键代码逻辑是（关键密码已被替换）：

 代码块
Python
自动换行
复制代码
$ passwordList = ["THE END", "THE LOVERS",  # 两个彩蛋密码
                  "Ros线密码", "Ty线密码", "Dean线密码",
                  "Hoss线密码", "Sal线密码", "Orl线密码", 
                  "Bxxx", "Bxxx", "Bxxx",
                  "Mxxx", "METEMPSYCHOSIS", "Wxxx"]
$ correctDayList = [1, 3, 4, 6, 6, 6, 6, 6, 7, 7, 7, 10, 11, 17]
$ VaultPassword = renpy.input("INPUT PASSWORD")
$ VaultPassword = VaultPassword.strip()
$ VaultPassword = VaultPassword.upper()

if VaultPassword in passwordList:
    if currentDay == correctDayList[passwordList.index(VaultPassword)]:
        $ renpy.jump("vaultPassword" + str(passwordList.index(VaultPassword)))复制成功

有编程基础的朋友肯定一眼看出为什么输入不区分大小写了：

`.upper()` 会强制把输入的字母全部大写；首尾空格也会被 `.strip()` 去掉。

有趣的是：

`passwordList.index(VaultPassword)` 只返回第一次匹配的位置，所以三个重复的 `"Bxxx"` 都会得到索引 8。玩过 b0.7 及以前版本的朋友可能还记得：D7 原本有两个假密码和一个真密码。到了 b0.85，这里保留了三个槽位，但前两个 label 已经没有正文；输入后会继续向下执行，进入第三个 label 的剧情。
在 `Day 7.rpy` 这里：

 代码块
Python
自动换行
复制代码
# NOTE PEACEKEEPER - Orlando shot
label vaultPassword8:

# NOTE ARBITER - Dean and Tyson argue over the gun
label vaultPassword9:

# NOTE Bxxx - Benson dead
label vaultPassword10:
    $ DAY7_PASSWORD_ACCEPTED = True  # 示意变量名，隐藏原答案
    ...复制成功

Ren'Py 的 `label` 是可跳转的标记，不是函数边界，也不会自动执行 `return`。如果某个 label 下面没有正文，执行流就会继续向下，经过后面的 label。这里的执行流程是：

 代码块
PlainText
自动换行
复制代码
输入当前 D7 正确密码（此处记作 Bxxx）
→ 在 passwordList 里找到第一个 Bxxx，索引 8
→ jump vaultPassword8
→ vaultPassword8 是空的
→ 自然落到 vaultPassword9
→ vaultPassword9 也是空的
→ 自然落到 vaultPassword10
→ 执行 $ DAY7_PASSWORD_ACCEPTED = True 和 Benson 死亡预兆剧情
（DAY7_PASSWORD_ACCEPTED 是隐藏原答案后的示意变量名）复制成功

所以这个改法不是“程序真的区分三个 `Bxxx`”，而是：三个 D7 旧密码槽位还在，但前两个槽位已经被掏空；输入现在只会命中第一个槽位 8，再通过空 label 连续落到第三个槽位 10 的真剧情。

这也解释了为什么它没有坏：如果 `vaultPassword8` 下面还有旧版 PEACEKEEPER 的剧情，输入真密码就会错误触发 Orlando shot 旧剧情；但现在 `vaultPassword8` 和 `vaultPassword9` 都是空壳，所以最后会统一进入 `vaultPassword10`。

眼尖的肯定发现老版本 D11 的密码 `METEMPSYCHOSIS` 也被留下来了。

`METEMPSYCHOSIS` 的情况和 D7 不一样。它没有被替换成别的密码，也没有空 label 落穿到某个新事件。它现在是一个残留密码项。残留痕迹有三层。

第一，`script.rpy` 的注释还保留旧设计：

 代码块
Python
自动换行
复制代码
# VAULT PASSWORD 12 - METEMPSYCHOSIS - (Day 11, unlocks Oswin route)复制成功

并且变量也还存在：

 代码块
PlainText
自动换行
复制代码
default METEMPSYCHOSIS = False复制成功

第二，`Vault.rpy` 的密码表也还保留它，并且 `correctDayList` 里对应 D11。由于它在密码表中的索引是 12，如果玩家在 D11 输入 `METEMPSYCHOSIS`，`Vault.rpy` 会尝试执行：

 代码块
Python
自动换行
复制代码
renpy.jump("vaultPassword12")复制成功

第三，当前脚本包中没有 `label vaultPassword12:`，也没有把 `METEMPSYCHOSIS` 设为 `True` 的正常入口。因此，它与 D7 的处理不同：密码项还在，但通往旧剧情的入口已经断了。正常流程中，这个变量会保持默认值 `False`，后续旧分支也就走默认文本。可以这样理解：

 代码块
Python
自动换行
复制代码
旧版：
Day11 输入 METEMPSYCHOSIS
→ vaultPassword12
→ $ METEMPSYCHOSIS = True
→ 后续 Oswin route / lab 信息分支走 True 文本

当前版：
密码表仍写 METEMPSYCHOSIS
→ 但没有 vaultPassword12
→ 没有 $ METEMPSYCHOSIS = True
→ 正常流程永远 False
→ 后续统一走简化后的默认文本复制成功

四、全 CG 收集

“某张 CG 到底怎么解锁？”也是我偶尔会收到的问题。

`newgallery.rpy` 里画廊通过 `galleryObject.unlock_image(x)` 绑定图片名，Ren'Py 会依据 `persistent._seen_images` 判断玩家是否看过该图片。也就是说，CG 解锁不是 Grizz 逐张写 `$ persistent.cg = True`，而是“玩家实际看过该图片名”后由 Ren'Py seen image 机制记录。

共定义 104 张图片，画廊实际收录 100 张

画廊外但普通流程可见的是：`envelopephoto3`、`hammondfamilyphoto2`、`roswellepilogue`。只在 `CGdump` 出现的是 `deanlove`；而 `CGdump` 在当前脚本里没有被其它 label `jump/call`。那 4 个旧 R18 Dean CG 是 `deangrope`、`deandavefrot`、`deandavehandjob`、`deandavehandjobclimax`，它们只出现在 `listOfSexCGs`，没有 `image` 定义、没有画廊登记、也没有剧情 `scene/show` 调用，因为 b0.85 版本原图片文件都已经被删掉了。

完整触发条件见《Password CG 解锁触发索引.pdf》，分享入口见置顶评论；也可以直接查在线索引：https://password.carambi.com/collectibles/gallery.html。画廊实际收录 100 张，不需要为另外 4 个图片定义把画廊刷到 104 张。

完整版见评论区置顶

画廊排列逻辑

如果想查缺补漏，请仔细阅读这部分内容：

画廊按 `script.rpy` 中的列表顺序排列，再由 `newgallery.rpy` 的 `vpgrid cols 4` 显示为四列网格，并不是按文件名排序。查“第 r 行、第 c 列”时，从 1 开始计数，对应的就是当前页签中第 `4 × (r - 1) + c` 张图。

游戏画廊实际有两个页签：`Memories`（回忆）和 `Trauma`（创伤）。`Memories` 页签先显示角色 CG，顺序是 Dave → Dean → Hoss → Orlando → Roswell → Sal → Tyson，然后接 Misc CG；总计 72 张，即 18 行 × 4 列。`Trauma` 页签显示 Death CG；总计 28 张，即 7 行 × 4 列。

下面按画廊顺序列出了 CG 文件名。发现某个位置空着时，先在位置表里找出文件名，再回到触发索引查解锁条件即可。

位置表的 PDF 文件名是《Password 画廊排列顺序对应表.pdf》，完整版在评论区置顶网盘获取；网页版 Gallery 页也能按位置查找。

完整版见评论区置顶

总结

到这里，奖牌记录、好感度、密码输入和 CG 收集这几个常见问题就讲完啦。对技术小白来说，代码部分可能还是有点硬核；看不懂也没关系，先看每节的结论，需要时再查表就好。如果还有疑问，欢迎在评论区提问；发现技术问题也欢迎指正！希望这篇专栏能帮大家少卡关、多看剧情，谢谢阅读 owo～

本文为我原创，未经授权禁止转载

cv49753344

分享至

投诉或建议

目录

一、奖牌收集机制

首先需要了解的有：

明明拿到了，为什么系统没记上？

乱七八糟说什么呢，我技术小白听不懂！

二、好感度增加机制

好感度阈值

好感度增加选项

好感度检定带来的剧情文本差异

Hoss 线：好感度与 CG 解锁

一个疑似代码笔误（？）

三、密码输入机制

四、全 CG 收集

画廊排列逻辑

总结