30 章视觉小说怎么做：结构、工具与工作流

先说规模，这是判断工作量的基准：

这个体量，一个人做完，靠的不是"写得快"，是结构先搭好。

一、章节结构：先定骨架再填肉

30 章不是 30 个独立故事，是 4 卷的层层递进。做法：

1. 先写一句话主线：主角从哪到哪，中间失去什么、得到什么。
2. 拆成 4 卷：每卷一个核心冲突，卷末必须有一次状态变化（不是"打完一仗"，是"主角变了"）。
3. 每卷拆 6—8 章：每章一个目标 + 一个阻碍 + 一个代价。
4. 每章拆场景：一章通常 3—5 场，每场一个地点、一组在场角色。

结构不先定，写到第 10 章一定崩——因为你会发现前面埋的线收不回来。我们现在的做法是先把 30 章的章节标题和一句话摘要写完，再动笔。

二、角色管理：角色卡系统

25 个角色，靠脑子记必然乱。每个角色一份「角色卡」：

为什么要有"说话习惯"这一栏：25 个角色写下来，最怕的是"所有人说话一个味"。定了句长和口头禅，盲测都能分出是谁在说。

三、对白工作流：1097 组是怎么写出来的

不是从头写到尾，是三层推进：

1. 第一层：场景卡——每场写清"谁在哪、要发生什么、结束时状态变化"。
2. 第二层：节拍表——一场拆成 3—5 个节拍（推进 / 转折 / 收束），每个节拍一句话。
3. 第三层：逐句对白——按节拍写，写完立刻读一遍（出声读，默读发现不了拗口）。

这样写的好处：任何时候停下，都知道下一句该写什么。 不会出现"打开文档发呆半小时"。

对白的三个自检问题

• 这句话非说不可吗？（删掉是否影响理解）
• 这个角色会这么说吗？（对照"说话习惯"）
• 信息是"说出来的"还是"演出来的"？（能用动作就别用台词）

四、为什么选 Godot 4

关键考量是网页可玩：我们希望用户点开链接就能玩，不用下载。Godot 4 的 Web 导出能做到这一点，包体也能控制。

五、系统功能：不只是"点下一步"

视觉小说的体验差距，很多时候在系统而不是剧情：

踩过的坑：存档结构改动后，老存档读不出来。做法是存档带版本号 + 迁移函数，每次改结构写一段兼容逻辑。不做这件事，每次更新都会流失一批玩家。

六、资源命名与工程规范

这类项目最容易死在"资源乱"上。我们的规则：

• 命名统一：角色名_表情_服装.png、场景名_时间_天气.png
• 目录按类型分：characters / backgrounds / cg / audio / ui
• 不用的资源不删，移到 _unused（可能后面还要用）
• 大图分级：立绘和背景按显示尺寸裁，不要拿 4K 原图直接进工程

七、网页版的三个性能坑

1. 首屏加载慢

资源全量预加载会导致白屏很久。做法：只预载第一章用到的资源，后面按章节懒加载。

2. 图片太大

背景图不压缩，一张几 MB，手机上直接卡死。做法：转 WebP、按显示尺寸裁切。

3. 音频解码卡顿

长音频一次性解码会卡。做法：BGM 流式加载，音效短采样预载。

八、内容合规的一个细节

古风题材容易踩的一个坑：用了真实王朝名。

我们原本的设定里出现过真实年号，后来全部改成架空——原因有两个：一是避免历史争议，二是给创作留空间（不用被史料绑住）。

这条后来写进了自查清单：每次改文案，自动扫一遍真实王朝/皇帝名。

九、现在做到哪了

十、给想做同类项目的人

先写 30 个章节标题，再动笔。
先把角色卡填完，再写对白。
先做能跑的最小系统（对话+存档），再补分支和成就。

顺序反了，做到一半就会崩。