Gal Lop 变量调试技巧——快速排查分支和好感度问题

变量 bug 的典型表现

当你在 Gal Lop 里发现下面这些问题时，大概率是变量系统出了状况：

调试技巧 1：在对话节点里临时显示变量值

最简单直接的调试方法。在你想检查变量值的位置插入一个对话节点或临时修改已有节点：

在节点里写：
"DEBUG: 好感度小樱 = {好感度小樱}, 好感度雷姆 = {好感度雷姆}, 道具钥匙 = {道具钥匙}"

Gal Lop 会把 {变量名} 替换成当前值。预览时你就能实时看到所有变量的状态。

这个技巧的优势

• 即时：不用专门的调试面板，写了就能看
• 精确：可以在任意节点位置插入，检查那个时刻的变量值
• 灵活：想检查什么变量就写什么

这个技巧的局限

• 会污染正常对话——调试完记得删掉或改回正常文本
• 只能在预览 / 运行时查看，不能静态分析

调试技巧 2：从中间节点开始预览

Gal Lop 的预览模式支持从时间线上任意节点开始。这对于调试某个特定分支或某个条件节点特别有用：

场景 1：测试条件分支

条件节点在时间线靠后的位置，不想每次都从头走一遍剧情：

1. 找到条件节点 → 选"从此处开始预览"
2. 手动把前置变量调到触发条件（用调试对话节点显示的数值推算）
3. 看条件节点走了哪条路径

场景 2：测试好感度计算

要确认一系列选项后好感度应该是多少：

1. 找到第一个要测试的选项节点 → 从此处开始预览
2. 依次做出选项
3. 在每个选项后检查好感度数值

场景 3：测试多结局触发

结局判定条件在时间线最末尾，不想跑完全程：

1. 先跑一遍把所有变量调到触发目标结局的值
2. 存一个"调试档"（手动存档）
3. 以后每次测试新结局直接读这个档改变量

调试技巧 3：条件分支的边界值测试

条件判定经常因为边界值错误导致 bug。每个条件都要测试三个值：

测试模板

条件表达式：好感度小樱 >= 80

边界值测试特别重要，因为很多 bug 就是 >= 写成 > 或反过来导致的。

多条件组合测试

AND / OR 复合条件也要测边界：

条件：好感度小樱 >= 50 AND 事件告白成功 == true

调试技巧 4：变量名拼写一致性检查

Gal Lop 没有自动补全变量名功能，变量名全靠手打。拼写不一致是最常见的 bug 来源：

检查方法

1. 在变量管理界面列出所有已创建的变量名
2. 逐个比对所有引用该变量的选项节点和条件节点
3. 一个一个检查拼写是否完全一致（空格、下划线都不能错）

效率技巧：Gal Lop 的变量名支持复制。在变量管理里长按变量名 → 复制。然后在选项节点和条件节点里粘贴，不要手打。

调试技巧 5：分块注释和隔离调试

当作品有几百个节点、几十个变量时，变量 bug 排查会很痛苦。提前做好标记能省很多事：

每个变量创建时写清楚用途

在变量管理界面，给每个变量写备注：

变量名：好感度小樱
类型：数值（0~100）
用途：小樱路线的好感度累积，结局判定依据
初始值：0
在哪些节点被修改：1~30 号选项节点
在哪些节点被检查：第 50 号条件节点（路线分岔）、结局节点

每个条件节点写清楚判定逻辑

在条件节点备注里写：

条件：好感度小樱 >= 好感度雷姆 AND 好感度小樱 >= 50
用途：决定进入小樱专属路线还是雷姆专属路线
分支 1（满足条件）→ 小樱路线起始节点
分支 2（不满足）→ 共同线继续

分段调试

长篇作品变量太复杂时：

1. 把前半段（条件节点之前）的变量逻辑先单独跑通
2. 再把后半段接上
3. 确认中间的变量值是正确传递的

调试技巧 6：模拟玩家完整走一遍

写好变量逻辑后，最好的验证方法是假装你是玩家，从头到尾完整玩一遍：

• 所有选项都选让角色 A 加好感的 → 看能不能走到 A 线
• 所有选项都选让角色 B 加好感的 → 看能不能走到 B 线
• 混合选择（有时 A 有时 B）→ 看好感度比较结果是否合理
• 刻意去触发隐藏结局的条件 → 看能不能解锁

模拟测试能帮你发现"变量逻辑理论上正确但实际体验不对"的问题。

常见 bug 速查

Bug 1：条件节点永远不满足

最可能的原因：

• 变量名拼写错误（操作的变量和检查的变量不是同一个）
• 条件表达式写错（比如用了 = 而 Gal Lop 要求 ==）
• 变量值根本没被修改（选项节点的变量操作没生效）

Bug 2：条件节点永远满足

最可能的原因：

• 条件表达式写反了（比如本该 >= 50 写成了 < 50）
• 变量被重复赋值覆盖（某个节点把变量设成了一个很大的值）
• OR 条件逻辑不对（满足了其中一个但本意是要同时满足）

Bug 3：好感度变化不符合预期

最可能的原因：

• 选项节点里的变量操作是 -5 而不是 +5（符号写反）
• 后续节点里有"重置"操作把好感度清零了（忘记删测试代码）
• 预览从中间开始，之前的好感度操作没被执行

Bug 4：多结局全部触发同一个

最可能的原因：

• 多个结局节点的触发条件写错了（全部写成了同一个条件）
• 结局判定之前没有正确设置各个路线的变量标记
• 结局节点的连线错了（所有路径都连到了同一个结局）

结语

变量调试不是玄学——它本质是"定位问题 → 验证修正 → 确认修复"的工程流程。用好上面的技巧，90% 的变量 bug 都能在几分钟内找到原因。剩下的 10% 通常是复杂的复合条件逻辑，需要结合分块注释和模拟玩家来排查。记住：变量系统的问题 80% 可以归结为"变量名拼写错了"或"条件运算符写反了"，先检查这两个地方，别自己吓自己。