视觉小说配音

塑造了这个门类的经济账

视觉小说以文本为先，既是传统也是必然。这个形式成长于一个配音很贵、台词量又极大的市场，于是惯例变成了部分配音：主线配上，支线内容静音，主角不出声好让玩家代入。

这些惯例现在既是经济的也是审美的——很多玩家就是偏好它们——但底下那道限制确实变了。一个小团队现在配得起过去只能留白的素材，而那主要是支线路线和次要角色，而不是主线。

分支让一致性比看起来更难

线性故事是按顺序听一遍。分支故事是被打乱顺序、反复地听，而且玩家是刻意在对比不同版本。第二个月写的一句和第九个月写的一句，会被任何走第二条路线的人连着听到。

这让声音漂移比在线性游戏里显眼得多。任何依赖「有人记得当时怎么选的」的机制，最终一定会失效。这里的角色只存在于一个项目里，所以流程规矩是一张写好的角色表：每个项目里每个角色都用同一个库角色和人设、按同样的顺序加入，并在导出前听一下每个主角的第一句，因为新项目不保证把角色落到同一把嗓子上。

把渲染这一步塞进引擎流程

实际的集成问题是文件命名。引擎按标识引用音频，而 CastDub 不导出逐句文件：它每个项目导出一条混好的 MP3，Pro 上每个角色一条音轨，Plus 起一份 SRT。SRT 就是那座桥。每一条是一句，按剧本顺序，带着起止时间，所以一个按这些时间码切开成片、再按你的台词清单给片段命名的小脚本，能把导入重新变回一次复制操作。

第二个问题是增量渲染。视觉小说剧本在测试期的变动远多于大多数游戏内容。只有改过的台词会重新生成，但导出总是覆盖整个项目，而且改动之后的每一句在时间上都可能挪动，所以把项目控制在一场戏或一小批台词，按新的 SRT 重新切，你的音频目录在两次构建之间就是稳定的。

告诉玩家他们听到的是什么

视觉小说社区对配音意见很强，部分原因是配音演员是这个门类文化里显眼且被爱的一部分。在这种语境下生成配音不是中性的，而人们的反应很大程度取决于团队有没有一开始就讲清楚。

写在商店页面上。说明哪些部分是生成的，如果有真人录音的部分也说明是哪些。这样做的团队基本上是被按结果评价的；被事后发现的团队是被按「隐瞒」评价的，而后一种评价严厉得多。

部分配音是一个设计决定

既然全部配音已经负担得起，有意思的问题就变成了「该不该」。玩家读字比声音说话快，而全程配音的视觉小说要么强迫读者等，要么让他们跳过音频，而后者让配音本身失去意义。

行得通的做法是：给那些因表演而增值的地方配音——情绪场次、角色首次登场、路线高潮——把连接性的文本留静音，让读者按自己的速度走。很多口碑不错的商业作品正是这么做的，而且是刻意的，不是因为预算。

一个好用的判据：如果一句台词存在的目的是传递信息，静音就够了。如果它存在的目的是传递角色对这个信息的感受，就给它配音。

配合测试版本一起迭代

视觉小说的剧本在测试期变动比大多数游戏内容都多，因为测试者会找出读起来不顺的分支，而编剧会当场重写。一条跟不上的配音流程，最后会变成「不去修问题」的理由，而那是最坏的结果。

让这件事成立的性质是增量渲染：改八条，只有这八条会重新生成，其余保留原有音频。没有逐句文件导出，所以文件仍然来自按 SRT 时间码切开导出的成片——每个项目控制在一场戏或一小批台词，重新导出和重新切的量就都很小，你的音频目录在两次构建之间保持稳定，版本控制的差异也保持可读，没人需要纠结「这次改写值不值得重渲」。

这套东西值得在写作完成之前就搭好，而不是之后。等剧本锁死再搭的团队会发现，剧本永远不会锁死。